A regional shared berth rolling horizon allocation method considering potential demand

Abstract

The application provides a regional shared parking rolling time domain allocation method considering potential demand, including the following steps: a parking user provides a parking destination and a parking time to a platform, the platform generates a parking request matrix in a region according to the advance reservation parking request and the time period; the platform divides the user to a shared parking lot in the region according to the parking request matrix of the parking user and generates a parking supply matrix of the shared parking lot in the region; the platform performs initial allocation of the shared parking according to the parking request reserved by the parking user and the result of the parking region division, rejects the initially allocated parking user according to the number and parking time length of the parking user to be rejected; the platform performs dynamic allocation according to the change of the road network traffic flow and the updated parking request matrix and supply matrix of the temporary reservation user in the region, and updates the parking request matrix and the supply matrix. The application effectively combines the parking demand and the parking supply through the shared parking, and improves the parking platform benefit.

Description

Technical Field

[0001] This invention relates to the field of shared parking, and more specifically to a method for rolling time-domain allocation of regional shared parking spaces that takes into account potential demand. Background Technology

[0002] With the growth of urban population and the increase in per capita car ownership, parking in urban centers has become one of the major challenges facing urban transportation. The lack of information sharing among adjacent parking lots in urban areas, and the continued FBFS (first-come, first-served) principle, fails to solve the severe imbalance between supply and demand, leading to a significant waste of parking resources, environmental pollution, and a severely diminished parking experience for users.

[0003] To improve the utilization rate of parking resources in urban centers and address the staggered parking demands, a large number of shared parking technologies have been adopted. Currently, shared parking mainly exists in two forms based on FBFS (First-Come, First-Served). One method involves users finding available parking spaces independently without prior reservation. This method offers greater user autonomy but can easily cause traffic delays in key areas and lead to confusion in user management. The other method utilizes an internet app for online pre-reservation. However, due to the lack of information sharing among shared parking lots, the limited number of shared parking spaces in each lot cannot meet the large demand. Therefore, a lottery system is used to allocate parking spaces after users fill in their information. This method is relatively fair because the allocation is random. However, since it only uses the user's reservation time for random allocation and lacks refined dynamic allocation based on other user information, the pre-fixed shared parking spaces reduce the flexibility of subsequent allocations and lower parking space utilization. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a rolling time-domain allocation method for regional shared parking spaces that considers potential demand. It utilizes historical parking data to construct shared parking areas capable of data sharing. This allows for dynamic allocation across parking lots within the area based on the optimal combination of road delays and walking distance for both pre-booked and temporary parking users. By rejecting a small number of pre-booked parking users with low time-space utilization rates in exchange for potentially high-yield users, it not only improves the overall utilization rate of parking resources within the area but also alleviates the parking supply-demand imbalance, increasing the overall revenue of the sharing platform. This invention can fully utilize parking resources, improve the utilization rate of shared parking spaces, increase the revenue of the sharing platform, and enhance the parking experience for shared parking users. It provides a rolling time-domain allocation method for regional shared parking spaces that considers potential demand, effectively combining parking demand and supply through shared parking, reducing the investment costs of parking space construction and management, and increasing the revenue of the parking platform.

[0005] The present invention achieves the above-mentioned technical objectives through the following technical means.

[0006] A method for rolling time-domain allocation of area-shared berths considering potential demand includes the following steps:

[0007] S1: The shared parking platform selects the number n of users whose parking is refused on that day and the number of users whose parking is refused based on the patterns of historical parking data. Parking duration for parking users

[0008] S2: Shared berth providers offer berth data;

[0009] S3: Parking users provide the platform with the parking destination d, the start time of parking, and the end time of parking. The platform generates a parking request matrix for the area based on the pre-booked parking request and the time period.

[0010] S4: The platform assigns users to shared parking lots within the area based on the parking request matrix of parking users. m And generate a parking supply matrix for shared parking lots within the area.

[0011] S5: The platform performs initial allocation of shared parking spaces based on parking requests made by users and the results of parking area division, and determines the number of users (n) whose parking requests are rejected and the parking duration. Reject users who are initially assigned parking spaces;

[0012] S6: The platform dynamically allocates parking spaces based on changes in road network traffic flow and the updated parking request and supply matrices of temporary reservation users within the area, and updates the parking request and supply matrices accordingly.

[0013] Furthermore, S1 includes the following steps:

[0014] S11: Parking users' parking behavior during the same time period on weekdays or holidays is used as a pattern. Based on this pattern, the platform retrieves historical parking data for the same pattern throughout the day to determine the time point t when parking demand exceeds parking supply. i , i = 1, 2, 3...I, where I represents the total number of decisions; i represents the i-th decision point;

[0015] S12: Extract the parking time proposed by all parking users in the historical parking data of the day, and combine the parking users who can be assigned to the same parking space. The number of combinations is χ.

[0016] S13: For t iParking is allocated to users on a first-come, first-served basis. The number of combined parking spaces that can be completed is χ1. Users who cannot complete the combined parking in step S12 are sorted by parking time, with a sorting cutoff of χ2, where χ2 = χ - χ1. The shortest parking time for rejected users is defined as the parking time of the first-ranked user, t. α The maximum time a user is denied parking is defined as the parking time of the user ranked χ2th, which is t. β .

[0017] Furthermore, S2 includes the following steps:

[0018] The platform receives basic data on shared parking spaces, including the time periods during which the parking spaces can be shared and the relationship between shared parking spaces and shared parking lots; variable r pt This indicates the supply status of shared berth p. If shared berth p is open during time period t, then r pt =1, otherwise 0; variable s pz This indicates the ownership relationship of shared parking space p. If shared parking space p belongs to parking lot z, then s pz =1, otherwise 0;

[0019] Let p represent the open status of shared berth p at decision point i during time period t. Then, the shared berth supply matrix for the entire day is: Since the ownership relationship between parking spaces and parking lots remains constant, the matrix of ownership relationships between all shared parking spaces and parking lots is S. P×Z =[s pz ], where p = 1, 2, ..., P; t = 1, 2, ..., T; i = 1, 2, ..., I; z = 1, 2, ..., Z, where P represents the total number of shared parking spaces, T is the total number of time periods, and Z is the total number of shared parking lots.

[0020] Furthermore, S3 includes the following steps:

[0021] Parking users provide basic information to the platform, including initial parking time, end parking time, and parking destination d; variable q mt This represents the relationship between advance parking reservation request m and time period t. If parking request m is within time period t, then q mt =1, otherwise 0; the parking request matrix for the i-th decision point is Let m represent the relationship between parking request m at decision point i and time period t, where m = 1, 2, ..., M, and M is the total number of advance parking reservation requests.

[0022] Furthermore, S4 includes the following steps:

[0023] S41: Variable w dzThis represents the walking distance between a shared parking lot z and a destination d. The distance between a single shared parking lot and a single destination is a constant. The platform generates a shared parking lot distribution matrix W. D×Z =[w dz ], where d = 1, 2, ..., D, and D is the total number of destinations within the area set by the platform;

[0024] S42: The platform updates the road network delay information near each shared parking lot in the region once at each decision point. Variable This represents the road delay near the shared parking lot z at decision point i. The road delay data received by the platform throughout the day is as follows:

[0025] S43: The platform uses the parking destination d input by the parking user and the shared parking lot distribution matrix W as input. D×Z Determine parking areas within an acceptable walking distance;

[0026] S44: The platform filters out S based on the defined parking area. P×Z The shared parking space p located in the parking area represents the daily shared parking space supply matrix. Update the supply matrix. This represents the parking space supply matrix within a parking area.

[0027] Furthermore, S5 includes the following steps:

[0028] S51: Establish decision variables for users who make advance parking reservations. This represents the relationship between parking request m from a user who pre-booked parking at decision point i and shared parking space p. If parking request m is allocated to shared parking space p, then... Otherwise, it is 0. The relationship matrix between parking requests m from users who have made advance reservations and shared parking spaces p is as follows:

[0029] S52: The platform makes dynamic decision-making allocations based on the updated supply matrix and parking user request matrix, with the goal of maximizing the overall benefits for both the platform and parking users;

[0030] S53: Establish a rejection variable for parking users after their initial allocation at decision point i (pre-booking). If the advance parking reservation request (m) fails to allocate a shared parking space (p), then... Otherwise, it is 0;

[0031] S54: The platform determines the shortest parking time t for users who refuse parking. α Longest parking time t βThe dynamic decision allocation matrix is ​​updated by calculating the number of users who refuse parking (χ²). After allocation, the supply matrix and request matrix are updated respectively.

[0032] Furthermore, S52 includes the following steps:

[0033] The formula for calculating the combined revenue of the platform and user parking costs is as follows:

[0034]

[0035] Where: C k This indicates the unit interval reservation fee for shared parking spaces; C s t represents the parking cost per unit time interval; c Indicates unit driving cost; w c Indicates the unit walking cost; v represents the average walking speed; A md This indicates the relationship between the parking request and the destination; when they match, A... md =1, otherwise A md =0; Indicates revenue from shared parking lots. This represents the cost of road delays near parking lots for parking users. μ represents the walking cost for parking users, and μ represents the overall revenue.

[0036] Determine the maximum overall return μ max The relationship matrix between parking requests m from pre-booked parking users and shared parking spaces p. and a 24-hour shared berth supply matrix And update and

[0037] Furthermore, S6 includes the following steps:

[0038] S61: When i≥2, the platform receives parking request b from a user who made a temporary parking reservation. If the parking time of temporary parking request b does not overlap with the parking time of pre-reserved parking request m in the same parking space, the platform agrees to the parking; if the times overlap, the platform rejects the parking request.

[0039] variable This represents the parking request status of a user temporarily reserving parking at decision point i. If parking request b at decision point i is within time period t, then... Otherwise, it is 0; the parking request status matrix for temporary parking reservation users throughout the day is as follows: Where b = 1, 2, ..., B;

[0040] Based on S51, establish decision variables for parking users making temporary reservations. This represents the relationship between parking request b, made temporarily at decision point i, and shared parking space p. If parking request b is allocated to shared parking space p, then... Otherwise, it is 0; the relationship matrix between parking requests b from users making temporary parking reservations throughout the day and shared parking spaces p is as follows:

[0041] S62: When i≥2, the parking requests of users who have been allocated parking spaces but have not yet started parking are 'a', and the request variables for these users are 'a'. This represents the relationship between parking request 'a' at decision point i and time period 't', and establishes a parking user request matrix that has been allocated multiple times. Where a = 1, 2, ..., A, and A represents the total number of parking requests that need to be allocated multiple times;

[0042] S63: Based on S62, establish a request matrix for parking users who have been allocated parking spaces but have not yet started parking. This represents the decision variable assigned at decision point (i-1) for parking request a at decision point (i-1). Let represent the decision variables assigned at decision point i in response to the parking request; construct the decision variable matrix assigned at decision point (i-1) in response to parking request a. Establish the decision variable matrix for parking request a at decision point i.

[0043] S64: Platform updated shared berth supply matrix based on S54 Parking User Request Matrix The system dynamically allocates parking spaces based on the combined benefits of maximizing both platform revenue and user parking costs, considering both advance and ad-hoc bookings.

[0044] S65: Update the shared parking space supply matrix for shared parking lots within the area.

[0045] Furthermore, S64 includes the following steps:

[0046] For parking users who are successfully assigned parking at decision point i, if the parking time requested by the parking user is less than or equal to the unit time interval at decision point i+1, the platform will notify the parking user to pay the parking reservation fee and the shared parking fee. The platform will then inform the parking user of the specific parking lot and parking space to complete the parking.

[0047] If a parking user requests a parking time longer than the unit time interval, the platform will notify the user to pay the parking reservation fee and wait for subsequent allocation of a decision point, specifically:

[0048] Establish parking request matrix for parking users In satisfying Generate decision variable matrix under the condition After the allocation is completed at decision point i+2, if the parking user's requested parking time is less than or equal to the unit time interval, the platform will inform the parking user of the specific parking lot and parking space to complete the parking; otherwise, the user will continue to wait.

[0049] Furthermore, S65 includes the following steps:

[0050] When i=1, the shared berth supply matrix update process is as follows:

[0051]

[0052] When i≥2, the shared berth supply matrix update process is as follows:

[0053]

[0054] The beneficial effects of this invention are as follows:

[0055] The rolling time-domain allocation method for regional shared parking spaces, which considers potential demand, as described in this invention, fully utilizes historical parking data to construct shared parking areas that can share data. It dynamically allocates parking spaces across different parking lots within the area based on the highest combined benefit from road delays and walking distance for both pre-booked and temporary users. By rejecting a small number of pre-booked users with low utilization rates of shared parking spaces in exchange for potentially high-benefit users, it not only improves the overall utilization rate of parking resources within the area but also alleviates the imbalance between parking supply and demand, increasing the overall revenue of the sharing platform. This invention fully utilizes parking resources, improves the utilization rate of shared parking spaces, increases the revenue of the sharing platform, and enhances the parking experience for shared parking users. It provides a rolling time-domain allocation method for regional shared parking spaces that considers potential demand, effectively combining parking demand and supply through shared parking, reducing the investment costs of parking space construction and management, and increasing the revenue of the parking platform. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings described below are some embodiments of the present invention. For those skilled in the art, it is obvious that other drawings can be obtained from these drawings without creative effort.

[0057] Figure 1 This is a flowchart of the regional shared berth rolling time-domain allocation method that considers potential demand as described in this invention;

[0058] Figure 2This is a schematic diagram illustrating the specific process of applying an embodiment of the present invention. Detailed Implementation

[0059] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0060] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "axial," "radial," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0061] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0062] like Figure 1 As shown, the regional shared berth rolling time-domain allocation method considering potential demand according to the present invention includes the following steps:

[0063] S1: The shared parking platform selects the number n of users whose parking is refused on that day and the number of users whose parking is refused based on the patterns of historical parking data. Parking duration for parking users Specifically:

[0064] S11: Parking users' parking behavior during the same time period on weekdays or holidays is used as a pattern. Based on this pattern, the platform retrieves historical parking data for the same pattern throughout the day to determine the time point t when parking demand exceeds parking supply. i, i = 1, 2, 3...I, where I represents the total number of decisions; i represents the i-th decision point;

[0065] S12: Extract the parking time proposed by all parking users in the historical parking data of the day, and combine the parking users who can be assigned to the same parking space. The number of combinations is χ.

[0066] S13: For t i Parking is allocated to users on a first-come, first-served basis. The number of combined parking spaces that can be completed is χ1. Users who cannot complete the combined parking in step S12 are sorted by parking time, with a sorting cutoff of χ2, where χ2 = χ - χ1. The shortest parking time for rejected users is defined as the parking time of the first-ranked user, t. α The maximum time a user is denied parking is defined as the parking time of the user ranked χ2th, which is t. β .

[0067] S2: Shared berth providers offer berth data, specifically:

[0068] The platform receives basic data on shared parking spaces, including the time periods during which the parking spaces can be shared and the relationship between shared parking spaces and shared parking lots; variable r pt This indicates the supply status of shared berth p. If shared berth p is open during time period t, then r pt =1, otherwise 0; variable s pz This indicates the ownership relationship of shared parking space p. If shared parking space p belongs to parking lot z, then s pz =1, otherwise 0;

[0069] Let p represent the open status of shared berth p at decision point i during time period t. Then, the shared berth supply matrix for the entire day is: Since the ownership relationship between parking spaces and parking lots remains constant, the matrix of ownership relationships between all shared parking spaces and parking lots is S. P×Z =[s pz ], where p = 1, 2, ..., P; t = 1, 2, ..., T; i = 1, 2, ..., I; z = 1, 2, ..., Z, where P represents the total number of shared parking spaces, T is the total number of time periods, and Z is the total number of shared parking lots.

[0070] S3: Parking users provide the platform with the parking destination d, start time, and end time. The platform generates a parking request matrix for the area based on the pre-booked parking requests and time periods, specifically:

[0071] Parking users provide basic information to the platform, including initial parking time, end parking time, and parking destination d; variable q mtThis represents the relationship between advance parking reservation request m and time period t. If parking request m is within time period t, then q mt =1, otherwise 0; the parking request matrix for the i-th decision point is Let m represent the relationship between parking request m at decision point i and time period t, where m = 1, 2, ..., M, and M is the total number of advance parking reservation requests.

[0072] S4: The platform assigns users to shared parking lots within the area based on the parking request matrix of parking users. m And generate a parking supply matrix for shared parking lots within the area. It has the following characteristics:

[0073] S41: Variable w dz This represents the walking distance between a shared parking lot z and a destination d. The distance between a single shared parking lot and a single destination is a constant. The platform generates a shared parking lot distribution matrix W. D×Z =[w dz ], where d = 1, 2, ..., D, and D is the total number of destinations within the area set by the platform;

[0074] S42: The platform updates the road network delay information near each shared parking lot in the region once at each decision point. Variable This represents the road delay near the shared parking lot z at decision point i. The road delay data received by the platform throughout the day is as follows:

[0075] S43: The platform uses the parking destination d input by the parking user and the shared parking lot distribution matrix W as input. D×Z Determine parking areas within an acceptable walking distance;

[0076] S44: The platform filters out S based on the defined parking area. P×Z The shared parking space p located in the parking area represents the daily shared parking space supply matrix. Update the supply matrix. This represents the parking space supply matrix within a parking area.

[0077] S5: The platform performs initial allocation of shared parking spaces based on parking requests made by users and the results of parking area division, and determines the number of users (n) whose parking requests are rejected and the parking duration. The following applies to users who are initially assigned parking spaces:

[0078] S51: Establish decision variables for users who make advance parking reservations. This represents the relationship between parking request m from a user who pre-booked parking at decision point i and shared parking space p. If parking request m is allocated to shared parking space p, then... Otherwise, it is 0. The relationship matrix between parking requests m from users who have made advance reservations and shared parking spaces p is as follows:

[0079] S52: Based on the updated supply matrix and parking user request matrix, the platform makes dynamic decision-making allocations with the goal of maximizing the overall revenue of both the platform and parking users. The formula for calculating the overall revenue of the platform and the parking costs of users is as follows:

[0080]

[0081] Where: C k This indicates the unit interval reservation fee for shared parking spaces; C s t represents the parking cost per unit time interval; c Indicates unit driving cost; w c Indicates the unit walking cost; v represents the average walking speed; A md This indicates the relationship between the parking request and the destination; when they match, A... md =1, otherwise A md =0; Indicates revenue from shared parking lots. This represents the cost of road delays near parking lots for parking users. μ represents the walking cost for parking users, and μ represents the overall revenue.

[0082] Determine the maximum overall return μ max The relationship matrix between parking requests m from pre-booked parking users and shared parking spaces p. and a 24-hour shared berth supply matrix And update and

[0083] S53: Establish a rejection variable for parking users after their initial allocation at decision point i (pre-booking). If the advance parking reservation request (m) fails to allocate a shared parking space (p), then... Otherwise, it is 0;

[0084] S54: The platform determines the shortest parking time t for users who refuse parking. α Longest parking time t β The dynamic decision allocation matrix is ​​updated by calculating the number of users who refuse parking (χ²). After allocation, the supply matrix and request matrix are updated respectively.

[0085] S6: The platform dynamically allocates parking spaces based on changes in road network traffic flow and updated parking request and supply matrices for temporary reservation users within the area, and updates the parking request and supply matrices accordingly. This includes the following steps:

[0086] S61: When i≥2, the platform receives parking request b from a user who made a temporary parking reservation. If the parking time of temporary parking request b does not overlap with the parking time of pre-reserved parking request m in the same parking space, the platform agrees to the parking; if the times overlap, the platform rejects the parking request.

[0087] variable This represents the parking request status of a user temporarily reserving parking at decision point i. If parking request b at decision point i is within time period t, then... Otherwise, it is 0; the parking request status matrix for temporary parking reservation users throughout the day is as follows: Where b = 1, 2, ..., B;

[0088] Based on S51, establish decision variables for parking users making temporary reservations. This represents the relationship between parking request b, made temporarily at decision point i, and shared parking space p. If parking request b is allocated to shared parking space p, then... Otherwise, it is 0; the relationship matrix between parking requests b from users making temporary parking reservations throughout the day and shared parking spaces p is as follows:

[0089] S62: When i≥2, the parking requests of users who have been allocated parking spaces but have not yet started parking are 'a', and the request variables for these users are 'a'. This represents the relationship between parking request 'a' at decision point i and time period 't', and establishes a parking user request matrix that has been allocated multiple times. Where a = 1, 2, ..., A, and A represents the total number of parking requests that need to be allocated multiple times;

[0090] S63: Based on S62, establish a request matrix for parking users who have been allocated parking spaces but have not yet started parking. This represents the decision variable assigned at decision point (i-1) for parking request a at decision point (i-1). Let represent the decision variables assigned at decision point i in response to the parking request; construct the decision variable matrix assigned at decision point (i-1) in response to parking request a. Establish the decision variable matrix for parking request a at decision point i.

[0091] S64: Platform updated shared berth supply matrix based on S54 Parking User Request Matrix The system dynamically allocates parking spaces based on a comprehensive benefit strategy, balancing advance bookings and last-minute bookings, with the goal of maximizing both platform revenue and user parking costs. Specifically:

[0092] For parking users who are successfully assigned parking at decision point i, if the parking time requested by the parking user is less than or equal to the unit time interval at decision point i+1, the platform will notify the parking user to pay the parking reservation fee and the shared parking fee. The platform will then inform the parking user of the specific parking lot and parking space to complete the parking.

[0093] If a parking user requests a parking time longer than the unit time interval, the platform will notify the user to pay the parking reservation fee and wait for subsequent allocation of a decision point, specifically:

[0094] Establish parking request matrix for parking users In satisfying Generate decision variable matrix under the condition After the allocation is completed at decision point i+2, if the parking user's requested parking time is less than or equal to the unit time interval, the platform will inform the parking user of the specific parking lot and parking space to complete the parking; otherwise, the user will continue to wait.

[0095] S65: Update the shared parking space supply matrix for shared parking lots within the area.

[0096] When i=1, the shared berth supply matrix update process is as follows:

[0097]

[0098] When i≥2, the shared berth supply matrix update process is as follows:

[0099]

[0100] Please refer to Figure 2 The technical solution of the present invention will be further explained below with reference to examples:

[0101] S11. Based on the regular parking behavior of parking users during the same time period on weekdays or holidays, the platform retrieves historical parking data with similar patterns throughout the day to determine the time point t when parking demand exceeds parking supply. i =8:00.

[0102] S12. Extract the parking time requested by all parking users from the historical parking data of the day, and group the parking users who meet the conditions to be assigned to the same parking space. The number of groups is χ = 5.

[0103] S13. For users parking before 8:00 AM, allocate parking on a first-come, first-served basis. The number of combined parking spaces that can be completed is χ1 = 4. Users unable to complete the combined parking in S12 are then sorted by parking time from shortest to longest, with a sorting cutoff of χ2 = 1. χ2 = χ - χ1. The starting point for the parking time of users denied parking is defined as t.αβ =11:30, parking ends at time t βα =17:00.

[0104] S2: The platform operates from 8:00 to 18:00, with a total of 20 decision points. Initial allocation begins at 8:00, with a 0.5-hour time interval between two decision points. The daily shared berth supply matrix is ​​as follows: There are 3 shared parking lots with a total of 8 shared parking spaces within the designated area of ​​the platform. The matrix showing the relationship between all shared parking spaces and parking lots is as follows.

[0105] S3. Parking users provide the platform with three parking destinations, start and end parking times. The platform generates a parking request matrix for the area and a parking user destination request matrix, respectively.

[0106] S41: The platform will generate a matrix of shared parking lots and destinations.

[0107] S42: At each decision point, the platform updates the road network delay information near each shared parking lot within the area. (Variable) This represents the road delay near shared parking lot z at decision point i, where the road delay data received at i=1 and i=2 is...

[0108] S43: The platform uses the parking destination d input by the parking user and the shared parking lot distribution matrix W as input. D×Z Determine parking areas within an acceptable walking distance.

[0109] S44: The platform filters out S based on the defined parking area. P×Z The shared parking space p located in the parking area represents the daily shared parking space supply matrix. Update the supply matrix. It can be represented as a parking space supply matrix within a parking area.

[0110] S51: Establish decision variables for users who make advance parking reservations. This represents the relationship between parking requests m made in advance by users at decision point i and shared parking spaces p. If parking request m is assigned to shared parking space p, then... Otherwise, it is 0. The relationship matrix between parking requests m from users who have made advance reservations and shared parking spaces p is as follows:

[0111] S52: The unit walking cost and unit driving cost are both set at 50 yuan / hour. The platform makes dynamic allocation decisions with the goal of maximizing the overall revenue for both the platform and parking users. The decision variable for the first allocation is...

[0112] S53: Based on S12 and S13, considering potential demand, establish the rejection variable matrix after the initial allocation of parking users' advance reservations. The reservation made in advance by user number 3 was rejected.

[0113] S54: The platform updates the dynamic decision allocation matrix of S52 based on the allocation results of rejected users in S53. Determine whether the 9 users who have already been assigned parking spaces should continue to be assigned in the next round. Users numbered 2, 4, and 5 have started parking and do not need to participate in the next round of allocation; their shared parking spaces are now fixed. Calculate the reservation fee. Yuan, Yuanhe The parking fee is calculated as follows: Yuan, Yuanhe The reservation fee for other users who made advance parking reservations but were not near their designated parking spot is [amount missing]. Yuan, Yuan, Yuan, Yuan, Yuanhe Yuan.

[0114] S61: When i=2, the platform receives parking requests b from users making temporary parking reservations, totaling 4 new parking requests. It determines whether these temporary parking requests conflict with pre-booked parking requests. Since parking times for vehicles numbered 11, 12, 13, and 14 do not conflict with other pre-booked parking times, parking is permitted. The parking request state matrix and destination allocation matrix for users making temporary parking reservations are as follows: Based on S51, the relationship matrix between parking requests b from temporary parking users and shared parking spaces p is established as follows:

[0115] S62: When i=2, there are 6 users who have made advance reservations and need to be reassigned. Establish a parking request matrix for users who have already been assigned parking but have not yet started parking.

[0116] S63: Based on S62, establish the decision variables for parking users who have been assigned parking spaces but have not yet started parking, and assign the decision variable matrix at i=1. Establish the allocation decision variable matrix for parking request a.

[0117] S64: When i=2, the platform updates the shared berth supply matrix according to S54. Parking User Request Matrix Dynamic decision allocation is performed with the goal of maximizing the overall benefits for both the platform and parking users. The decision variables are: Where i=2 is less than one unit of decision time away from temporary reservation user number 12, and therefore does not need to participate in the next round of allocation, the parking space is fixed and shared. The reservation fee is calculated as follows: The parking fee is calculated as follows: The remaining temporary parking reservation fees for users numbered 11, 13, and 14, who did not have nearby parking spaces, were calculated as follows: Yuan, Yuanhe Yuan. When decision point i=2, the platform's total revenue is 214.08 yuan, and the combined revenue of the platform and parking users is μ=124.27 yuan.

[0118] S65: Update the shared parking space supply matrix for shared parking lots within the area.

[0119] It should be understood that although this specification is described according to various embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

[0120] The detailed descriptions listed above are merely specific illustrations of feasible embodiments of the present invention and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for rolling time-domain allocation of regional shared berths considering potential demand, characterized in that, Includes the following steps: S1: The shared parking platform selects the number of users who refuse parking on a given day based on patterns in historical parking data. and the Parking duration for parking users , ; S2: Shared berth providers offer berth data; S3: Parking users provide their parking destination to the platform. The platform generates a parking request matrix for the area based on the pre-booked parking requests and time periods, including start and end times. Parking users provide basic information to the platform, including initial parking time, end parking time, and parking destination. ;variable Indicates a request to reserve parking in advance. and time period The relationship, if parking request In time period Inner Rules Otherwise, it is 0; the parking request matrix for the i-th decision point is , This represents a parking request at decision point i. and time period The relationship, among which M represents the total number of advance parking reservation requests; S4: The platform assigns users to shared parking lots within a designated area based on their parking request matrix. And generate a parking supply matrix for shared parking lots within the area. Specifically, it includes the following steps: S41: Variables Indicates shared parking and destination The walking distance is a fixed value, and the distance between a single shared parking lot and a single destination is used to generate a shared parking lot distribution matrix on the platform. ,in , The total number of destinations within the region set for the platform; S42: The platform updates the road network delay information near each shared parking lot in the region once at each decision point. Variable Indicates a shared parking lot at decision point i. Nearby road delays; the platform receives road delay data throughout the day. ; S43: The platform receives the parking destination input by the parking user. Distribution matrix of shared parking lots Determine parking areas within an acceptable walking distance; S44: The platform filters out parking areas based on the identified parking zones. Shared parking spaces located in the parking area A full-day shared berth supply matrix Update the supply matrix. This represents a parking space supply matrix within a defined parking area. S5: The platform initially allocates shared parking spaces based on parking requests made by users and the results of parking area division, and then adjusts the allocation based on the number of users whose parking requests are rejected. and parking duration Rejecting newly assigned parking spaces involves the following steps: S51: Establish decision variables for users who make advance parking reservations. , representing the parking request of a user who pre-booked parking at decision point i. Shared parking spaces The relationship, if parking request Assigned to shared berths but Otherwise, it is 0, representing parking requests from users who have made advance parking reservations. Shared parking spaces The relation matrix is ; S52: Based on the updated supply matrix and parking user request matrix, the platform makes dynamic allocation decisions with the goal of maximizing the overall benefits for both the platform and parking users, as detailed below: The formula for calculating the combined revenue of the platform and user parking costs is as follows: ， in: This indicates the unit interval reservation fee for shared parking spaces; Parking fees are expressed as a unit of time interval; Indicates unit driving cost; This represents the cost per unit of walking. This represents the average walking speed; This indicates the relationship between parking requests and destinations; when a match is found... ,otherwise ; Indicates revenue from shared parking lots. This represents the cost of road delays near parking lots for parking users. This represents the walking cost for parking users. Indicates overall revenue; Determine the maximum overall return The parking requests of users who made advance parking reservations at that time. Shared parking spaces relation matrix and a 24-hour shared berth supply matrix and update and ; S53: Establish a rejection variable for parking users after their initial allocation at decision point i (pre-booking). If you make a parking reservation in advance Allocating shared berths Failure Otherwise, it is 0; S54: The platform determines the shortest parking time based on the refused parking user's parking time. Longest parking time and the number of users who refused parking The dynamic decision allocation matrix is ​​updated, and the supply matrix and request matrix are updated respectively after the allocation is completed; S6: The platform dynamically allocates parking spaces based on changes in road network traffic flow and the updated parking request and supply matrices of temporary reservation users within the area, and updates the parking request and supply matrices accordingly.

2. The method for rolling time-domain allocation of regional shared berths considering potential demand as described in claim 1, characterized in that, S1 includes the following steps: S11: Parking users' parking behavior during the same time period on weekdays or holidays is used as a pattern. Based on this pattern, the platform retrieves historical parking data for the same pattern throughout the day to determine the times when parking demand exceeds parking supply. , I represents the total number of decisions; i represents the i-th decision point; S12: Extract the parking times requested by all parking users from the historical parking data for the current day, and group parking users who can be assigned to the same parking space. The number of groups is [number missing]. ; S13: Yes Parking is allocated to users on a first-come, first-served basis, and the number of combined parking spaces that can be completed is [number missing]. And sort the parking users who cannot perform the combined parking in step S12 by parking time, with a sorting cutoff of [number missing]. , The shortest parking time for users who refuse parking is the parking time of the user ranked first. The maximum time for a user to refuse parking is defined as the number of times the user is ranked. The parking time for each parking user is .

3. The method for rolling time-domain allocation of regional shared berths considering potential demand as described in claim 1, characterized in that, S2 includes the following steps: The platform receives basic data on shared parking spaces, including the time periods during which the spaces can be shared and the relationship between the shared parking spaces and shared parking lots; variables. Indicates shared berths The supply status, if shared berths exist If it is open during the time period Otherwise, it is 0; variable Indicates shared berths The ownership relationship, if the berths are shared. Parking lot but Otherwise, it is 0; This indicates a shared berth at decision point i. exist If the berths are open during a specific time period, then the total daily shared berth supply matrix is ​​as follows: Based on the fixed relationship between parking spaces and parking lots, the matrix of relationships between all shared parking spaces and parking lots is as follows: ,in ; ; ; P represents the total number of shared parking spaces, T represents the total number of time periods, and Z represents the total number of shared parking lots.

4. The method for rolling time-domain allocation of regional shared berths considering potential demand as described in claim 1, characterized in that, S6 includes the following steps: S61: When At that time, the platform receives parking requests from users who have made temporary parking reservations. If a temporary parking reservation is requested Parking time and pre-booked parking request If the parking times do not overlap at the same parking space, the platform will approve the parking; if the times overlap, the parking request will be rejected. variable This indicates the parking request status of a user who temporarily reserved parking at decision point i. In time period Inside, then Otherwise, it is 0; the parking request status matrix for temporary parking reservation users throughout the day is as follows: ,in ; Based on S51, establish decision variables for parking users making temporary reservations. , representing the parking request of a user who temporarily reserved parking at decision point i. Shared parking spaces The relationship, if parking request Assigned to shared berths but Otherwise, it is 0; parking requests from users who made temporary parking reservations for the entire day. Shared parking spaces The relation matrix is ; S62: When At that time, parking requests from users who have been assigned parking spaces but have not yet started parking are... The request variable for parking users who have been assigned parking spaces but have not yet started parking is... This indicates a parking request at the i-th decision point. With time period The relationship is used to establish a parking user request matrix that has been allocated multiple times. ,in A represents the total number of parking requests that need to be allocated multiple times; S63: Based on S62, establish a request matrix for parking users who have been allocated parking spaces but have not yet started parking. This indicates the parking request at the i-th decision point. The decision variables assigned at the (i-1)th decision point, This represents the decision variable assigned at decision point i in response to the parking request; it establishes the decision variable for the parking request. Decision variable matrix assigned at the (i-1)th decision point Establish a system for handling parking requests. Decision variable matrix assigned at decision point i ; S64: Platform updated shared berth supply matrix based on S54 Parking User Request Matrix The system dynamically allocates parking spaces based on the combined benefits of maximizing both platform revenue and user parking costs, considering both advance and temporary bookings. S65: Update the shared parking space supply matrix for shared parking lots within the area. .

5. The method for rolling time-domain allocation of regional shared berths considering potential demand as described in claim 4, characterized in that, S64 includes the following steps: For parking users who are successfully assigned parking at decision point i, if the parking time requested by the parking user is less than or equal to the unit time interval at decision point i+1, the platform will notify the parking user to pay the parking reservation fee and the shared parking fee. The platform will then inform the parking user of the specific parking lot and parking space to complete the parking. If a parking user requests a parking time longer than the unit time interval, the platform will notify the user to pay the parking reservation fee and wait for subsequent allocation of a decision point, specifically: Establish parking request matrix for parking users In order to satisfy Generate decision variable matrix under the condition After the allocation is completed, at the decision point If the requested parking time is less than or equal to the unit time interval, the platform will inform the parking user of the specific parking lot and parking space to complete the parking; otherwise, the user will continue to wait.

6. The method for rolling time-domain allocation of regional shared berths considering potential demand according to claim 4, characterized in that, S65 includes the following steps: when At that time, the shared berth supply matrix update process is as follows: ， when At that time, the shared berth supply matrix update process is as follows: 。

Images