Cloud computing-based catering service platform method and system

Abstract

The application relates to the technical field of cloud computing and intelligent catering delivery scheduling, in particular to a catering service platform method and system based on cloud computing; the method obtains order, store, rider and meal quality data and carries out timestamp alignment to obtain synchronization state data; order increment ratio, store busy degree, rider arrival value and meal quality risk value are determined based on the synchronization state data, and a dispatch order matching value is output according to preset weights to form a scheduling strategy under the constraints of time, distance, load and store order receiving; and the scheduling strategy is converted into an order receiving state code, a work station task sequence, a dispatch order state code and a route selection flag bit and is issued for execution. The application can realize the consistency of order scheduling and on-site execution.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and smart catering delivery scheduling technology, specifically to a cloud computing-based catering service platform method and system. Background Technology

[0002] With the development of cloud computing and on-demand delivery services, food service platforms have gradually evolved from single order processing to comprehensive management systems that facilitate multi-store collaboration, rider dispatch, and kitchen execution. Existing platforms typically need to process order data, store status data, rider status data, and food quality-related data simultaneously. However, the sources of these data are scattered and the reporting frequency is inconsistent, which can easily lead to scheduling errors due to time misalignment and asynchronous status. However, in actual testing, existing catering scheduling methods mostly rely on coarse-grained order volume or static distance for allocation, making it difficult to simultaneously consider store capacity load, rider's actual achievable delivery time, and food quality degradation. At the same time, the scheduling results output from the cloud often lack execution mapping adapted to store edge nodes and rider terminals, making it difficult to implement strategies in a timely manner after they are issued, affecting order acceptance efficiency, food preparation coordination, and delivery stability. Summary of the Invention

[0003] The purpose of this invention is to provide a cloud-based catering service platform method and system to solve the problems in existing technologies, such as scheduling deviations caused by scattered data sources and misaligned timing, and the inability of system resource allocation to adapt to the actual measured capacity status of stores and the physical accessibility of delivery riders. To this end, the technical solution of this invention includes: A cloud-based catering service platform method includes: Acquire and align the timestamps of order data, store status data, rider status data, and food quality data corresponding to the order data, wherein the food quality data includes food temperature and humidity value of the packaging area, to obtain synchronized status data; The order increment ratio and store busyness are determined based on the synchronized status data. The system obtains the current location and historical communication trajectory of at least one candidate rider, obtains the traffic congestion index of the area corresponding to the current location, calculates the location drift of the candidate rider and the network latency from the rider terminal corresponding to the candidate rider to the cloud dispatch server, and verifies the location reliability of the candidate rider. The path distance from the current location of the candidate rider to the pickup point corresponding to the order is obtained, as well as the average moving speed, the location drift, the network latency and the traffic congestion index within a preset time window, and the rider arrival value of the candidate rider that passes the verification is determined. Based on the predicted time difference between the completion of food preparation and the rider's arrival at the pickup store, the waiting time after food preparation, the food temperature, and the humidity of the packaging area, the food quality risk value of the pending orders and the already prepared orders is determined. Obtain preset weights, and calculate the order matching value by weighting the store busyness, the rider arrival value and the food quality risk value according to the preset weights. Output the scheduling strategy under preset time constraints, distance constraints, rider load constraints and store order acceptance constraints. A set of candidate delivery routes is formed and output, and a target route is determined from the set of candidate delivery routes. The scheduling strategy is converted into an order acceptance status code, a workstation task sequence, an order dispatch status code, and a route selection flag corresponding to the target route, and then executed.

[0004] Preferably, determining the order increment ratio and store busyness includes: Obtain the current statistical time window and the historical reference window, and determine the order increment ratio based on the current statistical time window and the historical reference window. The order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window. The historical reference window is the window corresponding to the same time period of the store in the past preset number of business days N, and N is a positive integer. Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, calculate the workstation occupancy rate and inventory satisfaction rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. The key workstation is the workstation with the lowest output per unit time in the preset production process. The inventory satisfaction rate is the ratio of available inventory to estimated demand. The estimated demand is the total theoretical consumption of key ingredients included in the orders to be made within the current statistical time window. The store's busyness is determined based on the current number of orders to be processed, workstation occupancy rate, and inventory fulfillment rate. The initial value of the preset weight is a fixed coefficient value obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within a historical period. The multiple linear regression algorithm uses the workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within a historical period as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting.

[0005] Preferably, the location reliability of candidate riders is verified, and the rider arrival value of the candidate riders who pass the verification is determined, including: If the location drift of a candidate rider is less than or equal to a preset distance deviation threshold and the network latency is less than or equal to a preset time delay threshold, then the candidate rider is deemed to have passed the location reliability verification. Here, the location drift is the distance deviation between the current location coordinates and the coordinates predicted based on the historical trajectory, and the network latency is the round-trip communication latency between the rider's terminal and the cloud dispatch server. For candidate riders who pass the verification, obtain the path distance from the candidate rider's current location to the pick-up point, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window; The rider arrival value is determined based on path distance, average moving speed, location drift, network latency, and traffic congestion index. The rider arrival value is obtained by performing dimensional unification processing on path distance, average moving speed, location drift, network latency, and traffic congestion index, and then weighting and summing them according to preset weights. The preset weights include a first type of weight corresponding to the path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to the average moving speed. The signs of the first type of weights are opposite to those of the second type of weights.

[0006] Preferably, determining the risk value of food quality includes: For orders that have already been prepared, the system obtains the cumulative waiting time since the food was prepared, and uses a temperature and humidity sensor located in the food storage area to obtain the current food temperature and humidity value of the food packaging area. The food quality risk value is determined based on the waiting time, the current food temperature, and the humidity value of the food packaging area. The food quality risk value is obtained by weighting and summing the waiting time, the deviation of the current food temperature from the preset insulation temperature range, and the deviation of the humidity value of the food packaging area from the preset humidity range after unifying their dimensions.

[0007] Preferably, after the scheduling strategy is distributed to the store edge nodes and rider terminals for execution, the process also includes: Based on store status, rider status, and route information, the system predicts food preparation time, delivery time, and delivery temperature upon receipt. It receives the food preparation time and delivery temperature from the store's edge nodes, as well as the delivery time from the rider's terminal. The comprehensive error value is determined based on the first difference between the meal preparation time and the predicted meal preparation time, the second difference between the delivery time and the predicted delivery time, and the third difference between the receipt temperature and the predicted receipt temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first difference, the second difference, and the third difference according to preset weights after unifying their dimensions. If the overall error value is greater than the preset system tolerance threshold, then at least one of the following will be executed: recalculate the weight parameters of store busyness, rider arrival value and food quality risk value; Send an abnormal takeover command to the pre-configured scheduling management terminal and terminate the issuance of the current scheduling policy; otherwise, maintain the normal issuance and execution of the current scheduling policy.

[0008] Preferably, a cloud-based catering service platform system, used to execute the cloud-based catering service platform method as described in any one of claims 1 to 5, includes a cloud dispatch server and store edge nodes and rider terminals communicatively connected to the cloud dispatch server. The cloud dispatch server includes: The data acquisition module is used to acquire order data, store status data, rider status data, and food quality data, and perform timestamp alignment to obtain synchronized status data. The load assessment module is used to determine the order increment ratio and store busyness based on synchronization status data; The rider screening module is used to obtain information about candidate riders, verify the location reliability of the candidate riders, and determine the rider arrival value of the candidate riders who pass the verification based on the path distance from the candidate rider's current location to the pick-up point, average moving speed, location drift, network latency and road congestion index. The quality judgment module is used to determine the food quality risk value of pending orders based on synchronized status data. The pending orders include orders to be made and orders that have been prepared and are ready for pickup. For orders to be made, the food quality risk value is determined based on the time difference between the predicted food preparation time and the predicted rider arrival time. For orders that have been prepared and are ready for pickup, the food quality risk value is determined based on the waiting time after food preparation, the food temperature, and the humidity value of the food packaging area. The strategy output module is used to weight the store's busyness, rider arrival value and food quality risk value according to preset weights to obtain the order matching value between the order to be processed and the candidate rider, and output the scheduling strategy under at least one of the preset time constraints, distance constraints, rider load constraints and store order acceptance constraints. The instruction mapping module is used to convert the scheduling strategy into order acceptance status code, workstation task sequence, order dispatch status code and route selection flag, and send them to the store edge node and rider terminal for execution. The workstation task sequence corresponds to the execution order of each production workstation in the store, and the route selection flag corresponds to the target route in the candidate delivery route set.

[0009] Preferably, the load assessment module is used for: Obtain the current statistical time window and the historical reference window, and determine the order increment ratio based on the current statistical time window and the historical reference window. The order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window. The historical reference window is the window corresponding to the same time period of the store in the past preset number of business days N, and N is a positive integer. Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, and calculate the workstation occupancy rate and inventory fulfillment rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. The store's busyness is determined based on the current number of orders to be processed, workstation occupancy rate, and inventory fulfillment rate. The initial value of the preset weight is a fixed coefficient value obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within a historical period. The multiple linear regression algorithm uses the workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within a historical period as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting.

[0010] Preferably, the rider screening module is used for: If the location drift of a candidate rider is less than or equal to a preset distance deviation threshold, and the network latency is less than or equal to a preset time delay threshold, then the candidate rider is deemed to have passed the location reliability verification. For candidate riders who pass the verification, obtain the path distance from the candidate rider's current location to the pick-up point, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window; The rider arrival value is determined based on path distance, average moving speed, location drift, network latency, and traffic congestion index. The rider arrival value is obtained by performing dimensional unification processing on path distance, average moving speed, location drift, network latency, and traffic congestion index, and then weighting and summing them according to preset weights. The preset weights include a first type of weight corresponding to the path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to the average moving speed. The signs of the first type of weights are opposite to those of the second type of weights.

[0011] Preferably, the cloud scheduling server further includes a feedback processing module, used for: Based on store status, rider status, and route information, predict the food preparation time, delivery time, and delivery temperature; receive the food preparation time and delivery temperature from the store's edge nodes, as well as the delivery time from the rider's terminal. The comprehensive error value is determined based on the first difference between the meal preparation time and the predicted meal preparation time, the second difference between the delivery time and the predicted delivery time, and the third difference between the receipt temperature and the predicted receipt temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first difference, the second difference, and the third difference according to preset weights after unifying their dimensions. If the overall error value exceeds the preset system tolerance threshold, at least one of the following actions will be taken: recalculate the weight parameters of store busyness, rider arrival value, and food quality risk value; send an abnormal takeover command to the pre-configured dispatch management terminal and terminate the issuance of the current dispatch strategy; otherwise, maintain the normal issuance and execution of the current dispatch strategy.

[0012] Compared with the prior art, the present invention has the following beneficial effects: This invention aligns order data, store status data, rider status data, and food quality data with timestamps to form synchronized status data within the same scheduling cycle. This effectively eliminates the time misalignment problem of data reporting from various terminals, thereby improving the real-time performance and accuracy of scheduling decisions. By determining the order increment ratio and store busyness based on the current statistical time window, historical reference window, key workstation occupancy status, and available inventory of key ingredients, the actual production load status of the store can be more comprehensively represented, avoiding the backlog of orders and production workstation tasks caused by allocating based on a single-dimensional static threshold only according to the number of orders. By verifying the location credibility of candidate riders and determining their arrival value by comprehensively considering path distance, average moving speed, location drift, network latency, and road congestion index, riders with location distortion or communication abnormalities can be eliminated, improving the actual reachability of order dispatch results and avoiding assigning orders to candidate riders whose straight-line distance is less than the preset threshold but whose overall estimated arrival time exceeds the preset time limit. By determining the food quality risk value for both pre-made orders and pre-prepared orders based on predicted food preparation time, predicted rider arrival time, waiting time, food temperature, and humidity in the packaging area, the system can simultaneously consider quality degradation factors before and after food preparation, reducing food quality deterioration caused by excessive waiting time or unsuitable environment. By weighting store busyness, rider arrival time, and food quality risk value, and outputting scheduling strategies under time constraints, distance constraints, rider load constraints, and store order acceptance constraints, a synergistic balance can be achieved between store capacity, rider timeliness, and food quality. By converting scheduling strategies into order acceptance status codes, workstation task sequences, order dispatch status codes, and route selection flags, and then sending them to store edge nodes and rider terminals for execution, cloud-based decisions can be directly mapped to on-site executable instructions, solving the problem of strategy implementation difficulties in existing technologies. By transmitting measured time and delivery temperature back and calculating the comprehensive error value, and readjusting weight parameters or triggering manual intervention when the error exceeds the threshold, a closed-loop feedback correction mechanism can be formed, improving the stability and adaptability of the scheduling system under complex conditions. Attached Figure Description

[0013] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific 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, other drawings can be obtained from these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating a cloud-based catering service platform method provided in an embodiment of the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] Please see the appendix Figure 1 A cloud-based catering service platform method includes: Acquire and align timestamps of order data, corresponding store status data, rider status data, and food quality data. Food quality data includes food temperature and humidity values ​​in the packaging area to obtain synchronized status data. The order increment ratio and store busyness are determined based on synchronized status data; Obtain the current location and historical communication trajectory of at least one candidate rider, obtain the traffic congestion index of the area corresponding to the current location, calculate the location drift of the candidate rider and the network latency from the rider terminal to the cloud dispatch server, and verify the location credibility of the candidate rider. Obtain the path distance from the candidate rider's current location to the pickup point corresponding to the order, as well as the average moving speed, location drift, network latency, and road congestion index within a preset time window, and determine the rider arrival value of the candidate riders who pass the verification. Based on the predicted time difference between the completion of food preparation and the rider's arrival at the pickup store, the waiting time after food preparation, the food temperature, and the humidity of the packaging area, the food quality risk value of the pending orders and the already prepared orders is determined. Obtain preset weights, and calculate the order matching value by weighting the store's busyness, rider arrival value, and food quality risk value according to the preset weights. Output the scheduling strategy under preset time constraints, distance constraints, rider load constraints, and store order acceptance constraints. The system generates and outputs a set of candidate delivery routes, determines the target route from the set of candidate delivery routes, converts the scheduling strategy into an order acceptance status code, a workstation task sequence, an order dispatch status code, and a route selection flag for the corresponding target route, and then issues the execution order.

[0017] This embodiment provides a cloud computing-based catering service platform method applicable to multi-store takeout and collaborative delivery scenarios. The method acquires multi-source status data, comprehensively evaluates store production load, rider's measured achievable delivery time, and the degree of food quality degradation, outputs a comprehensive scheduling strategy, and converts it into discrete instructions that can be directly executed by stores and riders, ultimately achieving a high degree of consistency between order scheduling and on-site execution. Based on the above overall architecture, this embodiment breaks down the key processing steps in detail. The system acquires order data, store status data, rider status data, and food quality data. Based on a unified time base, it performs timestamp alignment on the above multi-source heterogeneous data and outputs synchronized status data. In order to solve the problem of timing misalignment caused by inconsistent reporting frequencies of multi-source heterogeneous data and network communication delays, the timestamp alignment mechanism in this embodiment is specifically implemented using a sliding window-based buffering logic: For the same scheduling period, such as a period of 60 seconds, the cloud scheduling server maintains a time buffer queue with a length equal to the period plus a preset network tolerance deviation, such as an additional 5 seconds. At the end of this cycle, the data received within the cycle is uniformly overwritten and aligned to the standard truncation timestamp of that cycle. For low-frequency update feature data with a reporting frequency lower than the scheduling cycle, such as the inventory of key ingredients in stores, a zero-order hold strategy is adopted, that is, the most recent valid data in its cache pool is extracted and the standard truncation timestamp of the current cycle is appended to it. For high-frequency update feature data with a reporting frequency higher than the scheduling cycle, such as rider's second-level GPS signal, the sampling point whose physical reception time is closest to the standard truncation timestamp of that cycle is extracted from the buffer queue. Synchronous status data refers to business snapshots with the same timestamp within the same scheduling cycle, such as order arrival rate, workstation status, and rider location within the same minute. Compared to the status misalignment caused by the independent asynchronous processing of each module in the existing system, this embodiment uses a timestamp alignment mechanism to fuse multi-source features across channels, ensuring that subsequent decisions are based on accurate slices of the same moment. This embodiment of the invention can achieve synchronous fusion of multi-terminal data based on timestamp alignment, avoiding decision distortion caused by data delays or misalignments, and ultimately solving the technical defect of the existing technology that leads to erroneous order dispatch due to the lack of a status synchronization mechanism. The system acquires store busyness, rider arrival value, and food quality risk value. Based on preset weights, it performs weighted fusion of the above indicators to determine the order matching value between the pending order and the candidate rider. Under preset constraints, it outputs the scheduling strategy and converts the scheduling strategy into order acceptance status code, workstation task sequence, order dispatch status code, and route selection flag. The order matching value is used to represent the priority of order matching with rider. To avoid insufficient interpretability in the output process of the scheduling strategy, the process of outputting the scheduling strategy under multiple constraints is implemented through explicit structured logic: The cloud scheduling server constructs a two-dimensional matrix of dispatch matching values ​​with pending orders as rows and candidate riders as columns, and performs descending iterative matching in this matrix. Each time, the current global largest dispatch matching value is selected, and it is verified whether the number of uncompleted orders of the candidate rider corresponding to the matching is less than the preset load limit, i.e., the rider load constraint, and whether the distance from the rider's current location to the pickup store is less than the preset order acceptance radius, i.e., the distance constraint. If both constraints are satisfied, the matching relationship between the order and the rider is written into the scheduling strategy, and the order row and the fully loaded rider column are removed from the matrix. The process is repeated until the orders are all assigned. The time constraint is that the estimated delivery time of the order shall not exceed the deadline required by the order; the store order acceptance constraint is that the number of orders currently pending in the store shall not exceed the store's rated maximum order acceptance capacity. The route selection flag is used to indicate the target route, such as an alternative route to avoid congestion. Compared with the shortcomings of existing cloud strategies that output continuous scores and are difficult to apply on the terminal, this invention compresses complex global strategies into discrete status codes that can be directly recognized by the terminal through an instruction mapping mechanism. The specific mapping logic is as follows: after outputting a scheduling strategy that includes store identifiers, rider identifiers and time nodes, the cloud scheduling server translates the instructions based on a preset data dictionary. For the store side, the order processing time is mapped to a specific order acceptance status code, such as 0x01 indicating immediate start of production and 0x02 indicating delayed processing. The estimated start and end times of each dish in the scheduling strategy are extracted and encapsulated into a workstation task sequence list with a sequential order for distribution. For the rider side, the task status is mapped to a discrete order dispatch status code. Since directly issuing a full array of planned routes containing high-frequency latitude and longitude coordinates would cause network communication congestion and violate low latency control requirements, the cloud scheduling server extracts the feature fingerprints of the planned routes in the scheduling strategy, such as the hash value sequence of key road segment nodes, and performs hash matching comparison with the feature fingerprints of the candidate delivery route set cached by the rider terminal, and assigns the route selection flag bit with the route index value of the fingerprint that matches completely. The embodiments of the present invention can achieve precise docking between cloud decision-making and on-site execution based on the instruction conversion mechanism, avoiding the disconnect between scheduling results and actual operation due to communication delays, and ultimately solving the technical defect of existing technologies that the strategy cannot be executed due to the lack of an execution mapping mechanism; In practical applications, the above method runs on a cloud-based scheduling server. Order flow data, temperature and humidity sensor data, and rider GPS data are continuously transmitted to the cloud-based scheduling server. The cloud-based scheduling server performs rolling status alignment, load assessment, and quality judgment in each business cycle, and sends the output discrete status codes to edge computing nodes deployed in the store's back kitchen and rider smart terminals. At the same time, it triggers parameter updates based on the actual execution time of the execution end, forming a complete scheduling business flow from information collection and strategy output to on-site execution and error correction.

[0018] The cloud-based catering service platform method determines the order increment ratio and store busyness, including: obtaining the current statistical time window and historical reference window, determining the order increment ratio based on the current statistical time window and historical reference window, the order increment ratio being the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window, and the historical reference window being the window corresponding to the same time period of the store in the past preset number of N business days, where N is a positive integer; Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, calculate the workstation occupancy rate and inventory fulfillment rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. The key workstation is the workstation with the lowest output per unit time in the preset production process. The inventory fulfillment rate is the ratio of available inventory to estimated demand. The estimated demand is the total theoretical consumption of key ingredients included in the orders to be made within the current statistical time window. The store's busyness is determined based on the current number of orders to be made, workstation occupancy rate, and inventory fulfillment rate. The initial values ​​of the preset weights are fixed coefficient values ​​obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within historical periods. The multiple linear regression algorithm uses workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within historical periods as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting. Obtain order data and store status data, and conduct in-depth analysis of store production status based on the current statistical time window, historical reference window, workstation occupancy status parameters, and inventory fulfillment rate to determine the order increment ratio and store busyness. Among them, the order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window, for example, to identify the surge in orders during preset high-concurrency periods; the store busyness is a value obtained by weighting and summing the current number of orders to be made, workstation occupancy rate and inventory fulfillment rate, which is used to characterize the current measured production pressure of the kitchen; the preset weights are used to dynamically balance the degree of constraint of different production links on the overall capacity. To ensure data structure stability, when the denominator of the estimated demand used to calculate the inventory fulfillment rate is zero, the fulfillment rate is defaulted to the maximum set value of 1.0. In practice, a maximum-minimum normalization method can be used to map indicators such as the number of orders to be made to a dimensionless interval. For example, if the normalized number of orders to be made is 0.6 and the heating equipment workstation occupancy rate is 0.8, the indicator reflecting the inventory tightness is taken as the maximum value between 0 and 1 minus the inventory fulfillment rate. This avoids negative calculation results due to available inventory exceeding estimated demand, resulting in a value of 0.5. Under the corresponding weights of 0.4, 0.4, and 0.2, the store busyness for this order volume and status is... 0.6 × 0.4 + 0.8 × 0.4 + 0.5 × 0.2 = 0.66 Compared to existing platforms that only use the number of currently uncompleted orders as a single dimension for assessing busyness, this invention extracts key workstations, such as the occupancy status of heating equipment and packaging workstations, and the inventory fulfillment rate of key ingredients. Combined with a specific quantitative calculation structure, it accurately quantifies the node limitation thresholds of kitchen production processes. The embodiments of this invention can achieve accurate quantification of store load based on multi-dimensional production data, preventing stores from continuing to accept more orders when their actual capacity is saturated. Ultimately, it solves the main technical defect of existing technologies that lead to concentrated timeouts due to a lack of monitoring of kitchen processes.

[0019] The cloud-based catering service platform method verifies the location reliability of candidate riders and determines the rider arrival value of candidate riders who pass the verification. This includes: if the location drift of a candidate rider is less than or equal to a preset distance deviation threshold and the network latency is less than or equal to a preset time delay threshold, then the candidate rider is determined to have passed the location reliability verification. Here, the location drift is the distance deviation between the current location coordinates and the coordinates predicted based on the historical trajectory, and the network latency is the round-trip communication latency from the rider's terminal to the cloud dispatch server. For candidate riders who pass the verification, the path distance from the candidate rider's current location to the pick-up point is obtained, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window. The rider's arrival value is determined based on the path distance, average moving speed, location drift, network latency, and traffic congestion index. The rider's arrival value is obtained by weighting and summing the path distance, average moving speed, location drift, network latency, and traffic congestion index according to preset weights. The preset weights include a first type of weight corresponding to the path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to the average moving speed. The signs of the first type of weights are opposite to those of the second type of weights. The system acquires rider status data and verifies the reliability and timeliness of candidate riders' locations based on location drift, network latency, path distance, average speed, and traffic congestion index. It then determines the arrival values ​​of the candidate riders who pass the verification. Location drift refers to the deviation between the current location coordinates and the predicted coordinates, and is used, for example, to identify GPS signal drift caused by building obstruction. To avoid geometric inconsistencies in the location prediction process, the predicted coordinates are obtained based on explicit kinematic rules constrained by the road network topology. Unlike simple spatial geometric extrapolation, which can lead to deviations in trajectory calculations where predicted points fall into inaccessible areas like buildings, the system extracts the candidate rider's location coordinates and timestamps from the past three consecutive sampling periods. Combined with the measured road topology direction matched to the rider's current location, the system calculates the longitudinal speed and average acceleration along that road. Starting from a valid sampling point, and considering the spatiotemporal misalignment caused by network communication delays, the system extrapolates along the corresponding road segment to the terminal output timestamp associated with the current location coordinates using a kinematically constrained extrapolation formula. This is not based on the current system timestamp received by the cloud, thus eliminating location coordinate errors caused by network communication delays during network transmission time. This results in accurate predicted coordinates that conform to the physical constraints of the real road network. The rider arrival value represents the timeliness of the candidate rider's arrival at the pickup point. In practice, if the location drift is less than or equal to a preset first threshold, such as 30 meters, and the network latency is less than or equal to a preset second threshold, such as 1500 milliseconds, then the verification is passed; dimensional unification processing is performed, and for the average moving speed that is positively correlated with the rider's arrival value, a positive mapping formula is used to map it to the 0 to 1 interval; For path distance, location drift, network latency, and road congestion index, which are negatively correlated with rider arrival value, an inverse mapping formula is used, which is the maximum reference value minus the current value and then divided by the reference range. When the reference range is zero, the transformed dimensionless value is directly assigned the extreme value 1.0. Similarly, it is transformed into a dimensionless value in the interval [0,1]. The transformed spatiotemporal indicators are weighted and summed with corresponding preset weights to obtain the arrival value. Unlike conventional methods that rely solely on map geometric distance for rider assignment, this invention unifies the dimensions and maps the correlations of multidimensional heterogeneous physical quantities, and overlays network communication status and measured road network congestion characteristics to accurately eliminate invalid candidate riders caused by signal distortion. The embodiments of the present invention can achieve a comprehensive assessment of rider accessibility based on multi-dimensional spatiotemporal features, improve the measured accessibility of order dispatch results, avoid assigning orders to candidate riders whose estimated arrival time exceeds the preset time limit, and ultimately solve the technical defect of existing technology that causes order dispatch failure due to lack of terminal status verification.

[0020] A cloud-based catering service platform method for determining food quality risk values ​​includes: for orders that have already been prepared, obtaining the cumulative waiting time since the completion of food preparation, and obtaining the current food temperature and humidity value of the food packaging area through a temperature and humidity acquisition device set in the food temporary storage area; The food quality risk value is determined based on the waiting time, the current food temperature, and the humidity value of the food packaging area. The food quality risk value is obtained by weighting and summing the waiting time, the deviation of the current food temperature from the preset insulation temperature range, and the deviation of the humidity value of the food packaging area from the preset humidity range after unifying the dimensions of each. To address the issue of insufficient interpretability in the comprehensive evaluation of multidimensional physical quantities, this embodiment establishes a clear physical quantity mapping rule for the unified processing of orders that have been prepared but are waiting to be picked up: for waiting time, the current cumulative waiting time is divided by the preset maximum allowable waiting time to obtain the dimensionless risk index of the time dimension.

[0021] Among them, I t t represents a dimensionless risk index representing the time dimension. wait T represents the current cumulative waiting time. max This indicates the maximum allowed waiting time. For the current food temperature, when it is lower than the lower limit of the preset heat preservation temperature range, the difference between the lower limit and the current temperature is divided by the difference between the lower limit and the preset minimum reference value of room temperature to obtain the dimensionless risk index of the temperature dimension, which characterizes the cooling range caused by heat loss.

[0022] Among them, Itemp T represents a dimensionless risk index based on temperature. current Indicates the current temperature of the food, T min T represents the lower limit of the preset insulation temperature range. room This indicates the preset minimum reference value for room temperature; when T min equal to T room At that time, I temp It is directly assigned the preset maximum risk limit value of 1.0; For the humidity value of the food packaging area, when it exceeds the upper limit of the preset humidity range, such as for fried food, the difference between the current humidity value and the upper limit value is divided by 100% and then subtracted from the difference of the upper limit value to obtain the dimensionless risk index of the humidity dimension. Thus, the different dimensions of physical deviations belonging to time, thermodynamics and environmental humidity are uniformly mapped to the dimensionless standard reference system in the range of 0 to 1, ensuring that the weighted summation calculation of various features follows rigorous mathematical and physical logic. For orders to be made, the risk value of food quality can be determined based on the time difference between the predicted food preparation time and the predicted rider arrival time. When the time difference is positive, it indicates that there is a risk of food backlog. When the time difference is negative, it indicates that the food has the conditions for priority preparation to avoid excessive waiting time after subsequent preparation. For calculating the quality risk value of food items in orders to be prepared, quantitative estimation is achieved through preset segmented control rules: a preset safety tolerance range for time difference is defined, such as -5 minutes to +5 minutes. If the time difference falls within this range, the first preset base value of the risk value is directly assigned, such as 0.1, indicating that the quality is good; if the time difference is positive and exceeds +5 minutes, the risk value is linearly accumulated according to the first preset step size, such as 0.05 / minute, until the maximum risk threshold of 1.0 is reached. If the time difference is negative and less than -5 minutes, in order to prevent long wait times by riders from causing congestion in the kitchen and indirectly affecting quality, the risk value is accumulated for the number of minutes exceeding the limit according to a second preset step size, such as 0.02 / minute. Through rigorous structured segmented calculation, the functional limitations caused by abstract prediction are avoided, ensuring that the risk quantification truly reflects the business situation.

[0023] The cloud-based catering service platform approach, after distributing the scheduling strategy to store edge nodes and rider terminals for execution, also includes: Based on store status, rider status, and route information, the system predicts food preparation time, delivery time, and delivery temperature upon receipt. It receives the food preparation time and delivery temperature from the store's edge nodes, as well as the delivery time from the rider's terminal. The comprehensive error value is determined based on the first difference between the meal preparation time and the predicted meal preparation time, the second difference between the delivery time and the predicted delivery time, and the third difference between the signed-in temperature and the predicted signed-in temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first, second, and third differences according to preset weights after unifying their dimensions. If the overall error value is greater than the preset system tolerance threshold, then at least one of the following will be executed: recalculate the weight parameters of store busyness, rider arrival value and food quality risk value; Send an abnormal takeover command to the pre-configured scheduling management terminal and terminate the issuance of the current scheduling policy; otherwise, maintain the normal issuance and execution of the current scheduling policy. To avoid the lack of an interpretable path in mapping multidimensional state information to prediction results, this embodiment clarifies the structured calculation path for each prediction value: the predicted meal time is calculated by multiplying the length of the order queue to be made in the store status by the corresponding meal's baseline preparation time, and then multiplying it by the congestion weighting coefficient based on the current workstation occupancy rate; the predicted delivery time is calculated by dividing the planned route distance in the route information by the rider's average moving speed within a preset time window, and then adding the delay penalty constant corresponding to the road congestion index. The predicted delivery temperature is calculated based on the physical principle of Newton's law of cooling. Unlike simple linear temperature drop models that directly subtract the product of the cooling constant and time from the initial temperature, this embodiment uses a preset standard initial temperature as the initial state. Within each discrete time step of the predicted delivery time, the temperature difference between the food and ambient temperatures from the previous time step is calculated. This temperature difference, the current discrete time step length, and the cooling constant corresponding to the takeout packaging material are then multiplied to obtain the temperature drop at the current time step.

[0024] To strictly ensure the consistency of temperature dimensions and avoid errors in physical modeling calculations caused by inconsistencies in dimensions, the current food temperature is calculated iteratively by subtracting the temperature drop from the previous time step's food temperature step by step.

[0025] Among them, T i T represents the temperature of the food calculated at the current discrete time step. i-1 Let T represent the food temperature at the previous discrete time step, ΔT represent the temperature drop at the current discrete time step, and k represent the temperature cooling constant corresponding to the takeaway packaging material. The dimension of k is the reciprocal of time, and its specific value is obtained by calibrating it using historical temperature drop test data of different takeaway packaging materials under constant external environment. envThe ambient temperature is represented by Δt, which represents the current discrete time step. The variable subscript i represents the discrete time step sequence index, and i≥1. The calculation continues until the predicted delivery time ends, resulting in a predicted receipt temperature that conforms to the actual thermodynamic laws. Based on this multidimensional quantitative prediction mechanism, the recalculation of weight parameters can be adaptively corrected according to the relative proportions of meal preparation error, delivery error and receipt temperature error in the comprehensive error value. The weights of indicators with higher error proportions are increased, and the weights of indicators with lower error proportions are decreased, while keeping the total weights unchanged, so that the correction direction of the scheduling strategy is consistent with the direction of the on-site deviation. The specific recalculation and quantification logic includes the following steps: divide the absolute value of the meal preparation error, the absolute value of the delivery error, and the absolute value of the temperature error upon receipt by their respective preset tolerance limit parameters. For example, the time tolerance is set to 180 seconds and the temperature tolerance is set to 3 degrees Celsius, and then convert them into dimensionless relative deviation rates. Divide the relative deviation rate of each indicator by the sum of the relative deviation rates of the three indicators to exceed the difference in physical dimensions and obtain the relative error proportion of each indicator under a unified reference system; multiply the original preset weight used for each indicator by the corresponding relative error proportion to calculate the weight adjustment transition value of each indicator; divide the weight adjustment transition value of a single indicator by the sum of the weight adjustment transition values ​​of all indicators, and use the normalized result to directly overwrite the new preset weight of the updated indicator. This calculation rule, based on relative deviation transformation, percentage scaling, and forced normalization, avoids data processing errors caused by the direct mixing and addition of multi-dimensional physical dimensions in adaptive correction, and ensures that the weight parameters of the next scheduling cycle prioritize the correction of the data dimension with the largest historical execution deviation.

[0026] A cloud-based catering service platform system, used in the cloud-based catering service platform method of the present invention, includes a cloud scheduling server and store edge nodes and rider terminals that are communicatively connected to the cloud scheduling server. The cloud scheduling server includes: a data acquisition module, used to acquire order data, store status data, rider status data and food quality data, and perform timestamp alignment to obtain synchronized status data; The load assessment module is used to determine the order increment ratio and store busyness based on the synchronization status data; the rider screening module is used to obtain information on candidate riders, verify the location credibility of candidate riders, and determine the rider arrival value of candidate riders who pass the verification based on the path distance from the candidate rider's current location to the pick-up point, average moving speed, location drift, network latency, and road congestion index. The quality assessment module is used to determine the food quality risk value of pending orders based on synchronized status data. Pending orders include orders to be made and orders that have been prepared but are ready for pickup. For orders to be made, the food quality risk value is determined based on the time difference between the predicted food preparation time and the predicted rider arrival time. For orders that have been prepared but are ready for pickup, the food quality risk value is determined based on the waiting time after food preparation, food temperature, and humidity value of the food packaging area. The strategy output module is used to weight the store's busyness, rider arrival value and food quality risk value according to preset weights to obtain the order matching value between the order to be processed and the candidate rider, and output the scheduling strategy under at least one of the preset time constraints, distance constraints, rider load constraints and store order acceptance constraints. The instruction mapping module is used to convert the scheduling strategy into order acceptance status code, workstation task sequence, order dispatch status code and route selection flag, and send them to the store edge node and rider terminal for execution. The workstation task sequence corresponds to the execution order of each production workstation in the store, and the route selection flag corresponds to the target route in the candidate delivery route set. This embodiment provides a cloud computing-based catering service platform system as the hardware and logic carrier for implementing the above method. Through the coordinated operation of multiple modules, it realizes an effective connection between business status perception, strategy calculation and terminal execution. In the system's operational architecture, the data acquisition module serves as a unified data entry point, acquiring multi-source data such as orders, stores, riders, and quality, and forcibly performing timestamp alignment to output synchronized status data, providing a consistent data source for all subsequent modules. The strategy output module and the instruction mapping module together constitute the decision-making hub. The strategy output module dynamically balances and weights the store's busyness, rider arrival value, and food quality risk value to output the scheduling strategy. The instruction mapping module then converts the strategy into order acceptance status codes, workstation task sequences, order dispatch status codes, and route selection flags. This conversion from continuous strategy to discrete instructions eliminates the incompatibility and data structure differences between complex cloud algorithms and the execution capabilities of store edge nodes and rider terminals. To address the timing discrepancy issue in the transmission of control commands from the cloud in weak network communication environments, the command mapping module employs a bidirectional handshake retransmission mechanism based on a unique serial number when issuing commands: after a command is issued, the command mapping module marks the command in the control flow as an initial state awaiting confirmation and starts a waiting timer. If the execution confirmation signal ACK is not received from the store edge node or rider terminal within the preset backoff time window, the control logic will not discard the current state or re-output a new strategy. Instead, it will maintain the original state characteristics and reissue discrete instructions with the same serial number according to the exponential backoff time interval until an acknowledgment is received, thereby triggering the state machine to switch to the executed state. This ensures the deterministic physical closed loop of the scheduling control flow at the edge execution terminal.

[0027] The cloud-based catering service platform system uses a load assessment module to: obtain the current statistical time window and historical reference window; determine the order increment ratio based on the current statistical time window and historical reference window; the order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window; the historical reference window is the window corresponding to the same time period of the store in the past N preset business days, and N is a positive integer. Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, and calculate the workstation occupancy rate and inventory fulfillment rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. Based on the current number of orders to be made, workstation occupancy rate, and inventory fulfillment rate, determine the store's busyness. The initial values ​​of the preset weights are fixed coefficient values ​​obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within historical periods. The multiple linear regression algorithm uses the workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within historical periods as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting. The load assessment module deeply mines the store's production status based on synchronized status data, calculates the order increment ratio, and calculates the store's busyness by combining workstation occupancy rate and inventory fulfillment rate. By quantifying key workstations, such as the queue length of steaming cabinets and packaging workstations, as well as the consumption rate of key ingredients, this module can accurately identify the store's actual production capacity limit and avoid issuing order acceptance instructions that exceed the preset production capacity load limit at the system level.

[0028] The cloud-based catering service platform system has a rider screening module that is used to: determine that a candidate rider passes the location reliability verification if the candidate rider's location drift is less than or equal to a preset distance deviation threshold and the network latency is less than or equal to a preset time delay threshold; for candidate riders who pass the verification, obtain the path distance from the candidate rider's current location to the pickup point, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window; The rider arrival value is determined based on path distance, average speed, location drift, network latency, and traffic congestion index. The rider arrival value is obtained by weighting and summing the path distance, average speed, location drift, network latency, and traffic congestion index separately after unifying their dimensions. The preset weights include a first type of weight corresponding to path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to average speed. The signs of the first type of weights are opposite to those of the second type of weights. The rider screening module specifically suppresses invalid delivery resources, uses location drift and network latency to verify location reliability, and removes riders whose location is distorted due to signal abnormalities. The rider arrival value is calculated by combining path distance, average moving speed and road congestion index. This method ensures that riders entering the scheduling pool are not only spatially appropriate, but also have measured physical accessibility in terms of communication and road conditions.

[0029] The cloud-based catering service platform system also includes a feedback processing module in its cloud dispatch server. This module is used to: generate predicted food preparation time, predicted delivery time, and predicted arrival temperature based on store status, rider status, and route information; receive food preparation time and arrival temperature from store edge nodes, and receive delivery time from rider terminals; and determine a comprehensive error value based on the first difference between food preparation time and predicted food preparation time, the second difference between delivery time and predicted delivery time, and the third difference between arrival temperature and predicted arrival temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first, second, and third differences according to preset weights after unifying their dimensions. If the overall error value exceeds the preset system tolerance threshold, at least one of the following actions will be taken: recalculate the weight parameters of store busyness, rider arrival value, and food quality risk value; send an abnormal takeover command to the pre-configured dispatch management terminal and terminate the issuance of the current dispatch strategy; otherwise, maintain the normal issuance and execution of the current dispatch strategy. The feedback processing module establishes an adaptive adjustment channel for the system. By receiving measured delivery time and delivery temperature data transmitted from store edge nodes and rider terminals, it calculates the comprehensive error value between the measured and predicted results. When the error value exceeds the system tolerance threshold E... max When the system is in operation, it automatically triggers the recalculation of weight parameters or initiates a manual takeover request to ensure that the system can promptly correct scheduling deviations when faced with extreme weather or sudden congestion and other drastic changes in the external environment, thus ensuring the stability and reliability of the entire catering service chain.

[0030] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A cloud computing-based catering service platform method, characterized in that, include: Acquire and align the timestamps of order data, store status data, rider status data, and food quality data corresponding to the order data, wherein the food quality data includes food temperature and humidity value of the packaging area, to obtain synchronized status data; The order increment ratio and store busyness are determined based on the synchronized status data. The system obtains the current location and historical communication trajectory of at least one candidate rider, obtains the traffic congestion index of the area corresponding to the current location, calculates the location drift of the candidate rider and the network latency from the rider terminal corresponding to the candidate rider to the cloud dispatch server, and verifies the location reliability of the candidate rider. The path distance from the current location of the candidate rider to the pickup point corresponding to the order is obtained, as well as the average moving speed, the location drift, the network latency and the traffic congestion index within a preset time window, and the rider arrival value of the candidate rider that passes the verification is determined. Based on the predicted time difference between the completion of food preparation and the rider's arrival at the pickup store, the waiting time after food preparation, the food temperature, and the humidity of the packaging area, the food quality risk value of the pending orders and the already prepared orders is determined. Obtain preset weights, and calculate the order matching value by weighting the store busyness, the rider arrival value and the food quality risk value according to the preset weights. Output the scheduling strategy under preset time constraints, distance constraints, rider load constraints and store order acceptance constraints. A set of candidate delivery routes is formed and output, and a target route is determined from the set of candidate delivery routes. The scheduling strategy is converted into an order acceptance status code, a workstation task sequence, an order dispatch status code, and a route selection flag corresponding to the target route, and then executed.

2. The cloud computing-based catering service platform method as described in claim 1, characterized in that, Determine the order increase ratio and store busyness, including: Obtain the current statistical time window and the historical reference window, and determine the order increment ratio based on the current statistical time window and the historical reference window. The order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window. The historical reference window is the window corresponding to the same time period of the store in the past preset number of business days N, and N is a positive integer. Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, calculate the workstation occupancy rate and inventory satisfaction rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. The key workstation is the workstation with the lowest output per unit time in the preset production process. The inventory satisfaction rate is the ratio of available inventory to estimated demand. The estimated demand is the total theoretical consumption of key ingredients included in the orders to be made within the current statistical time window. The store's busyness is determined based on the current number of orders to be processed, workstation occupancy rate, and inventory fulfillment rate. The initial value of the preset weight is a fixed coefficient value obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within a historical period. The multiple linear regression algorithm uses the workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within a historical period as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting.

3. The cloud computing-based catering service platform method as described in claim 1, characterized in that, Verify the location reliability of candidate riders and determine the rider arrival values ​​of those who pass the verification, including: If the location drift of a candidate rider is less than or equal to a preset distance deviation threshold and the network latency is less than or equal to a preset time delay threshold, then the candidate rider is deemed to have passed the location reliability verification. Here, the location drift is the distance deviation between the current location coordinates and the coordinates predicted based on the historical trajectory, and the network latency is the round-trip communication latency between the rider's terminal and the cloud dispatch server. For candidate riders who pass the verification, obtain the path distance from the candidate rider's current location to the pick-up point, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window; The rider arrival value is determined based on path distance, average moving speed, location drift, network latency, and traffic congestion index. The rider arrival value is obtained by performing dimensional unification processing on path distance, average moving speed, location drift, network latency, and traffic congestion index, and then weighting and summing them according to preset weights. The preset weights include a first type of weight corresponding to the path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to the average moving speed. The signs of the first type of weights are opposite to those of the second type of weights.

4. The cloud computing-based catering service platform method as described in claim 1, characterized in that, Determine the risk value of food quality, including: For orders that have already been prepared, the system obtains the cumulative waiting time since the food was prepared, and uses a temperature and humidity sensor located in the food storage area to obtain the current food temperature and humidity value of the food packaging area. The food quality risk value is determined based on the waiting time, the current food temperature, and the humidity value of the food packaging area. The food quality risk value is obtained by weighting and summing the waiting time, the deviation of the current food temperature from the preset insulation temperature range, and the deviation of the humidity value of the food packaging area from the preset humidity range after unifying their dimensions.

5. The cloud computing-based catering service platform method as described in claim 1, characterized in that, After the scheduling strategy is distributed to the store edge nodes and rider terminals for execution, it also includes: Based on store status, rider status, and route information, the system predicts food preparation time, delivery time, and delivery temperature upon receipt. It receives the food preparation time and delivery temperature from the store's edge nodes, as well as the delivery time from the rider's terminal. The comprehensive error value is determined based on the first difference between the meal preparation time and the predicted meal preparation time, the second difference between the delivery time and the predicted delivery time, and the third difference between the receipt temperature and the predicted receipt temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first difference, the second difference, and the third difference according to preset weights after unifying their dimensions. If the overall error value is greater than the preset system tolerance threshold, then at least one of the following will be executed: recalculate the weight parameters of store busyness, rider arrival value and food quality risk value; Send an abnormal takeover command to the pre-configured scheduling management terminal and terminate the issuance of the current scheduling policy; otherwise, maintain the normal issuance and execution of the current scheduling policy.

6. A cloud-based catering service platform system, used to execute the cloud-based catering service platform method as described in any one of claims 1 to 5, characterized in that, This includes a cloud-based dispatch server, as well as store edge nodes and rider terminals that communicate with the cloud-based dispatch server. The cloud-based dispatch server includes: The data acquisition module is used to acquire order data, store status data, rider status data, and food quality data, and perform timestamp alignment to obtain synchronized status data. The load assessment module is used to determine the order increment ratio and store busyness based on synchronization status data; The rider screening module is used to obtain information about candidate riders, verify the location reliability of the candidate riders, and determine the rider arrival value of the candidate riders who pass the verification based on the path distance from the candidate rider's current location to the pick-up point, average moving speed, location drift, network latency and road congestion index. The quality judgment module is used to determine the food quality risk value of pending orders based on synchronized status data. The pending orders include orders to be made and orders that have been prepared and are ready for pickup. For orders to be made, the food quality risk value is determined based on the time difference between the predicted food preparation time and the predicted rider arrival time. For orders that have been prepared and are ready for pickup, the food quality risk value is determined based on the waiting time after food preparation, the food temperature, and the humidity value of the food packaging area. The strategy output module is used to weight the store's busyness, rider arrival value and food quality risk value according to preset weights to obtain the order matching value between the order to be processed and the candidate rider, and output the scheduling strategy under at least one of the preset time constraints, distance constraints, rider load constraints and store order acceptance constraints. The instruction mapping module is used to convert the scheduling strategy into order acceptance status code, workstation task sequence, order dispatch status code and route selection flag, and send them to the store edge node and rider terminal for execution. The workstation task sequence corresponds to the execution order of each production workstation in the store, and the route selection flag corresponds to the target route in the candidate delivery route set.

7. The cloud-based catering service platform system as described in claim 6, characterized in that, The load assessment module is used for: Obtain the current statistical time window and the historical reference window, and determine the order increment ratio based on the current statistical time window and the historical reference window. The order increment ratio is the ratio of the number of new orders in the current statistical time window to the average number of orders in the historical reference window. The historical reference window is the window corresponding to the same time period of the store in the past preset number of business days N, and N is a positive integer. Obtain the occupancy status parameters of key workstations and the available inventory of key ingredients, and calculate the workstation occupancy rate and inventory fulfillment rate. The occupancy status parameters include one or more of the following: workstation activation status, queue length, and occupancy duration. The store's busyness is determined based on the current number of orders to be processed, workstation occupancy rate, and inventory fulfillment rate. The initial value of the preset weight is a fixed coefficient value obtained by the cloud scheduling server through offline training using a multiple linear regression algorithm based on scheduling success rate data within a historical period. The multiple linear regression algorithm uses the workstation occupancy rate, inventory fulfillment rate, and number of candidate riders within a historical period as feature inputs, and uses the corresponding historical measured scheduling success rate as the target output for model fitting.

8. The cloud-based catering service platform system as described in claim 6, characterized in that, The rider screening module is used for: If the location drift of a candidate rider is less than or equal to a preset distance deviation threshold, and the network latency is less than or equal to a preset time delay threshold, then the candidate rider is deemed to have passed the location reliability verification. For candidate riders who pass the verification, obtain the path distance from the candidate rider's current location to the pick-up point, as well as the average moving speed, location drift, network latency, and traffic congestion index within a preset time window; The rider arrival value is determined based on path distance, average moving speed, location drift, network latency, and traffic congestion index. The rider arrival value is obtained by performing dimensional unification processing on path distance, average moving speed, location drift, network latency, and traffic congestion index, and then weighting and summing them according to preset weights. The preset weights include a first type of weight corresponding to the path distance, location drift, network latency, and traffic congestion index, and a second type of weight corresponding to the average moving speed. The signs of the first type of weights are opposite to those of the second type of weights.

9. The cloud-based catering service platform system as described in claim 6, characterized in that, The cloud-based dispatch server also includes a feedback processing module, which is used to: generate predictions of food preparation time, delivery time, and delivery temperature based on store status, rider status, and route information; receive food preparation time and delivery temperature from store edge nodes; and receive delivery time from rider terminals. A comprehensive error value is determined based on the first difference between the food preparation time and the predicted food preparation time, the second difference between the delivery time and the predicted delivery time, and the third difference between the receipt temperature and the predicted receipt temperature. The comprehensive error value is obtained by weighting and summing the absolute values ​​of the first, second, and third differences according to preset weights after unifying their dimensions. If the comprehensive error value is greater than the preset system tolerance threshold, at least one of the following actions is taken: recalculate the weight parameters of store busyness, rider arrival value, and food quality risk value; send an abnormal takeover command to the pre-configured dispatch management terminal and terminate the issuance of the current dispatch strategy; otherwise, the current dispatch strategy is maintained and executed normally.

Images