Rapid matching method for order and multi-tenant driver
By splitting the order into sub-orders and matching the drivers based on geographical location data, combining the second verification of the status judgment of the order and multi-tenant drivers, the problems of low matching efficiency and poor fairness are solved, and fast and fair matching efficiency is achieved And a good ride experience.
Patent Information
- Application Number
- CN202411351026.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-26
- Publication Date
- 2025-01-14
AI Technical Summary
The existing technology is difficult to efficiently achieve rapid matching of orders with multi-tenant drivers, resulting in low matching efficiency, poor fairness, and may affect customers' ride experience.
The main order of passengers is split into sub-orders through the scheduling and matching system, and the capacity pool is determined based on the geographical location data of the driver and passengers, and the order instruction is sent to the first matched driver to obtain the operation status data of the order process to determine whether it is necessary Secondary verification ensures that only one driver finally gets the order and achieves a fair match.
It realizes the rapid finding of drivers, ensuring that only one driver will be finalized and only matches the tenant company chosen by the passenger, improving matching efficiency and ensuring the customer's ride experience.
Smart Images

Figure CN119313072A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of order matching, and in particular to a method for quickly matching orders with multi-tenant drivers. Background Art
[0002] In recent years, with the vigorous development of online ride-hailing, more and more people have begun to choose to travel through online ride-hailing platforms. This not only provides users with a more convenient and flexible way of travel, but also brings more employment opportunities and income sources to drivers; passengers place orders for online ride-hailing through the dispatch matching system and select the tenants they want (the transportation company that provides driver capacity). After the driver confirms to accept the passenger's order, the order is matched; however, with the continuous expansion of the online ride-hailing market, the platform is facing more and more challenges, the most prominent of which is how to efficiently achieve the problem of fast matching of orders with multi-tenant drivers;
[0003] Generally speaking, when a passenger places an order for an online ride-hailing vehicle through the dispatching and matching system, there may be multiple eligible drivers in the area near the departure point for an order, but in the end only one driver can actually pick up the passenger. The passenger may choose multiple tenants when placing an order, which may cause many problems, such as: how to find a driver as quickly as possible and ensure that only one driver completes the order in the end, how to match only the company of the tenant selected by the passenger and achieve fairness to drivers of multiple tenants, a driver may be registered with multiple transportation companies but how to complete the order only once, and in addition, when the order is finally placed, whether it is necessary to judge whether the driver needs secondary verification to determine the validity of the order based on the status of the order, so as to ensure matching efficiency and ensure that it will not affect the customer's riding experience. Summary of the invention
[0004] The purpose of the present invention is to solve the problem and propose a method for quickly matching orders with multi-tenant drivers.
[0005] The present invention proposes a method for quickly matching orders with multi-tenant drivers, wherein the method performs scheduling matching on orders and multi-tenant drivers through a scheduling matching system, wherein:
[0006] When a passenger places an order, the passenger's main order is extracted and split into several sub-orders. For each sub-order, the corresponding tenant is determined according to the sub-order;
[0007] For each tenant, obtain the driver's geographic location data and the passenger's geographic location data, determine the tenant's capacity pool based on the driver's geographic location data and the passenger's geographic location data, and perform sub-order matching based on the drivers in the capacity pool;
[0008] For the first matched driver, the driver's global ID is locked, and an order instruction is sent to the driver. The order processing status data is obtained, and it is determined whether the order processing instruction needs to be sent again based on the order processing status data.
[0009] When the driver confirms the order, the driver's global ID is locked successfully and a successful matching message is sent to the passenger; if the driver fails to complete the order, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool.
[0010] Optionally, the main order is split to obtain a plurality of sub-orders, and for each sub-order, determining a corresponding tenant according to the sub-order includes:
[0011] The main order is the order corresponding to a passenger's order action. The sub-order is the order that the passenger can select multiple tenants when placing an order. An order is created for each tenant. This order is associated with the main order and is defined as a sub-order.
[0012] For each sub-order, the tenant corresponding to the sub-order is determined. The tenant is the transportation company that provides the driver's transportation capacity, and the transportation company is the online car-hailing company where the driver is registered.
[0013] Optionally, determining the transportation capacity pool of the tenant according to the geographic location data of the driver and the geographic location data of the passenger includes:
[0014] The geographic location data of each driver and the geographic location data of each passenger include a congestion coefficient and a shortest drivable distance;
[0015] The method for obtaining the congestion coefficient is:
[0016] Get the shortest drivable distance between the current driver's location and the order placement location, and get the average driving time of the vehicle in this distance, get the average speed, and get the congestion coefficient based on the average speed and the preset normal driving speed threshold. The calculation formula is: df = fg / ed×rk, where df is the congestion coefficient, fg, ed and rk are the shortest drivable distance, the average driving time of the vehicle and the preset normal driving speed threshold respectively;
[0017] The shortest drivable distance and the congestion coefficient are normalized, and the acceptable coefficient is obtained according to the normalized shortest drivable distance and the congestion coefficient. The calculation formula is: Dkl = a1 × df + a2 × fg, where Dkl is the acceptable coefficient, df and fg represent the congestion coefficient and the shortest drivable distance respectively, a1 and a2 are the proportional coefficients of the congestion coefficient and the shortest drivable distance respectively, and a1 and a2 are both greater than 0;
[0018] The acceptable coefficient is compared with the preset acceptable coefficient threshold. If the acceptable coefficient is less than the preset acceptable coefficient threshold, the driver and his vehicle are defined as vehicles that can accept orders. All the tenant's vehicles that can accept orders are used as the tenant's capacity pool, and all drivers in the capacity pool are matched with sub-orders.
[0019] Optionally, judging whether it is necessary to send the order placing instruction for a second time according to the order placing process operation status data includes:
[0020] The order process operation status data includes the network signal unavailability coefficient and the historical breach coefficient;
[0021] The method for obtaining the network signal unavailable coefficient is:
[0022] Get the actual network signal at different times during the order process, and mark the actual network signal as X 实 p , p represents the number of the actual network signal at different times during the order process, p = 1, 2, 3, 4, ..., g, g is the sequence number of the actual network signal, and g is a positive integer;
[0023] Calculate the actual network signal X at different times during the order process 实 p The standard deviation of is taken as the network signal instability coefficient WD, and the calculation formula is:
[0024]
[0025] in, The actual average value of network signals at different times during the order process is obtained by the expression:
[0026] Optionally, the network signal unavailable coefficient further includes:
[0027] The network signals whose actual network signals at different times in the order process are less than the preset minimum threshold value Fd of the effective network signals are re-marked as S a , a represents the number of actual network signals that are less than the preset minimum threshold value Fd of effective network signals, a=1, 2, 3, 4, ..., A, A is a positive integer;
[0028] Calculate the network signal failure coefficient Uj, the calculation formula is: Uj = A / g;
[0029] The signal unavailable coefficient is calculated using the following formula: Dsx = b1 × WD + b2 × Uj; wherein Dsx is the signal unavailable coefficient, and b1 and b2 represent the preset weight coefficients of the network line number instability coefficient and the network line number failure coefficient.
[0030] Optionally, the method for obtaining the historical breach coefficient is:
[0031] The driver's total number of successful orders and one-time successful orders in history are retrieved, and the historical breach coefficient is calculated using the following formula: gf = hj-tl / hj, where gf is the historical breach coefficient, hj and tl are the total number of successful orders in history and the one-time successful orders, respectively;
[0032] The network signal unavailability coefficient and the historical breach coefficient are normalized, and the secondary verification coefficient is obtained based on the normalized network signal unavailability coefficient and the historical breach coefficient. The calculation formula is: Rfx=c1×Dsx+c2×gf, where Rfx is the secondary verification coefficient, Dsx and gf represent the network signal unavailability coefficient and the historical breach coefficient respectively, c1 and c2 are the proportional coefficients of the network signal unavailability coefficient and the historical breach coefficient respectively, and c1 and c2 are both greater than 0.
[0033] Optionally, when the driver confirms the order, the driver's global ID is locked successfully and a matching success message is sent to the passenger; if the driver fails to complete the order, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool, including:
[0034] The secondary verification coefficient is compared with the preset secondary verification coefficient threshold. When the secondary verification coefficient is less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is not sent to the driver. When the secondary verification coefficient is not less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is sent to the driver.
[0035] After sending a request to the driver to confirm whether the order is successful, if the driver confirms that the order is successful, the driver's global ID is successfully locked and a matching success message is sent to the passenger;
[0036] If the driver determines that the order has not been completed, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool until the match is successful.
[0037] Beneficial effects of the present invention:
[0038] The present invention proposes a method for quickly matching orders with multi-tenant drivers, splits a main order into several sub-orders, determines the corresponding tenant for each sub-order, obtains the driver's geographic location data and the passenger's geographic location data for each tenant, determines the tenant's transportation capacity pool based on the driver's geographic location data and the passenger's geographic location data, and matches the sub-orders with the drivers in the transportation capacity pool. For the first matched driver, the driver's global ID is locked, and an order instruction is sent to the driver, and the order process operation status data is obtained. It is determined whether the order instruction needs to be sent again based on the order process operation status data. When the driver confirms After the order is placed, the driver's global ID is locked successfully and a matching success message is sent to the passenger. If the driver fails to place the order, the driver's global ID is unlocked, the current match is ignored, and the next match is made in the driver pool. In this way, the driver can be found as quickly as possible and only one driver is guaranteed to place the order. At the same time, only the company of the tenant selected by the passenger is matched, and fairness is achieved for drivers of multiple tenants. A driver may be registered with multiple transportation companies but only place an order once. In addition, when the order is finally placed, the driver is judged based on the status of the order and a secondary verification is performed to determine the validity of the order, thereby ensuring matching efficiency and not affecting the customer's riding experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The present invention will be further described below in conjunction with the accompanying drawings.
[0040] Figure 1 A flowchart of a method for quickly matching orders with multi-tenant drivers;
[0041] Figure 2 A relationship diagram between the main order and the sub-order;
[0042] Figure 3 This is the relationship diagram between the driver's global ID and the sub-tenant ID;
[0043] Figure 4 Flow chart for order matching. DETAILED DESCRIPTION
[0044] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0045] Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in the field without making any creative work shall fall within the scope of protection of the present invention.
[0046] The embodiment of the present invention provides a method for quickly matching orders with multi-tenant drivers. Figure 1 , Figure 1 A flowchart of a method for quickly matching orders with multi-tenant drivers provided by an embodiment of the present invention. The method performs scheduling matching on orders and multi-tenant drivers through a scheduling matching system, wherein:
[0047] When a passenger places an order, the passenger's main order is extracted and split into several sub-orders. For each sub-order, the corresponding tenant is determined according to the sub-order;
[0048] For each tenant, obtain the driver's geographic location data and the passenger's geographic location data, determine the tenant's capacity pool based on the driver's geographic location data and the passenger's geographic location data, and perform sub-order matching based on the drivers in the capacity pool;
[0049] For the first matched driver, the driver's global ID is locked, and an order instruction is sent to the driver. The order processing status data is obtained, and it is determined whether the order processing instruction needs to be sent again based on the order processing status data.
[0050] When the driver confirms the order, the driver's global ID is locked successfully and a successful matching message is sent to the passenger; if the driver fails to complete the order, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool.
[0051] Based on the method for quickly matching orders with multi-tenant drivers provided in an embodiment of the present invention, through the above-mentioned method, it is possible to find a driver as quickly as possible and ensure that only one driver will eventually complete the order. At the same time, only the company of the tenant selected by the passenger will be matched and fairness will be achieved for drivers of multiple tenants. A driver may be registered with multiple transportation companies but only complete an order once. In addition, when the order is finally completed, the driver is judged according to the status of the order and a secondary verification is performed to determine the validity of the order, thereby ensuring matching efficiency and ensuring that the customer's riding experience will not be affected.
[0052] In one embodiment, the main order is split into several sub-orders. For each sub-order, the corresponding tenant is determined according to the sub-order, including:
[0053] The main order is the order corresponding to a passenger's order action. The sub-order is the order that the passenger can select multiple tenants when placing an order. An order is created for each tenant. This order is associated with the main order and is defined as a sub-order.
[0054] For each sub-order, determine the tenant corresponding to it. The tenant is the transportation company that provides the driver's transportation capacity, and the transportation company is the online car-hailing company where the driver is registered.
[0055] It should be noted that if Figure 2As shown, the main order (main order) and sub-orders can be split as follows, and each tenant creates a sub-order.
[0056] In one embodiment, determining the transportation capacity pool of the tenant according to the geographic location data of the driver and the geographic location data of the passenger includes:
[0057] The geographic location data of each driver and passenger includes the congestion factor and the shortest drivable distance;
[0058] The method for obtaining the congestion coefficient is:
[0059] Get the shortest drivable distance between the current driver's location and the order placement location, and get the average driving time of the vehicle in this distance, get the average speed, and get the congestion coefficient based on the average speed and the preset normal driving speed threshold. The calculation formula is: df = fg / ed×rk, where df is the congestion coefficient, fg, ed and rk are the shortest drivable distance, the average driving time of the vehicle and the preset normal driving speed threshold respectively;
[0060] The shortest drivable distance and the congestion coefficient are normalized, and the acceptable coefficient is obtained according to the normalized shortest drivable distance and the congestion coefficient. The calculation formula is: Dkl = a1 × df + a2 × fg, where Dkl is the acceptable coefficient, df and fg represent the congestion coefficient and the shortest drivable distance respectively, a1 and a2 are the proportional coefficients of the congestion coefficient and the shortest drivable distance respectively, and a1 and a2 are both greater than 0;
[0061] The acceptable coefficient is compared with the preset acceptable coefficient threshold. If the acceptable coefficient is less than the preset acceptable coefficient threshold, the driver and his vehicle are defined as vehicles that can accept orders. All the tenant's vehicles that can accept orders are used as the tenant's capacity pool, and all drivers in the capacity pool are matched with sub-orders.
[0062] It should be noted that the shortest drivable distance and the average vehicle driving time can be obtained directly through traffic logs or other methods, and there is no specific limitation on this; in addition, the preset normal driving speed threshold and the preset acceptable coefficient threshold are set by professionals based on actual conditions, and there is no specific limitation or elaboration on this.
[0063] It should be noted that drivers enter the corresponding pool according to tenants: drivers can register in multiple tenants. Each registration in a tenant is a transport capacity. The same driver has multiple transport capacities in multiple tenants. The transport capacity pool corresponding to each tenant is isolated. When a driver registers in multiple tenants, he will generate multiple different transport capacity IDs. The transport capacity ID is unique. The transport capacity IDs of a driver in multiple tenants are different and unique. The driver dispatches the vehicle according to the tenant dimension. After dispatching the vehicle in a tenant, his geographic information will enter the corresponding tenant's transport capacity pool, so that subsequent orders can find nearby orders as soon as possible based on the geographic information. In addition, the relationship between the driver's global ID and the tenant ID is shown in the figure below. Figure 3 shown.
[0064] Divide a passenger's order into multiple sub-orders according to the tenants they have checked: Passengers can check multiple tenants when taking a taxi. A main order will be created when the passenger places an order, and each tenant they have checked will create an independent sub-order associated with the main order when creating an order.
[0065] It should be noted that for each capacity pool, each sub-order is matched separately, and each sub-order is matched with a driver independently. They are matched simultaneously and in parallel. There is no priority between multiple sub-orders when matching. Fairness among tenants is achieved through the parallel processing capabilities of computers.
[0066] In addition, when multiple passengers place an order, they may check the same tenant. The orders of multiple passengers are also independent, and the process of matching them with drivers is completely isolated. When multiple passengers place an order, multiple main orders will be generated. If they check the same tenant, each main order will generate a unique sub-order for this tenant, and matching is performed according to the sub-order dimension.
[0067] In one implementation method, the above method can screen out drivers who are truly capable of accepting orders, which not only improves the operating efficiency and service quality of the system, but also effectively protects the rights and interests of passengers and drivers, and provides more stable and efficient travel services.
[0068] In one embodiment, judging whether it is necessary to send the order placing instruction again according to the order placing process operation status data includes:
[0069] The operation status data of the order process includes the network signal unavailability coefficient and the historical breach coefficient;
[0070] The method for obtaining the network signal unavailable coefficient is:
[0071] Get the actual network signal at different times during the order process, and mark the actual network signal as X 实 p, p represents the number of the actual network signal at different times during the order process, p = 1, 2, 3, 4, ..., g, g is the sequence number of the actual network signal, and g is a positive integer;
[0072] Calculate the actual network signal X at different times during the order process 实 p The standard deviation of is taken as the network signal instability coefficient WD, and the calculation formula is:
[0073]
[0074] in, The actual average value of network signals at different times during the order process is obtained by the expression:
[0075] The network signals whose actual network signals at different times in the order process are less than the preset minimum threshold value Fd of the effective network signals are re-marked as S a , a represents the number of actual network signals that are less than the preset minimum threshold value Fd of effective network signals, a=1, 2, 3, 4, ..., A, A is a positive integer;
[0076] Calculate the network signal failure coefficient Uj, the calculation formula is: Uj = A / g;
[0077] The signal unavailable coefficient is calculated using the following formula: Dsx = b1 × WD + b2 × Uj; wherein Dsx is the signal unavailable coefficient, and b1 and b2 represent the preset weight coefficients of the network line number instability coefficient and the network line number failure coefficient.
[0078] It should be noted that the actual network signals at different times during the order-making process can be obtained in real time according to the monitoring system in the scheduling and matching system. In addition, the preset minimum threshold of the effective network signal is set by professionals according to the actual situation and is not specifically limited.
[0079] It should be noted that the greater the instability of the network signal during the order-placing process and the greater the degree to which it is less than the minimum valid network signal threshold, the more it indicates that a second verification is required for the matched driver. The reason is that if the network signal is unstable or fails frequently, the driver may not be able to confirm the order in time, or the driver may be more accidental when placing orders. Through secondary verification, it can ensure that the driver is indeed sure to place the order, thereby reducing the number of orders cancelled due to network problems, and improving the success rate of order placement and passenger satisfaction.
[0080] In one embodiment, the method for obtaining the historical breach coefficient is:
[0081] The driver's total number of successful orders and one-time successful orders in history are retrieved, and the historical breach coefficient is calculated using the following formula: gf = hj-tl / hj, where gf is the historical breach coefficient, hj and tl are the total number of successful orders in history and the one-time successful orders, respectively;
[0082] The network signal unavailability coefficient and the historical breach coefficient are normalized, and the secondary verification coefficient is obtained based on the normalized network signal unavailability coefficient and the historical breach coefficient. The calculation formula is: Rfx=c1×Dsx+c2×gf, where Rfx is the secondary verification coefficient, Dsx and gf represent the network signal unavailability coefficient and the historical breach coefficient respectively, c1 and c2 are the proportional coefficients of the network signal unavailability coefficient and the historical breach coefficient respectively, and c1 and c2 are both greater than 0.
[0083] It should be noted that the total number of successful orders and the one-time successful order number of the driver can be retrieved from the storage log system in the dispatch matching system, or other methods, which are not specifically limited.
[0084] In one embodiment, when the driver confirms the order, the driver's global ID is locked successfully and a matching success message is sent to the passenger; if the driver fails to complete the order, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool.
[0085] The secondary verification coefficient is compared with the preset secondary verification coefficient threshold. When the secondary verification coefficient is less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is not sent to the driver. When the secondary verification coefficient is not less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is sent to the driver.
[0086] After sending a request to the driver to confirm the order, if the driver confirms the order, the driver's global ID is locked successfully and a matching success message is sent to the passenger.
[0087] If the driver determines that the order has not been completed, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool until the match is successful.
[0088] It should be noted that the preset secondary verification coefficient threshold is set by professional staff based on actual conditions and is not specifically limited.
[0089] It should be noted that the benefits of the present invention are that, for passengers, they can find qualified drivers from multiple tenants they have checked as quickly as possible; for drivers, they can receive orders from passengers as quickly as possible, and there will be no situation of receiving multiple orders at the same time; for transportation companies, each transportation company is fair, and no transportation company will be given priority in dispatching orders.
[0090] It should be noted that if Figure 4 As shown in the order matching flow chart, the sub-order directly finds the capacity of the pool of the tenant corresponding to the sub-order according to the latitude and longitude of the order starting point. Because the latitude and longitude information of the capacity has been encoded, encoding the latitude and longitude of the order starting point can quickly find the capacity nearby. The sub-order first finds multiple qualified capacities at the fastest speed. The sub-order and each found capacity form a matching pair, so there will be multiple matching pairs. According to the principle of first come first served, the capacity of the first matched matching pair will lock the corresponding real driver. The matching pair that is matched later will check that the real driver of the capacity of this matching pair has been locked before and will discard this matching pair. In addition, the sub-order will stop matching after the order is confirmed, otherwise it will continue to match the next round until the order is successfully completed and the maximum matching time is reached.
[0091] It should be noted that the above-mentioned nouns are explained as follows:
[0092] Transport company: the online ride-hailing company where the driver is registered;
[0093] Tenants: Transportation companies that provide driver capacity
[0094] Order completed: The order is matched with the driver and enters the fulfillment state
[0095] Transport ID: A driver's unique ID registered with a transport company
[0096] Transport capacity: A driver registered with a transport company is called a transport capacity
[0097] Capacity pool: a common pool composed of drivers' current geographic information, one capacity pool for each tenant
[0098] Geographic information coding: Encode the latitude and longitude of the driver to facilitate the order to quickly find a driver near a certain latitude and longitude
[0099] Main order: defines the order corresponding to a passenger's order action
[0100] Sub-order: When placing an order, passengers can select multiple tenants. An order is created for each tenant, and this order is associated with the main order.
[0101] Dispatching: The driver selects a transport company with which he / she is registered and sets up the system to accept orders.
[0102] Matching pair: A combination formed by matching a sub-order with a transport capacity is called a matching pair. At this time, the order has not yet been actually confirmed.
[0103] The above is a detailed description of an embodiment of the present invention, but the content is only a preferred embodiment of the present invention and cannot be considered to limit the scope of implementation of the present invention. All equivalent changes and improvements made within the scope of the present invention should still fall within the scope of the patent coverage of the present invention.
Claims
1. A method for quickly matching orders with multi-tenant drivers, characterized in that: The method performs dispatch matching between orders and multi-tenant drivers through a dispatch matching system, wherein: When a passenger places an order, the passenger's main order is extracted and split into several sub-orders. For each sub-order, the corresponding tenant is determined according to the sub-order; For each tenant, obtain the driver's geographic location data and the passenger's geographic location data, determine the tenant's capacity pool based on the driver's geographic location data and the passenger's geographic location data, and perform sub-order matching based on the drivers in the capacity pool; For the first matched driver, the driver's global ID is locked, and an order instruction is sent to the driver. The order processing status data is obtained, and it is determined whether the order processing instruction needs to be sent again based on the order processing status data. When the driver confirms the order, the driver's global ID is locked successfully and a successful matching message is sent to the passenger; if the driver fails to complete the order, the driver's global ID is unlocked, the current match is ignored, and the next match is performed in the driver pool.
2. The method for quickly matching orders with multi-tenant drivers according to claim 1, characterized in that: The main order is split into several sub-orders. For each sub-order, the corresponding tenant is determined according to the sub-order, including: The main order is the order corresponding to a passenger's order action. The sub-order is an order that a passenger can select multiple tenants when placing an order. An order is created for each tenant. This order is associated with the main order and is defined as a sub-order. For each sub-order, the tenant corresponding to the sub-order is determined. The tenant is the transportation company that provides the driver's transportation capacity, and the transportation company is the online car-hailing company where the driver is registered.
3. The method for quickly matching orders with multi-tenant drivers according to claim 1, characterized in that: The capacity pool of the tenant is determined based on the driver's and passenger's geographic location data, including: The geographic location data of each driver and the geographic location data of each passenger include a congestion coefficient and a shortest drivable distance; The method for obtaining the congestion coefficient is: The shortest drivable distance between the current driver's location and the order placement location is obtained, and the average driving time of the vehicle in the shortest drivable distance is obtained to obtain the average speed, and the congestion coefficient is obtained according to the average speed and the preset normal driving speed threshold. The calculation formula is: df = fg / ed×rk, where df is the congestion coefficient, fg, ed and rk are the shortest drivable distance, the average driving time of the vehicle and the preset normal driving speed threshold respectively; The shortest drivable distance and the congestion coefficient are normalized, and the acceptable coefficient is obtained according to the normalized shortest drivable distance and the congestion coefficient. The calculation formula is: Dkl = a1 × df + a2 × fg, where Dkl is the acceptable coefficient, df and fg represent the congestion coefficient and the shortest drivable distance respectively, a1 and a2 are the proportional coefficients of the congestion coefficient and the shortest drivable distance respectively, and a1 and a2 are both greater than 0; The acceptable coefficient is compared with the preset acceptable coefficient threshold. If the acceptable coefficient is less than the preset acceptable coefficient threshold, the driver and his vehicle are defined as vehicles that can accept orders. All the tenant's vehicles that can accept orders are used as the tenant's capacity pool, and all drivers in the capacity pool are matched with sub-orders.
4. The method for quickly matching orders with multi-tenant drivers according to claim 1, characterized in that: Judging whether it is necessary to send the order instruction again based on the order process operation status data includes: The order process operation status data includes the network signal unavailability coefficient and the historical breach coefficient; The method for obtaining the network signal unavailable coefficient is: Get the actual network signal at different times during the order process, and mark the actual network signal as X 实 p , p represents the number of the actual network signal at different times during the order process, p = 1, 2, 3, 4, ..., g, g is the sequence number of the actual network signal, and g is a positive integer; Calculate the actual network signal X at different times during the order process 实 p The standard deviation of is taken as the network signal instability coefficient WD, and the calculation formula is: in, The actual average value of network signals at different times during the order process is obtained by the expression:
5. The method for quickly matching orders with multi-tenant drivers according to claim 4 is characterized in that: The network signal unavailable coefficient also includes: The network signals whose actual network signals at different times in the order process are less than the preset minimum threshold value Fd of the effective network signals are re-marked as S a , a represents the number of actual network signals that are less than the preset minimum threshold value Fd of effective network signals, a=1, 2, 3, 4, ..., A, A is a positive integer; Calculate the network signal failure coefficient Uj, the calculation formula is: Uj = A / g; The signal unavailable coefficient is calculated using the following formula: Dsx = b1 × WD + b2 × Uj; wherein Dsx is the signal unavailable coefficient, and b1 and b2 represent the preset weight coefficients of the network line number instability coefficient and the network line number failure coefficient.
6. The method for quickly matching orders with multi-tenant drivers according to claim 4, characterized in that: The method for obtaining the historical breach coefficient is as follows: The driver's total number of successful orders and one-time successful orders in history are retrieved, and the historical breach coefficient is calculated using the following formula: gf = hj-tl / hj, where gf is the historical breach coefficient, hj and tl are the total number of successful orders in history and the one-time successful orders, respectively; The network signal unavailability coefficient and the historical breach coefficient are normalized, and the secondary verification coefficient is obtained based on the normalized network signal unavailability coefficient and the historical breach coefficient. The calculation formula is: Rfx=c1×Dsx+c2×gf, where Rfx is the secondary verification coefficient, Dsx and gf represent the network signal unavailability coefficient and the historical breach coefficient respectively, c1 and c2 are the proportional coefficients of the network signal unavailability coefficient and the historical breach coefficient respectively, and c1 and c2 are both greater than 0.
7. The method for quickly matching orders with multi-tenant drivers according to claim 1, characterized in that: When the driver confirms the order, the driver's global ID is locked successfully and a matching success message is sent to the passenger; If the driver fails to place an order, the driver's global ID is unlocked, the match is ignored, and the next match in the driver pool includes: The secondary verification coefficient is compared with the preset secondary verification coefficient threshold. When the secondary verification coefficient is less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is not sent to the driver. When the secondary verification coefficient is not less than the preset secondary verification coefficient threshold, the secondary verification of whether the order is confirmed is sent to the driver. After sending a request to the driver to confirm the order, if the driver confirms the order, the driver's global ID is locked successfully and a matching success message is sent to the passenger. If the driver determines that the order has not been completed, the driver's global ID is unlocked, the match is ignored, and the next match is performed in the driver pool until the match is successful.