JP2012126504A - Elevator group managing device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an elevator group managing device which manages an elevator group by optimizing a control method according to traffic demand.SOLUTION: The elevator group managing device has an elevator car, a detecting section, an extracting section, a traffic demand determining section, a control method storing section, a control method evaluating section, a control method acquiring section and a car assigning control computing section. The detecting section detects a getting-on load and a getting-off load for each direction and for each floor to be output as load information. The extracting section extracts a feature amount relating to getting-on and getting-off from the load information. The traffic demand determining section determines the traffic demand based on the feature amount. The control method storing section stores one or more control method candidates in association with each of reference traffic demands. The control method evaluating section determines an optimal control method from the control method candidates for each of the traffic demand. The control method acquiring section acquires a control method determined for the reference traffic demand which matches the traffic demand. The car assigning control computing section assigns an elevator car according to the acquired control method.

Description

  Embodiments described herein relate generally to an elevator group management apparatus that manages the operation of an elevator group.

  In order to improve the elevator operation efficiency and the service to the users, the elevator group management device is an optimal elevator car according to the control method set for the hall call generated at any time on any floor in the building. Assign. In such a group management device, it is assumed that the traffic demand changes depending on the day of the week and the time zone, and the control method is changed for each day of the week and the time zone. In addition, the control method may be changed when a specific condition is satisfied.

JP 2007-91378 A JP 2007-261819 A JP 2007-269424 A

  However, since the actual traffic demand changes from moment to moment, the elevator may be operated with a control method optimized for the traffic demand different from the actual traffic demand. As a result, there is a problem that the waiting time of the user is increased and the performance of the elevator is lowered such that the transportation amount per unit time is reduced. Therefore, in the elevator group management apparatus, it is required that the control method can be optimized following the continuously changing traffic demand.

  This indication is made in order to solve the above-mentioned problem, and it aims at providing an elevator group management device which optimizes a control system according to actual traffic demand, and manages operation of an elevator group. .

  An elevator group management apparatus according to an embodiment includes a plurality of elevator cars, a detection unit, an extraction unit, a traffic demand determination unit, a control method storage unit, a control method evaluation unit, a control method acquisition unit, and a car assignment control calculation unit. The plurality of elevator cars move up and down in the hoistway. A detection part is provided in each of the said elevator cage | baskets, detects boarding load and alighting load for every up-down direction and for every floor, and outputs load information. An extraction part extracts the feature-value regarding boarding and alighting from the said load information. The traffic demand determination unit determines traffic demand based on the feature amount. The control method storage unit stores one or more control method candidates in association with each reference traffic demand. The control method evaluation unit evaluates the control method candidate based on the elevator operation performance by the control method candidate, and determines an optimal control method from the control method candidates for each reference traffic demand. The control method acquisition unit acquires the control method determined for the reference traffic demand that matches the traffic demand. The car assignment control operation part assigns the elevator car according to the acquired control method.

The block diagram which shows roughly the elevator group management system which concerns on this embodiment. The figure which shows an example of a virtual call list. The figure which shows an example of a some virtual call list. The figure which shows an example of an allocation object call list. The figure for demonstrating the method to discriminate | determine the traffic demand at the time of going to work, leaving work, and normal time. The figure for demonstrating the method of discriminating the traffic demand at the time of the first half of lunch, the middle of lunch, and the latter half of lunch. (A) is a figure which shows an example of the load information of 1 sampling, (b) is a figure which shows the estimated number of passengers and the estimated number of persons getting off from (a), (c) is ( It is a figure which shows the boarding probability and the getting-off probability calculated from b), (d) is a figure which shows the result of having encoded (c). (A), (b), and (c) encode the standard floor boarding probability regarding the ascending cage and the standard floor boarding probability regarding the descending car shown in FIG. 7 (c) using threshold values θ1, θ2, and θ3, respectively. It is a figure which shows the result. (A) is a figure which shows the other example of the load information of 1 sampling, (b) is a figure which shows the estimated number of passengers and the estimated number of people getting off from (a), (c) , (B) is a diagram showing the boarding probability and the boarding probability calculated from (b), (d) is the sum of the standard floor boarding probability and the dining room boarding probability of (c), and the standard floor boarding probability and the boarding hall boarding probability. It is a figure which shows the result of having encoded the sum total with a probability using threshold value (theta) 4. FIG. The figure which shows an example of the feature vector produced | generated from the load information sampled every minute. The figure which shows an example of the integrated feature vector produced | generated from the feature vector shown in FIG. The flowchart which shows roughly the procedure in which the traffic demand determination part shown in FIG. 1 determines a traffic demand. The figure which shows roughly the traffic demand template stored in the control system memory | storage part shown in FIG. The flowchart which shows roughly the procedure in which the control system evaluation part shown in FIG. 1 determines the control system applied to a traffic demand. The figure which shows schematically the procedure in which the relearning determination part shown in FIG. 1 detects the deterioration of the control system determined by the control system evaluation part. The flowchart which shows the procedure in which the learning management part shown in FIG. 1 sets the optimal control system with respect to each traffic demand.

  Hereinafter, an elevator group management apparatus according to an embodiment will be described with reference to the drawings as necessary.

  FIG. 1 schematically shows an elevator group management apparatus according to the present embodiment. As shown in FIG. 1, the elevator group management apparatus includes an elevator group management unit 100, and the elevator group management unit 100 includes M elevator baskets (hereinafter simply referred to as “elevator groups”) installed in a building such as a building. The group management control of 161 to 16M is performed. Here, M is an integer of 2 or more. The baskets 161 to 16M are installed so as to be able to move up and down in a hoistway provided in the building, and are driven and controlled by the basket control units 151 to 15M. The baskets 161 to 16M are provided with basket call buttons 171 to 17M for instructing a target floor (destination floor). The baskets 161 to 16M are provided with load detection units 181 to 18M that detect loads in the baskets 161 to 16M, respectively.

  Hall call buttons 191 to 19N for making an elevator car dispatch request (hall call) are provided on each floor (floor) in the building. “Vehicle allocation” means that an elevator car is allocated in response to a hall call. FIG. 1 shows an example in which one hall call button is installed on each floor assuming an N-story building. For example, a user who wishes to board an elevator in order to move from the X floor to another floor presses the hall call button 19X and requests the elevator group management unit 100 to dispatch an elevator car. Here, X is an integer from 1 to N. The dispatch request is detected by the elevator group management unit 100 as a hall call. A method for determining the basket assigned to the hall call by the elevator group management unit 100 will be described later.

  The elevator group management unit 100 uses the car assignment calculation processing unit 110 that determines the assignment of a car to a hall call and the car assignment calculation processing unit 110 from among a plurality of control methods (virtual call lists) prepared in advance. A learning management unit 120 that determines a control method (virtual call list) is provided. Furthermore, the elevator group management unit 100 includes a car stop information storage unit 141, a hall call detection unit 142, a car call detection unit 143, and a car information detection unit 144.

  The basket allocation calculation processing unit 110 executes a basket allocation calculation process based on a virtual call list determined by the learning management unit 120 for a hall call generated at an arbitrary time on an arbitrary floor in the building. Decide which basket to allocate for the call. The basket allocation calculation processing unit 110 sends hall call allocation information including a set of identification information of the basket to be allocated and hall call information targeted for the basket allocation to the basket stop information storage unit 141. The hall call allocation information further includes hall call occurrence time, hall call occurrence floor, hall call direction, and the like. The hall call assignment information may include the time when the basket is assigned to the hall call.

  The learning management unit 120 determines traffic demand based on the car information obtained by the car information detecting unit 144 described later, and based on the determined traffic demand, the car assignment calculation process is performed from a plurality of virtual call lists. The virtual call list used in the unit 110 is selected. The selected virtual call list is sent to the basket allocation calculation processing unit 110.

  The hall call detection unit 142 detects that a hall call button 19X (X = 1, 2,..., N) on each floor is pressed, that is, a vehicle allocation request from the user. The dispatch request is detected by the hall call detection unit 142 in the form of generation of a new hall call. Information on the hall call detected by the hall call detection unit 142 is sent to the basket allocation calculation processing unit 110. The hall call information includes a hall call occurrence time, a hall call occurrence floor, a hall call direction (UP or DOWN), and the like.

  The cage information detection unit 144 detects the cage information regarding each of the cages 161 to 16M. The cage information includes data such as the load in the cage, the cage traveling direction, the cage speed, and the cage current position. The load in the car refers to the total value of the weight of the user who has entered the car and the luggage brought in by the user. The load in the cage is detected by load detectors 181 to 18M provided in each of the cages 161 to 16M. The basket information is sent to the learning management unit 120.

  The basket call detection unit 143 detects a press by the user of the basket call buttons 171 to 17M provided in the baskets 161 to 16M as a basket call, and passes the detected basket call information to the basket stop information storage unit 141. . The cage call information includes, for example, destination floor (destination floor) and basket identification information. The cage call information may further include the time when the cage call occurred.

  The car stop information storage unit 141 receives the car call information from the car call detection unit 143 and stores the car call information. Furthermore, the basket stop information storage unit 141 receives hall call allocation information from the basket allocation calculation processing unit 110 and stores hall call allocation information. When the car stop information storage unit 141 receives from the car control units 151 to 15M via the car information detection unit 144 that the allocation of the unanswered hall call is completed, the hall stop information storage unit 141 deletes the hall call allocation information related to the hall call. In addition, when the basket stop information storage unit 141 receives from the basket control units 151 to 15M via the basket information detection unit 144 that processing for an unanswered basket call has been completed, the basket call information related to the basket call is deleted. . Here, an unanswered hall call is a hall call that has already been assigned a car but has not yet been dispatched, and an unanswered car call is a car call that has not yet stopped at the destination floor. Point to.

  Depending on the difference in the group management processing system, for example, a basket other than the basket originally assigned to the hall call arrives first due to the occurrence of the car call, etc., and the passenger waiting for the floor arrives first. There is a case where a so-called “basket call first arrival” occurs. In such a case, hall call allocation information for hall calls may not be deleted.

Next, the basket allocation calculation processing unit 110 will be described in more detail.
As shown in FIG. 1, the basket allocation calculation processing unit 110 includes a search calculation processing unit 111, a search calculation data storage unit 112, and a model evaluation unit 113 in order to perform a basket allocation calculation process (search calculation process). The search calculation processing unit 111 performs a car assignment calculation process based on the virtual call list determined by the parameter determination unit 129 in the learning management unit 120 and the information from the car stop information storage unit 141 and the car information detection unit 144. Do. The search calculation data storage unit 112 stores data related to the basket allocation calculation process.

  The search calculation processing unit 111 receives the hall call information from the hall call detection unit 142 at a timing at which calculation is possible. For example, the basket allocation calculation processing unit 110 receives new hall call information after the basket allocation calculation process for a certain hall call is completed. The search calculation processing unit 111 receives hall call information from the hall call detection unit 142, receives information stored in the car stop information storage unit 141, and further receives car information from the car information detection unit 144. The basket allocation calculation processing unit 110 performs a basket allocation calculation process based on the received information and the virtual call list determined by the learning management unit 120, and allocates the basket assigned to the hall call detected by the hall call detection unit 142. To decide.

  More specifically, the search calculation processing unit 111 obtains a floor patrol schedule for each car from the car information, the car call information, and the hall call assignment information, and obtains model data that is a set of the floor patrol schedule for each car. Generate. Further, the search calculation processing unit 111 obtains a traveling schedule for each car based on the virtual call list and adds it to the model data. The model evaluation unit 113 evaluates model data that is sequentially updated to obtain an evaluation value. As an example, the evaluation value is a non-response time, that is, a time difference between the time of arrival of a car at an arbitrary floor and the time of occurrence of a hall call that causes a car stop to the arbitrary floor. Search calculation processing unit 111 determines an elevator car to be assigned to the hall call based on the evaluation value.

  The basket allocation calculation processing unit 110 determines a basket 16X (X = 1, 2,..., M) allocated to the hall call. Here, as an example, it is assumed that the basket 161 is assigned to the hall call. The basket allocation calculation processing unit 110 notifies the hall control unit 151 corresponding to the determined basket 161 of the hall call allocation. The hall call assignment notification includes, for example, the hall call generation floor (stopped floor) and the hall call direction. The basket control unit 151 performs control so that the basket 161 is guided to the generation floor according to the hall call assignment notification. More specifically, the car control unit 151 includes a hall call already assigned to the car 161, a car call generated by pressing the car call button 171 in the car 161, car position information, and a system. The car's floor patrol order is uniquely determined based on the car state information defined in step (stopped, moving, door open, etc.), and the car 161 is autonomously controlled according to the determined car's floor patrol order. . Similarly to the basket control unit 151 described above, the basket control units 152 to 15M control the operations of the cages 162 to 16M, respectively.

The virtual call list will be described with reference to FIG.
The virtual call list is a list of virtual call sets. In FIG. 2, L virtual call sets are listed. The virtual call set includes information on hall calls that are expected to occur later and cage calls that are derived therefrom. More specifically, the virtual call set includes a call set ID, virtual hall call information (virtual hall call information), and cage call information derived from the virtual call (derived car call information). Including. The virtual hall call information includes “occurrence time (current time is 0 second)”, “occurrence floor”, and “occurrence direction (hall call direction)”. The derived basket call information includes one or more “target floor (destination floor)”. In FIG. 2, the virtual call list stores a plurality of virtual call sets. However, the virtual call list may not be in the form of a virtual call set but may describe only virtual hall call information. In this case, the search calculation processing unit 111 includes a cage call determination unit (not shown) that obtains derived cage call information from the virtual hall information, and at the time of the search calculation process or when a new virtual call list is selected, The derived car call information is obtained from the hall call information. For example, the cage call determination unit may obtain the derived cage call information by inputting the virtual hall call information into a function prepared in advance, or may obtain the derived cage call information at random.

  In the virtual call list, there is a virtual space between floors where demand is expected to increase due to past operation record data and characteristics of tenants in the building, or between floors where service is to be improved. Include multiple call sets. In the elevator group management apparatus of this embodiment, a plurality of such virtual call lists are prepared in advance as shown in FIG. The parameter determination unit 129 described later selects an appropriate virtual hall call list from the plurality of virtual hall call lists according to the traffic demand, and sends the virtual hall call list to the search calculation processing unit 111.

  Upon receiving the hall call information from the hall call detection unit 142, the search calculation processing unit 111 generates the derived cage call information by predicting the cage call derived from the hall call in the received hall call information. That is, the search calculation processing unit 111 has a car call prediction function for predicting a derived car call from a hall call. For example, the search calculation processing unit 111 may obtain hall car call information by inputting hall call information into a function prepared in advance, or may obtain cargo information at random. The search calculation processing unit 111 generates a call set including a set of the received hall call information and the generated derived cage call information. Further, the search calculation processing unit 111 adds the virtual call list selected by the parameter determination unit 129 to the call set to generate an allocation target call list. The virtual call list No. shown in FIG. FIG. 4 shows an example of the allocation target call list to which call sets are added.

  The search calculation processing unit 111 searches for an optimal basket allocation pattern (basis temporary allocation pattern) for a plurality of call sets included in the allocation target call list (a virtual call set is also simply referred to as a call set). Execute the process. The search calculation processing unit 111 determines a basket to be allocated to the hall call detected by the hall call detection unit 142 based on the temporary basket allocation pattern found by the search calculation process. The search calculation processing unit 111 notifies the hall control allocation (for example, the basket control unit 151) corresponding to the determined basket (for example, the cage 161) of hall call allocation.

Next, the learning management unit 120 will be described in detail.
As shown in FIG. 1, the learning management unit 120 includes an elevator control result acquisition unit 121, an elevator performance case totaling unit 122, a feature amount extraction unit 123, a traffic demand determination unit 124, a performance case storage unit 125, and a control method storage unit. 126, a control method evaluation unit 127, a relearning determination unit 128, and a parameter determination unit 129.

  The elevator control result acquisition unit 121 acquires operation data from the hall call detection unit 142, the car call detection unit 143, and the car information detection unit 144. For example, the elevator control result acquisition unit 121 receives, from the car information detection unit 144, car information, for example, load information indicating the loading load and the getting-off load for each direction and at each floor at a predetermined sampling interval. Get as. The elevator performance case totaling unit 122 totals the operation data acquired by the elevator control result acquisition unit 121 and stores the totaled operation data in the performance case storage unit 125. The operation data includes an average non-response time for each floor, an average non-response time for the entire building, and the like. The operation data may further include a log such as a time when the traffic demand determination unit 124 detects the transition of the traffic demand and a control method used for the traffic demand after the transition.

  The feature amount extraction unit 123 receives the cage information from the cage information detection unit 144, and extracts feature amounts for determining traffic demand from the received cage information. The cage information may be sent from the cage information detection unit 144 to the feature amount extraction unit 123 via the elevator control result acquisition unit 121.

  The traffic demand determination unit 124 determines the traffic demand of the elevator generated in the building based on the feature amount extracted by the feature amount extraction unit 123. The control method storage unit 126 holds a traffic demand template in which one or more control method candidates are described in association with each of a plurality of reference traffic demands. In the control method storage unit 126, the reference traffic demand is referred to by the traffic demand determined by the traffic demand determination unit 124, and the control method according to the traffic demand is notified to the parameter determination unit 129.

  A parameter determination unit (also referred to as a control method acquisition unit) 129 acquires a control method (virtual call list) from the control method storage unit 126, and sets a control parameter corresponding to this control method in the basket allocation calculation processing unit 110.

  Based on the operation data stored in the performance example storage unit 125, the control method evaluation unit 127 is optimal for each reference traffic demand among control method candidates associated with each reference traffic demand in the traffic demand template. The correct control method. When the re-learning determination unit 128 detects that the performance of the control method determined by the control method evaluation unit 127 has deteriorated, the re-learning determination unit 128 determines the control method optimal for the reference traffic demand again. Notify

Hereinafter, the operation of the learning management unit 120 will be described in detail.
The traffic demand in a building can be classified into several typical patterns regardless of the building use. As a feature of elevator traffic demand, users often go through a floor where many uses are expected, such as a lobby floor (reference floor) where the entrance of a building is located or a dining room floor where a restaurant is located. The traffic demand determination unit 124 is based on information on the standard floor (for example, boarding probability and boarding probability of the standard floor), information on a specific floor (for example, boarding probability and boarding probability of the dining hall), and the number of elevator users. To determine traffic demand.

  Generally, elevator traffic demand is expressed by OD (Origin Destination). The OD is a record of how many floors an elevator user has moved from within a certain period. For a building with N floors, OD is represented by an OD table of an N × N matrix. As an example, the sum total of each row of the OD table indicates the number of passengers on each floor, and the sum total of each column of the OD table indicates the number of passengers getting off on each floor. The total number of passengers on each floor or the total number of persons getting off on each floor indicates the total number of elevator users in a certain period. Moreover, when OD is divided by the number of elevator users, a state transition matrix per person for a certain period is obtained. That is, OD is obtained by multiplying the state transition matrix by the total number of elevator users. The sum of each row of the state transition matrix represents the elevator user's boarding probability of each floor, and the sum of each column represents the elevator user's getting-off probability of each floor.

  However, in practice, it is difficult to accurately obtain the OD in the elevator of the up / down button system. In order to accurately measure the OD, it is necessary to input destination floor information in advance for each user as in DCS (Destination Control System) or attach an IC tag to the user.

  In the present embodiment, the traffic demand is expressed by a feature vector having, as elements, the boarding probability and the getting-off probability of each floor and the number of users in the vertical direction. In the case of an N-floor building, the traffic demand is expressed by a (4N + 1) -dimensional feature vector.

In such a feature vector, each element of the vector is a non-negative continuous value. As an example, in a 16-story building, when the boarding and getting-off probability is classified in 10% increments and the number of users is classified in increments of 100 in the range from 0 to 3000, the feature vector is about 3 × 10 ¹³ traffic demands can be expressed. However, it is not easy to prepare an optimal control method for all these traffic demands, and it is considered impossible to apply to an actually operated elevator due to the problem of computational resources. For this reason, in the present embodiment, the number of traffic demands to be classified is reduced by making use of the characteristics of elevator traffic demand.

Traffic demand varies from building to building, but can be broadly classified into time when going to work, leaving work, normal time, first half of lunch, mid-lunch, second half of lunch, concentrated on specific floors, and off-roads.
The traffic demand at the time of going to work is the traffic demand in which the number of users getting on from the reference floor (for example, the first floor with the entrance / exit) occupies most of the total number of users. The traffic demand at the time of leaving the office is the traffic demand in which the number of users getting off the standard floor accounts for the majority of the total number of users. The traffic demand in normal times is a traffic demand in which traffic demands at the time of going to work and leaving work are mixed, and the traffic demand that occupies the majority of the total number of users through the reference floor. The traffic demand at lunch (first half of lunch, mid-lunch, and late half of lunch) is different from the traffic demand at work, when leaving work, and during normal times. It is. The traffic demand when a specific floor is concentrated is a traffic demand where users concentrate on a specific floor. Moreover, the traffic demand at the time of quiet is a traffic demand with few users.

When the above traffic demand is classified in consideration of a standard floor and a specific floor such as a cafeteria floor, it is as follows.
(A) Traffic demand characterized by users who pass through the standard floor: At work, at work, during normal times (B) By users who pass through the standard floor and users through specific floors other than the standard floor Characterized traffic demand: first half of lunch, mid-lunch, second half of lunch, concentration on specific floors (C) Traffic demand characterized by the number of users ... during off-peak hours For example, when going to work, leaving work, lunch, and off-time Traffic demand for the total number of people getting on the rising cage (number of people climbing the basket) and the number of people getting off the rising cage (number of people getting on the rising cage) (number of people using the rising cage) The number of passengers) and the total number of passengers who descend from the descending car (the number of descending car passengers) (the number of ascending car users) is detected, and the number of users obtained from the ascending car users and descending car users, and Increase basket number of users and from the lowered cage ridership bias, it can be classified. However, when simply detecting the number of climbing cage users and the number of descending cage users, the information for each floor is reduced, so the number of climbing cage users and the number of descending cage users are balanced. Sometimes it is not possible to classify traffic demands, and it is not possible to classify traffic demands when a specific floor is concentrated.

  In the present embodiment, the traffic demand is expressed by a feature vector having elements of boarding probability and getting-off probability for each floor in addition to the number of ascending car users and the number of descending car users. In this embodiment, a plurality of feature vectors characterized by the state transition matrix and the number of users are prepared for each of the eight traffic demands described above, and the traffic demand is identified by template matching.

  (A) The traffic demand (at work, at work, during normal times) that is characterized by the user who passes through the reference floor will be described. The traffic demand feature vector described above is a (4N + 1) -dimensional vector, but there are few users who do not go through the reference floor during work, at work, during normal times, and the like. Therefore, the number of dimensions of the feature vector used to determine the traffic demand at the time of going to work, leaving work, and normal times is further reduced, and expressed as a three-dimensional vector of the standard floor boarding probability, the standard floor getting off probability, and the number of users. To do.

  In FIG. 5, the three coordinate axes respectively indicate the reference floor boarding probability, the reference floor getting-off probability, and the number of users. In FIG. 5, a plane including the reference floor boarding probability axis and the reference floor getting-off probability axis is divided into a plurality of regions by line segments parallel to the respective axes. This coincides with dividing the standard floor boarding probability and the standard floor boarding probability by a plurality of threshold values. FIG. 5 shows an example in which the thresholds set for the standard floor boarding probability and the standard floor boarding probability are both 0.25 and 0.5, but the threshold value and number are limited to this example. It is not a thing.

  In FIG. 5, the number of users per hour is divided in increments of 300. The step size related to the number of users can also be set arbitrarily. In this way, a plurality of three-dimensional spaces are formed by a polygonal column having a divided area of a plane including the axis of the standard floor boarding probability and the axis of the standard floor boarding probability as the bottom surface and a constant step width of the axis of the number of users as the height. Divided into regions. Each area represents one traffic demand.

  In this way, by using feature vectors created from the standard floor boarding probability, standard floor boarding probability, and the number of users, when there are few users on floors other than the standard floor at work, leaving work, and normal times Can cover all traffic demands.

  Next, (B) the traffic demand characterized by the user who goes through the reference floor and the user who passes through a specific floor other than the reference floor will be described. The traffic demand in (B) will be described by dividing it into (B-1) traffic demand in the first half of lunch, mid-lunch, traffic demand in the second half of lunch, and (B-2) traffic demand at the time of concentration on a specific floor.

  First, (B-1) traffic demand in the first half of lunch, mid-lunch, and late lunch will be described. In the first half of lunch, mid-lunch, and late-lunch, users are concentrated on the cafeteria floor in addition to the standard floor. In this case, even if a method similar to the above method is used, there is a possibility that the traffic demand cannot be accurately determined because there is insufficient information regarding the dining room floor.

  Traffic demand in the first half of lunch, mid-lunch, and late half of lunch is a feature vector with the sum of the probability of getting on the standard floor and the probability of getting on the canteen floor, the sum of the probability of getting off the standard floor and the probability of getting off the canteen, and the number of users Is represented by At this time, as shown in FIG. 6, a space similar to the three-dimensional space used for determination of traffic demand at the time of going to work, at the time of leaving work, and during normal times is generated.

  In FIG. 6, the three-dimensional space is expressed by three axes: the total of the standard floor boarding probability and the dining room floor boarding probability, the total of the standard floor boarding probability and the dining room floor boarding probability, and the total number of users. By preparing a plurality of threshold values as described above, a plane including the total axis of the standard floor boarding probability and the dining room floor boarding probability, and the axis including the standard floor boarding probability and the total floor boarding probability is divided into a plurality of regions. be able to. And like FIG. 5, it can divide | segment into the area | region of a polygonal column by providing a fixed step size with respect to the axis | shaft of the number of users.

  (B-2) The traffic demand when a specific floor is concentrated will be described.

  When users are concentrated on specific floors other than the standard floor and cafeteria floors, express them on a space where traffic demand can be expressed during work, leaving work, normal, early lunch, mid-lunch, and late lunch. I can't. In determining traffic demand when a specific floor is concentrated, a criterion for determining that users are concentrated on the specific floor is required. In this embodiment, when the boarding probability or the getting-off probability of a specific floor is calculated to be 0.25 or more, it is determined that the traffic demand is when the specific floor is concentrated. The threshold is set to 0.25, for example, and it is determined whether or not there is a floor that is equal to or higher than the threshold among boarding probabilities or getting-off probabilities of floors other than the reference floor and the restaurant floor. The traffic demand at the time of specific floor concentration may occur regularly depending on the building, but it is unpredictable for most building applications, so when going to work, leaving work, normal, early lunch, mid-lunch, No distinction is made as in the latter half of lunch.

  (C) The traffic demand characterized by the number of users (traffic demand during quiet periods) will be described. The quiet time is when there are few users. Whether or not it is a traffic demand in a quiet time is determined by the number of users without making a determination based on the boarding probability or the getting-off probability of each floor.

  The feature quantity extraction unit 123 extracts feature quantities related to the user's getting on and getting off from the cage information detected by the basket information detection unit 144, and the traffic demand determination unit 124 is the feature obtained by the feature quantity extraction unit 123. Based on the quantity, it classifies like the above (A), (B) and (C), and determines the traffic demand generated in the building.

  The feature amount extraction unit 123 uses the information on the boarding load and the getting off load for each direction and each floor obtained from the car information detection unit 144 at a certain sampling interval, Estimate the number of people getting off. The estimated number of passengers and the estimated number of people getting off can be obtained by dividing the boarding load and the getting-off load by an average weight per person, for example, 65 kg. Subsequently, the feature amount extraction unit 123 calculates the estimated number of users by adding the estimated number of passengers and the estimated number of people getting off. Although the number of passengers and the number of people getting off are ideally the same, the timing for measuring the number of passengers and the timing for measuring the number of people getting off are different because of the characteristics of the elevator operation, so they are rarely the same. However, when the traffic demand is steady, i.e., when the same traffic demand continues for a certain period, the number of passengers and the number of people getting off will be measured. It can be thought that it will be the same. In this embodiment, the average value of the number of passengers and the number of people getting off is used as the number of users at the sampling time.

  With reference to FIGS. 7A to 7D, the procedure for calculating the feature vector will be specifically described. FIGS. 7A to 7D show an example in which the feature vector is calculated from the data of the in-car load obtained in 1 minute from 6:50. In this example, a building having four floors is assumed.

  The feature amount extraction unit 123 receives data on the boarding load and the getting off load at predetermined sampling intervals, for example, every minute, for each direction and for each floor. In FIG. 7A, the load in the rising cage is increased by 1040 kg on the first floor, increased by 65 kg on the second floor, increased by 130 kg on the third floor, and increased by 0.004 kg on the fourth floor. Moreover, the load in the rising cage is reduced by 0.008 kg on the first floor, 65.01 kg on the second floor, 65.01 kg on the third floor, and 130 kg on the fourth floor. The load in the descending cage is increased by 65 kg on the fourth floor, increased by 65 kg on the third floor, increased by 65 kg on the second floor, and increased by 0.01 kg on the first floor. Further, the load in the lowering cage is reduced by 0.002 kg on the fourth floor, 65.01 kg on the third floor, 65.01 kg on the second floor, and 975 kg on the first floor.

  The feature quantity extraction unit 123 divides the boarding load and the getting-off load for each direction and for each floor by the average weight of one adult, for example, 65 kg, and obtains the estimated number of passengers and the number of getting-off persons for each direction and for each floor. In FIG.7 (b), it is estimated that 16 persons boarded from the 1st floor and 1 person boarded from the 2nd floor, and 2 persons boarded from the 3rd floor. In addition, it is estimated that one person got off at the second floor and one person at the third floor from the rising basket. In addition, it is estimated that one person entered the descending cage from the fourth floor, one person from the third floor, and one person from the second floor. Furthermore, it is estimated that 1 person got off at the 3rd floor and 1 person got off at the 2nd floor and 15 people got off at the 1st floor from the descending basket.

  Therefore, the number of passengers within this sampling interval is estimated to be 22 people, which is the sum of the estimated number of passengers in the rising cage and the estimated number of passengers in the downward cage. In addition, the number of people getting off within this sampling interval is estimated to be 21 people, which is the sum of the number of people getting off the rising car and the number of people getting off the down car.

  Subsequently, the feature amount extraction unit 123 divides the estimated number of passengers and the estimated number of people getting off for each direction and for each floor by the estimated number of passengers and the estimated number of people getting off, respectively, as shown in FIG. Get a boarding probability and a boarding probability for each floor. In addition, the feature amount extraction unit 123 calculates an average value of the estimated number of passengers and the estimated number of people getting off, and sets this average value as the estimated number of users. In this example, the estimated number of users is calculated as 21.5.

  Furthermore, the feature amount extraction unit 123 encodes the boarding probability and the getting-off probability for each direction and for each floor using a preset threshold, that is, binarizes. This threshold is defined as θ1. In this example, the threshold value θ1 is set to 0.25. In this encoding process, “0” is assigned when each of the boarding probability and the getting-off probability for each direction and each floor is equal to or less than the threshold value θ1, and “1” is assigned when the threshold value θ1 is exceeded. FIG. 7D stores encoded data and estimated number of users for each direction and for each floor. The feature quantity extraction unit 123 creates a 4 × 4 + 1 = 17-dimensional feature vector from the data in FIG.

  In addition, the feature quantity extraction unit 123 is configured to distinguish the traffic demand related to the reference floor (in this example, the first floor) in detail, with reference floor boarding probabilities regarding the rising cage (in FIG. 7C, upward and first floor boarding). ) And the reference floor getting-off probability for the descending cage (the column specified by the downward and first-floor boarding in FIG. 7C) using one or more threshold values larger than the above-described threshold value θ1. Turn into. As an example, two threshold values θ2 and θ3 are prepared in advance, one threshold value θ2 is preset to 0.5, and the other threshold value θ3 is set to 0.75. 8 (a), (b), and (c), the threshold value θ1, θ2, and θ3 respectively indicate the reference floor boarding probability for the rising cage and the reference floor unloading probability for the falling cage shown in FIG. 7 (c). Results are shown.

  Furthermore, in order to distinguish traffic demand during lunch in detail, the feature amount extraction unit 123 adds the standard floor boarding probability and the dining hall floor (for example, the third floor) boarding probability, and the standard floor boarding probability and the dining room floor boarding probability. And the total boarding probability and the total boarding probability are encoded using a preset threshold value. This threshold is set to θ4. As an example, the threshold value θ4 is set to 0.5. The threshold value θ4 and the above-described threshold values θ1, θ2, and θ3 can be changed from the outside by an input device (not shown).

  FIGS. 9A to 9D show an example of encoding the total of the standard floor boarding probability and the dining room floor boarding probability, and the total of the standard floor boarding probability and the dining room floor boarding probability. As illustrated in FIG. 9A, the feature amount extraction unit 123 receives data on boarding loads and getting-off loads for each direction and for each floor. As shown in FIG. 9B, the feature quantity extraction unit 123 divides the boarding load and the getting-off load for each direction and for each floor by the average weight of one adult, and estimates the estimated boarding for each direction and for each floor. Get the number of people and the estimated number of people getting off. As shown in FIG. 9 (c), the feature quantity extraction unit 123 divides the estimated number of passengers and estimated number of passengers for each direction and for each floor by the estimated number of passengers and estimated number of passengers, respectively. Get the boarding probability and boarding probability for each floor.

  Furthermore, the feature amount extraction unit 123 calculates the average value of the estimated number of passengers and the estimated number of people getting off, and sets the calculated average value as the estimated number of users. In FIG. 9C, the total of the standard floor boarding probability and the dining hall floor (third floor) boarding probability is 0.934, and the total of the standard floor boarding probability and the dining hall boarding probability is 0.911. FIG. 9D shows a result of encoding with the threshold θ4. Since the sum of the reference floor boarding probability and the dining room floor boarding probability and the total of the standard floor boarding probability and the dining room floor boarding probability exceed the threshold θ4, the encoded results in FIG. 9D are both “1”. It has become.

  Regarding the number of thresholds described above, P is the number of thresholds introduced to distinguish traffic demand related to the reference floor in detail, and Q is the number of thresholds introduced to distinguish traffic demand at lunch in detail. To do. In the example described above, P is 3 and Q is 1. At this time, the feature vector created for each sampling is a (4N + 2P + 2Q + 2) -dimensional vector. This feature vector consists of 4N elements for distinguishing traffic demand on each floor, 2P elements for distinguishing traffic demand via the reference floor, and 2Q elements for distinguishing traffic demand at lunch time. An element indicating an element, an element indicating a time, and an element indicating an estimated number of users; FIG. 10 shows an example of a feature vector generated from load information sampled every minute. Each row in FIG. 10 represents one feature vector. Each feature vector is expressed by encoded data of time, estimated number of users, and boarding probability and boarding probability.

  In the present embodiment, the traffic demand is determined using a (4N + 2P + 2Q + 2) -dimensional feature vector. However, the traffic demand is determined not by using a feature vector for each sampling but by a majority decision using a plurality of feature vectors. Use the generated integrated feature vector.

  The integrated feature vector is generated using the past (eg, latest) K feature vectors. The estimated number of users of the integrated feature vector is the average value of the estimated number of users of the K feature vectors. Each of the encoded data of the boarding probabilities of the integrated feature vectors is set to the larger one by comparing the number of “1” and the number of “0” for each element of the K feature vectors. Also, each of the encoded data of the unification probability of the integrated feature vector is set to be larger by comparing the number of “1” and the number of “0” for each element of the K feature vectors. In this majority decision, each element is uniquely determined to be “1” or “0” by setting K to an odd number. FIG. 11 shows an integrated feature vector generated from the feature vector of FIG. In FIG. 11, an integrated feature vector is generated every 5 minutes. For example, the integrated feature vector whose time is 6:55 is generated from five feature vectors from 6:50 to 6:54 in FIG. In the present embodiment, the traffic demand determination unit 124 determines the traffic demand based on the integrated feature vector generated by the feature amount extraction unit 123.

  Note that the feature demand extraction unit 123 may determine the traffic demand based on the feature vector generated by the feature amount extraction unit 123 without generating the integrated feature vector. Therefore, hereinafter, the integrated feature vector is simply referred to as a feature vector.

  FIG. 12 shows an example of a procedure for determining the traffic demand based on the feature vector. In step S1201, the traffic demand determination unit 124 compares the estimated number of users of the feature vector with the set value G. If the estimated number of users is smaller than the set value G, the traffic demand determination unit 124 determines in step S1206 that the traffic demand is quiet. Thereafter, in step S1205, a control method corresponding to the traffic demand during quiet periods is selected.

  If the estimated number of users is greater than or equal to the set value G in step S1201, the process proceeds to step S1202. In step S1202, it is determined whether or not “1” is stored in any element other than the reference floor with reference to the bit pattern of the boarding probability and the getting-off probability for each direction and for each floor. If there is no “1” in any element other than the reference floor, the process proceeds to step S1207, and the traffic demand determination unit 124 determines which traffic demand is at the time of going to work, at the time of leaving work, or during normal times.

  If there is an element “1” other than the reference floor in step S1202, the process proceeds to step S1203. In step S1203, it is determined whether or not “1” is stored in any element related to the cafeteria floor (for example, the third floor). When “1” is stored in any element related to the cafeteria floor in step S1203, in step S1204, the traffic demand determination unit 124 selects any of the first half of lunch, the middle of lunch, and the second half of lunch. Determine if it is traffic demand. When “1” is not stored in any element related to the cafeteria floor, in step S1208, the traffic demand determination unit 124 determines that the traffic demand is when the specific floor is concentrated. In step S1205, a control method that prioritizes hall calls generated on a specific floor is selected.

  When the traffic demand determination unit 124 determines the traffic demand in steps S1204, S1206, S1207, and S1208, the traffic demand determination unit 124 refers to the traffic demand template stored in the control method storage unit 126 and determines the control method. The control method determined by the traffic demand determination unit 124 is notified to the parameter determination unit 129.

With reference to FIG. 13, a method for determining in step S1207 which traffic demand is at the time of going to work, at the time of leaving work, or during normal times and determining a control method according to the traffic demand will be described.
FIG. 13 shows an example of a traffic demand template (data set) stored in the control method storage unit 126. As shown in FIG. 13, the control method storage unit 126 stores a traffic demand template that is divided by an upper limit and a lower limit of the number of users and expressed in a bit pattern. In the traffic demand template, one or more control method candidates (for example, control method C1, control method C2, etc.) are associated with each reference traffic demand. Each reference traffic demand is assigned an identification ID. FIG. 13 describes a bit pattern for determining traffic demand at the time of going to work, at the time of leaving work, and during normal times, but the same can be expressed for lunch. When determining the current traffic demand, the traffic demand determination unit 124 refers to the template of the control method storage unit 126 with the determined traffic demand and notifies the parameter determination unit 129 of the control method according to the current traffic demand.

  FIG. 13 shows an example in which a plurality of control method candidates are set for one reference traffic demand. However, the present invention is not limited to this, and one control method candidate for one reference traffic demand. It may be set. When a plurality of control method candidates are set, it is necessary to determine the most suitable control method for the reference traffic demand by actually operating with these control method candidates and evaluating the result. Evaluation of control method candidates is performed by the control method evaluation unit 127.

  The control method evaluation unit 127 evaluates the result of actual operation of each control method candidate set in the control method storage unit 126 for each traffic demand by sign determination, so that each reference traffic demand in the traffic demand template is evaluated. Determine the optimal control method.

With reference to FIG. 14, a method for determining a control method optimum for a certain traffic demand will be described.
In step S1401, the control method evaluation unit 127 sets an evaluation criterion for performing code determination. The control method evaluation unit 127 generates an evaluation standard by using the result obtained by operating with the same control method for each traffic demand. When generating the evaluation standard, the basket allocation calculation processing unit 110 performs a basket allocation calculation process according to a reference control method (allocation without a virtual user). If J times of operation data are obtained for each traffic demand, an average value of the operation data is set as a reference value. The operation data used for determining the control method is, for example, an average non-response time for each floor or an average non-response time for the entire building. At this time, the control method evaluation unit 127 stores the number of samples and the accumulated value.

  In step S1402, the elevator is operated according to each of the control method candidates set in the traffic demand of the control method determination target, and these operation data are totaled by the elevator performance case totaling unit 122 and stored in the performance case storage unit 125. Is done. Here, J determination data is collected for each control method candidate. The determination data indicates a result of determining whether the operation data obtained in step S1402 is better (Y) or worse (N) than the reference value set in step S1401. When J determination data is accumulated for a certain control method candidate set in the traffic demand, the control method evaluation unit 127 changes to another control method and collects the determination data. This is because the evaluation is performed by unifying the number of samples.

  When the control method evaluation unit 127 acquires J determination data for each control method candidate set in the reference traffic demand, in step S1403, the control method evaluation unit 127 counts the number of Y and N for each control method candidate. Then, the number of Y is compared, and the superiority or inferiority to the reference control method is determined by the number of Y. If the number corresponding to the rejection area with a large number of Y is observed, the control method evaluation unit 127 leaves the control method candidate as a significant control method candidate in the options. As an example, when J is 20, at a significance level of 5%, a rejection area with a large number of Y indicates a range where Y is 15 or more. If a number corresponding to the rejection area where the number of N is large is observed, the control method evaluation unit 127 deletes the control method candidate from the options. As an example, when J is 20, at a significance level of 5%, a rejection area where the number of N is large indicates a range where Y is 5 or less. The control method evaluation unit 127 suspends control method candidates that do not correspond to the rejection area and leaves them as options.

  In step S1404, if the control method candidate is determined to be superior or inferior in step S1403, if one significant control method is determined, the significant control method is regarded as the optimum control method and applied to the traffic demand. Set the method.

  If the number of significant control method candidates is not one in step S1404, in step S1405, the control method evaluation unit 127 performs control in the order in which the number of Y is larger, except for control method candidates that are inferior to the reference control method. Sort method candidates.

  In step S1406, the control method evaluation unit 127 compares the result with the previous evaluation of the control method stored in the control method storage unit 126. If the order sorted in step S1405 is the same as the previous result, in step S1407, the control method evaluation unit 127 compares the difference between the worst value and the best value, and temporarily determines the control method candidate having the smallest difference. Is set as the optimal control method. Here, the worst value indicates that the value of the operation data is the worst when operating with each control method candidate, and the best value indicates that the value of the operation data is the best when operated with each control method candidate.

  If the current result is different from the previous result in step S1406, in step S1408, the control method evaluation unit 127 selects the control method candidate with the best result this time as the reference control method. In step S1409, the control method evaluation unit 127 registers the current evaluation result in the control method storage unit 126 for later comparison. Thereafter, the process returns to step S1401 again, and a series of procedures is repeated.

  When the control method evaluation unit 127 repeats a series of procedures, the control method is finally uniquely determined. After the control method is uniquely determined for each reference traffic demand by the same procedure, the elevator can be adaptively controlled only by the traffic demand determination by the traffic demand determination unit 124.

  However, since the traffic demand template of the present embodiment reduces the OD information, even if a traffic demand corresponding to the same template is detected, it takes a long time to subtle the OD level within the same template. When there is a change, the control method selected by the control method evaluation unit 127 does not always give good performance.

  For this reason, the performance of the control method uniquely determined for the traffic demand by the control method evaluation unit 127 is always evaluated. Evaluation of performance deterioration is performed by the relearning determination unit 128. When the performance deterioration is detected, the control method evaluation unit 127 determines again the optimal control method for the traffic demand according to FIG.

  FIG. 15 schematically shows an example of the operation of the relearning determination unit 128. In step S1501, the basket allocation calculation processing unit 110 operates according to the optimal control method set in the traffic demand detected by the traffic demand determination unit 124. When the J operation data is obtained, the relearning determination unit 128 sets the average value of the operation data as a reference value. At this time, the relearning determination unit 128 stores the number of samples and the accumulated value.

  In step S1502, the relearning determination unit 128 further continues operation by the control method of step S1501, and collects J determination data. The determination data is a result of determining whether the reference value is better (Y) or worse (N).

  In step S1503, code determination is performed based on the determination data obtained in step S1502. As a result of the code determination, if it is determined that the control method is significantly inferior, the process proceeds to step S1504, and the relearning determination unit 128 notifies the control method evaluation unit 127 to perform relearning.

  When the relearning is notified, the control method evaluation unit 127 returns to the relearning return point of the traffic demand stored in the control method storage unit 126 and again determines a control method that is significant for the traffic demand. . For re-learning, the control method evaluation unit 127 stores the result of the past evaluation in the control method storage unit 126. For example, the control method evaluation unit 127 sets a point in time when the number of control method candidate options for a certain traffic demand in step S1403 is reduced to a predetermined number or less as a re-learning return point, and sets a set of options at this time as a control method storage unit 126 is stored. In relearning, a significant control scheme is determined using a set of options at the relearning return point.

  FIG. 16 schematically shows a procedure in which the learning management unit 120 sets an optimal control method for each traffic demand. In step S1601, the control method evaluation unit 127 searches for one significant control method from the control method candidates for each traffic demand, as shown in FIG. In step S1602, the control method evaluation unit 127 repeats step S1601 until one significant control method is determined for each traffic demand. When one significant control method is determined for each traffic demand, in step S1603, the relearning determination unit 128 evaluates the performance of the control method set for each traffic demand as shown in FIG. . If the relearning determination unit 128 determines in step S1604 that the performance of the control method set for a certain traffic demand has deteriorated, the relearning determination unit 128 notifies the control method evaluation unit 127 to perform relearning in step S1605.

  In this way, the learning management unit 120 can set a significant control method for each traffic demand, and can provide the basket allocation calculation processing unit 110 with a control method suitable for the detected traffic demand.

  As described above, the elevator group management device according to the present embodiment detects the traffic demand in the building, determines the control method according to the detected traffic demand, and responds to the hall call according to this control method. By deciding, it is possible to realize an elevator operation that follows the traffic demand that changes every moment. In addition, multiple control method candidates are prepared for each traffic demand, and the optimal control method for each traffic demand is determined from the control method candidates based on the operation results of the elevator, so that it can be adapted to the specific situation of the building. Elevator basket allocation control can be realized.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

DESCRIPTION OF SYMBOLS 100 ... Elevator group management part, 110 ... Basket allocation calculation process part, 111 ... Search calculation process part, 112 ... Search calculation data storage part, 113 ... Model evaluation part, 120 ... Learning management part, 121 ... Elevator control result acquisition part, 122 ... Elevator performance case totaling unit, 123 ... Feature amount extraction unit, 124 ... Traffic demand determination unit, 125 ... Performance example storage unit, 126 ... Control method storage unit, 127 ... Control method evaluation unit, 128 ... Relearning determination unit, 129 ... Parameter determination unit, 141 ... Basket information storage unit, 142 ... Hall call detection unit, 143 ... Basket call detection unit, 144 ... Basket information detection unit, 151 to 15M ... Basket control unit, 161 to 16M ... Elevator basket, 171 ˜17M: Basket call button, 181-18M ... Load detection unit, 191-19N ... Hall call button.

Claims (4)

A plurality of elevator cars that move up and down in the hoistway;
A detection unit that is provided in each of the elevator cars, detects a loading load and a getting-off load for each vertical floor and for each floor, and outputs load information;
An extraction unit for extracting feature values related to getting on and getting off from the load information;
A traffic demand determination unit that determines traffic demand based on the feature amount;
A control method storage unit that stores one or more control method candidates in association with each reference traffic demand;
A control method evaluation unit that evaluates the control method candidate based on the elevator operation performance by the control method candidate, and determines an optimal control method from among the control method candidates for each reference traffic demand;
A control method acquisition unit that acquires a control method determined for a reference traffic demand that matches the traffic demand;
According to the acquired control method, a car assignment control operation unit for assigning the elevator car,
An elevator group management apparatus comprising:   The traffic demand determination unit calculates the boarding probability and the getting-off probability for each floor and the floor from the load information, and uses the threshold prepared in advance and the boarding probability and the boarding for each floor and floor. The elevator group management apparatus according to claim 1, wherein a feature vector having a value obtained by encoding a probability as an element is generated and output as the feature amount.   The elevator group management device according to claim 2, wherein the threshold value can be changed from the outside.   The elevator according to claim 1, further comprising a performance case storage unit that stores a time when the traffic demand determination unit detects a transition of traffic demand and a control method used for the traffic demand after the transition. Group management device.

Images