A cloud edge collaboration-based real-time operation scheduling method and system

Abstract

The application relates to the technical field of operation scheduling, and discloses a real-time operation scheduling method and system based on cloud-edge cooperation, which is applied to an operation system for cooperatively managing park operation vehicles by a cloud-end operation scheduling platform, regional edge nodes and vehicle terminals and comprises the following steps: the cloud-end operation scheduling platform acquires real-time operation tasks and vehicle state information, and generates a candidate park operation vehicle set; the cloud-end operation scheduling platform acquires the task remaining time, the number of tasks to be processed and the round-trip communication time of the candidate park operation vehicle, and determines the earliest connection time for receiving the next real-time operation task; the cloud-end operation scheduling platform compares the available sequence of the vehicle itself with the actual connection sequence of the cloud edge, generates a sequence inversion relationship and a cloud-edge connection sequence inversion zone when the two sequences are inconsistent, only performs local sequence adjustment on the related candidate park operation vehicle, generates a real-time scheduling table and outputs a scheduling instruction through the regional edge node. The application can reduce the influence of edge task backlog and communication waiting on scheduling confirmation.

Description

Technical Field

[0001] This invention relates to the field of operation scheduling technology, and more specifically, to a real-time operation scheduling method and system based on cloud-edge collaboration. Background Technology

[0002] In real-time operational scenarios such as logistics, inspection, shuttle, and production transfer within the industrial park, vehicle terminals typically report vehicle location, current task stage, estimated end time, available payload, vehicle operating status, and task confirmation status to regional edge nodes. These edge nodes maintain a local queue of pending tasks and exchange task data with the cloud-based operations scheduling platform. The cloud-based platform generates a scheduling table based on real-time operational tasks, vehicle status information, and service area constraints. The regional edge nodes then forward scheduling instructions to the vehicle terminals, and the vehicle terminals return task confirmation results, forming a closed loop. This cloud-edge collaboration approach considers both a global resource view and on-site response, making it suitable for multi-region, multi-vehicle, and multi-task parallel operation management.

[0003] In actual deployment, the length of the local pending task queue at each regional edge node, the quality of the cloud-edge network, and the current task progress of vehicles all affect the continuation of the next task. If the cloud-based operation and scheduling platform mainly arranges vehicle order based on the remaining task time, vehicles with shorter remaining task time may receive and confirm information later than other vehicles due to a large backlog at their respective regional edge nodes or longer round-trip communication times. Consequently, after the scheduling table is issued, problems such as task waiting, duplicate reassignment, cross-regional resource consumption, and increased pressure on status merging may occur. The existing operation and scheduling system needs to ensure that the vehicle sequencing process reflects the task continuation conditions on the regional edge node side, while retaining centralized coordination in the cloud, local queue maintenance at edge nodes, and vehicle terminal confirmation links. Summary of the Invention

[0004] This invention provides a real-time operation scheduling method and system based on cloud-edge collaboration, which solves the technical problems mentioned in the background art.

[0005] To achieve the above-mentioned objectives, the present invention provides the following technical solution.

[0006] A real-time operation scheduling method based on cloud-edge collaboration is applied to an operation system that collaboratively manages park vehicles through a cloud-based operation scheduling platform and regional edge nodes, comprising: The cloud-based operation and scheduling platform obtains real-time operation tasks and vehicle status information of park operation vehicles, and generates a candidate set of park operation vehicles based on the real-time operation tasks and vehicle status information. For each candidate park operation vehicle in the candidate park operation vehicle set, obtain the remaining task time, the number of tasks to be processed, and the round-trip communication time. The earliest possible time for the candidate park operation vehicle to receive the next real-time operation task is determined based on the remaining time of the task, the number of tasks to be processed, and the round-trip communication time. Compare the available order of candidate park operating vehicles formed by the remaining time of the task with the actual cloud-edge connection order formed by the earliest connection time. When the two are inconsistent, generate an order reversal relationship and form a cloud-edge connection order reversal band. The cloud-edge continuation order reversal band is used to perform local sorting adjustments only on candidate park operation vehicles that have the order reversal relationship. A real-time scheduling table is generated based on the candidate park operation vehicle order after local sorting adjustment, and the corresponding scheduling instructions are output through the edge node of the region.

[0007] Compared with the prior art, the present invention has the following substantial features and significant progress: This invention, within the existing collaborative link between the cloud-based operation and scheduling platform, regional edge nodes, and vehicle terminals, uses the remaining task time of park operation vehicles, the number of pending tasks at regional edge nodes, and round-trip communication time to determine the earliest connection time. It then identifies the order reversal relationship between the available vehicle sequence and the actual connection sequence at the cloud edge, and uses the cloud edge connection order reversal band to limit the local sorting adjustment range. As a result, the real-time scheduling table can more closely reflect the task confirmation progress at the regional edge nodes, reducing task mismatches, duplicate reassignments, and vehicle waiting caused by local pending task queue backlogs or communication delays. Simultaneously, it retains the original task collection, candidate park operation vehicle screening, scheduling instruction issuance, edge backup scheduling, and status merging processes, facilitating deployment within the existing park operation vehicle scheduling system. Attached Figure Description

[0008] Figure 1 This is a diagram of the real-time operation scheduling system architecture and scheduling mechanism based on cloud-edge collaboration of the present invention. Detailed Implementation

[0009] The following description is provided in conjunction with the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the invention; those skilled in the art can make equivalent substitutions or combinations for the specific implementations.

[0010] Example 1: This specific implementation is applied to an operational system for collaborative management of park operation vehicles by a cloud-based operation scheduling platform and regional edge nodes. The operational system includes a cloud-based operation scheduling platform 100, regional edge nodes 200, vehicle terminals 300, and park operation vehicles 400. The cloud-based operation scheduling platform 100 is used to aggregate real-time operation tasks, vehicle status information, remaining task time, number of pending tasks, and round-trip communication time, and to form a cloud-edge connection sequence reversal belt 600 and a real-time scheduling table 700. The regional edge node 200 is used to maintain a local pending task queue 500, receive information reported by the vehicle terminals 300, forward scheduling instructions, and send back task confirmation results. The vehicle terminals 300 are installed on or configured corresponding to the park operation vehicles 400, and are used to report vehicle status information and task confirmation results, and receive scheduling instructions forwarded by the regional edge nodes 200.

[0011] Reference Figure 1 There are uplink data streams and downlink command streams between the regional edge node 200 and the cloud-based operation and scheduling platform 100. The uplink data stream carries at least the remaining time of the task, the number of tasks to be processed, the round-trip communication time, and the vehicle status information; the downlink command stream carries at least the scheduling instructions generated based on the real-time scheduling table 700. Figure 1 The local pending task queue 500 inside the regional edge node 200 represents the source of real-time operation task records that have not yet been assigned or confirmed on the regional edge node 200 side. The cloud-edge connection order reversal band 600 inside the cloud operation scheduling platform 100 represents the local sorting adjustment range formed when the available order of the vehicle itself is inconsistent with the actual connection order of the cloud edge. The real-time scheduling table 700 represents the scheduling result formed after the local sorting adjustment.

[0012] In this specific implementation, the terminal operation scheduling platform 100 determines the earliest connection time only by directly collecting the remaining time of tasks, the number of tasks to be processed, and the round-trip communication time from the existing operating state. Based on the earliest connection time, it identifies the order reversal relationship and the cloud-edge connection order reversal band 600. As a result, the allocation order of real-time operation tasks can be closer to the actual connection state at the regional edge node 200.

[0013] Example 2: In one implementation, the cloud-based operation and scheduling platform 100 pre-establishes basic ledgers for park operation vehicles 400, regional edge nodes 200, service areas, and real-time operation tasks. The basic ledger for park operation vehicles 400 records at least the vehicle number, service area, rated load, permitted service type, vehicle operating status, and current task number. The basic ledger for regional edge nodes 200 records at least the regional edge node number, coverage area, list of connected park operation vehicles 400, and communication address. The basic ledger for real-time operation tasks records at least the task number, task type, task occurrence time, work location, destination location, required completion time, load requirement, and task status. These basic ledgers can be maintained through existing business databases, cloud configuration files, or local caching on regional edge nodes 200. Their purpose is to ensure that real-time operation tasks, park operation vehicles 400, and regional edge nodes 200 can participate in subsequent scheduling using consistent fields.

[0014] When the regional edge node 200 collects real-time operation tasks, it can receive real-time operation tasks submitted by field terminals, business systems, or manual input terminals. For each real-time operation task, the regional edge node 200 collects the task number, task type, task occurrence time, work location, target location, required completion time, load requirements, and task status, and maintains a local pending task queue 500 based on the task occurrence time, required completion time, and task status. The records in the local pending task queue 500 are not simply a display list, but a set of real-time operation task records used to determine the number of pending tasks; when a real-time operation task has not yet been assigned or confirmed, the real-time operation task record is retained in the local pending task queue 500.

[0015] To ensure field consistency between the cloud-based operation and scheduling platform 100 and the regional edge node 200, the cloud-based operation and scheduling platform 100 can send a unified field dictionary, time format, and status code to the regional edge node 200. After receiving a real-time operation task, the regional edge node 200 first performs an integrity check based on the task number, task occurrence time, work location, target location, load requirements, and task status. For duplicate reports with the same task number, the regional edge node 200 retains the most recent valid record. For records lacking work location, target location, vehicle number, or task status, the regional edge node 200 marks them as needing to be supplemented. This processing constitutes routine data verification and deduplication, ensuring reliable input for subsequent use of remaining task time, the number of pending tasks, and round-trip communication time.

[0016] Example 3: The vehicle terminal 300 periodically or when its status changes reports vehicle status information to the regional edge node 200. The vehicle status information includes vehicle location, current task stage, estimated end time, available load, vehicle operating status, and task confirmation status. Vehicle location is used to determine the spatial relationship between the park operation vehicle 400 and the work location and target location; current task stage is used to determine if the park operation vehicle 400 is in a standby, heading to the work location, currently working, leaving the work location, or has completed its task status; estimated end time is used to determine the remaining task time in conjunction with the current time; available load is used to determine if the park operation vehicle 400 meets the load requirements; vehicle operating status is used to exclude park operation vehicles 400 that are offline, faulty, or out of service; and task confirmation status is used to determine whether the dispatch instruction has been accepted, rejected, or temporarily suspended by the vehicle terminal 300.

[0017] The regional edge node 200 determines the remaining task time based on the current task stage, current time, and estimated end time reported by the vehicle terminal 300. For candidate park operation vehicles... Remaining time for the task This indicates the time required for the candidate park operation vehicle to complete its current task from the current moment, in seconds. The remaining task time can be obtained by subtracting the current moment from the expected end time; when park operation vehicle 400 is idle, the remaining task time can be taken as... When the expected end time is earlier than the current time and the vehicle terminal 300 has not yet reported the completion status, the regional edge node 200 can mark the vehicle status information as pending verification and participate in the generation of the candidate park operation vehicle set according to the most recent valid vehicle status information or postpone participation in the generation of the candidate park operation vehicle set.

[0018] The remaining task time describes the operational progress of the park operation vehicle 400 itself, and cannot solely represent the time when the park operation vehicle 400 actually receives the next real-time operation task. If candidate park operation vehicles are only sorted by remaining task time from smallest to largest, the differences between the local pending task queue 500 and the cloud-edge communication status of different candidate park operation vehicles belonging to different regional edge nodes 200 will be ignored. Therefore, this specific implementation uses the remaining task time as an input of the earliest connection time, rather than as the sole basis for the final sorting.

[0019] Example 4: The region edge node 200 determines the number of tasks to be processed based on its local task queue 500. For the region edge node... Number of tasks to be processed This indicates the number of real-time operational task records that have not yet been assigned or confirmed at the local edge node 200 in this area, and the unit can be individual. The number of pending tasks is obtained by the local pending task queue 500 directly counted by the edge node 200. The larger the number of pending tasks, the more queued objects the current edge node 200 has when forwarding scheduling instructions to the vehicle terminal 300, receiving task confirmation results, or processing real-time operational task records.

[0020] The region edge node 200 obtains the round-trip communication time through conventional network probing. For the region edge node... Round-trip communication time This represents the time elapsed from when edge node 200 in the region sends a probe request to the cloud-based operation and scheduling platform 100 and receives a response, in seconds. The round-trip communication time can be obtained from the request and response times of heartbeat requests, probe messages, or existing service interfaces. To avoid instability in sorting due to single abnormal fluctuations, edge node 200 uses the most recent valid round-trip communication time within a collection cycle, or the most recent... The arithmetic mean of the valid detection results; the above processing is only used to filter out network jitter.

[0021] When determining the round-trip communication time using multiple valid detection results, the region edge node 200 always uses the nearest one. The arithmetic mean of all valid detection results. Number of valid detection samples. The acquisition configuration is determined by the data acquisition configuration stored at the region edge node 200 and remains unchanged within the same scheduling cycle; when the most recent valid detection result is less than At this point, the number of valid detection results obtained so far will be used as the number of valid detection samples. If a probe fails to return within the existing interface timeout period, has an abnormal response format, or its response identifier does not match the probe request, the probe result will not be counted as a valid probe result. For the [missing information]... The time for a single round-trip communication for each valid detection result is denoted as [missing information]. The unit is seconds. The round-trip communication time for the regional edge node 200 is determined according to the following formula.

[0022]

[0023] Among them, round-trip communication time and single round-trip communication time All dimensions are time, and the number of effective detection samples Since it is a count and dimensionless, this arithmetic mean still represents the round-trip communication time between the region edge node 200 and the cloud operation scheduling platform 100. When the number of valid probe samples... for Time, round-trip communication time Equivalent to the most recent valid round-trip communication time; when there is no valid detection result, the area edge node 200 uses the valid round-trip communication time of the previous collection cycle and marks the source identifier as the continued value. If there is no valid round-trip communication time of the previous collection cycle, the round-trip communication time of the area edge node 200 is marked as pending verification in this scheduling cycle.

[0024] The regional edge node 200 uploads the number of pending tasks, round-trip communication time, and vehicle status information, along with the collection timestamp and source identifier, to the cloud-based operation and dispatch platform 100. Upon receiving this data, the cloud-based operation and dispatch platform 100 merges the data from each region based on the regional edge node number and vehicle number, forming a unified real-time operation view. For pending tasks or round-trip communication times exceeding a predetermined valid time, the cloud-based operation and dispatch platform 100 can mark them as expired. For multiple records from the same regional edge node 200 within the same collection period, the cloud-based operation and dispatch platform 100 can retain valid records based on the timestamp selection method. The aforementioned source verification, duplicate record removal, and expired status marking are routine data processing steps used to ensure the stability of the input for calculating the earliest connection time.

[0025] Example 5: After obtaining real-time operational tasks and vehicle status information of park operation vehicles 400, the cloud-based operation scheduling platform 100 generates a candidate set of park operation vehicles based on the real-time operational tasks and vehicle status information. For real-time operational tasks with a pending assignment status, the cloud-based operation scheduling platform 100 first removes park operation vehicles 400 whose vehicle operation status is offline, faulty, or suspended; then removes park operation vehicles 400 whose available load is insufficient to meet load requirements; then removes park operation vehicles 400 that do not support the task type; and finally determines the park operation vehicles 400 that can participate in the assignment based on the service area, allowed cross-area range, vehicle location, work location, and target location.

[0026] When determining which park operation vehicles 400 can participate in allocation based on service area, permitted cross-regional range, vehicle location, work location, and target location, the cloud-based operation dispatch platform 100 adopts fixed entry rules. If the service area of ​​the park operation vehicle 400 is consistent with the service area of ​​the work location of the real-time operation task, and the target location is located within the service area or within the permitted cross-regional range of the park operation vehicle 400, then the park operation vehicle 400 meets the service area condition; if the service area of ​​the park operation vehicle 400 is inconsistent with the service area of ​​the work location, but both the work location and the target location are within the permitted cross-regional range of the park operation vehicle 400, then the park operation vehicle 400 meets the service area condition; except for the above two situations, the park operation vehicle 400 does not enter the candidate park operation vehicle set.

[0027] Vehicle location is used to confirm whether the park operation vehicle 400 has the basic operational feasibility to reach the work site at the current moment. If the vehicle location is located in a suspended service area, maintenance area, closed area, or outside the permitted cross-area range, the cloud operation dispatch platform 100 will remove the park operation vehicle 400. If the vehicle location is temporarily missing within the same collection period, but the vehicle terminal 300 has a most recent valid vehicle location that is still within its service area or within the permitted cross-area range, the cloud operation dispatch platform 100 can use the most recent valid vehicle location to complete the generation of the candidate park operation vehicle set. If there is no most recent valid vehicle location, the park operation vehicle 400 will not be included in the candidate park operation vehicle set.

[0028] Each candidate park operation vehicle in the candidate park operation vehicle set is associated with its corresponding area edge node 200. This association is used to determine the number of pending tasks and round-trip communication time for that candidate park operation vehicle when calculating the earliest connection time. If the candidate park operation vehicle set is empty, the cloud operation scheduling platform 100 maintains the pending status of real-time operation tasks and expands the service area according to existing business process prompts, waiting for the park operation vehicle 400 to recover or for operation personnel to intervene. If the candidate park operation vehicle set is not empty, the cloud operation scheduling platform 100 records the current task stage, remaining task time, corresponding area edge node 200, vehicle location, available load, and vehicle operating status for each candidate park operation vehicle.

[0029] The process of generating the candidate park operation vehicle set ensures that subsequent ranking is only performed among the 400 park operation vehicles with basic business feasibility. This process has a sequential relationship with the cloud-edge connection order reversal band 600: first, the candidate park operation vehicle set is determined based on real-time operation tasks and vehicle status information; then, for each candidate park operation vehicle in the candidate park operation vehicle set, the remaining task time, the number of pending tasks, and the round-trip communication time are obtained; finally, the earliest connection time is calculated and the order reversal relationship is identified. This avoids including offline, faulty, suspended, underloaded, or unsupported task types of the 400 park operation vehicles in the local ranking adjustment.

[0030] Example 6: The cloud-based operation and dispatch platform 100 determines the earliest pick-up time for candidate park operation vehicles from the candidate park operation vehicle set. This is for vehicles originating from regional edge nodes. Management of candidate park operation vehicles Remaining time for the task Indicates the vehicles operating in the candidate parks Time required to complete the current task, number of tasks pending Represents the edge node of the region The number of real-time operational task records in the local pending task queue of 500 that have not yet been assigned or confirmed, and the round-trip communication time. Represents the edge node of the region The request-response time between the cloud-based operation and scheduling platform 100 and the cloud-based operation and scheduling platform 100. The cloud-based operation and scheduling platform 100 determines the earliest connection time according to the following formula. .

[0031]

[0032] The formula includes candidate park operation vehicles Its own operation progress, and the edge nodes of its region Local queuing status and regional edge nodes The communication status between the cloud-based operation and scheduling platform 100 and the cloud-based operation and scheduling platform 100 is merged into a single time quantity. Corresponding candidate park operation vehicles It can receive the earliest successor time for the next real-time operational task. Vehicles from the candidate park Remaining time for the task Vehicles from the candidate park Edge nodes of the region The number of tasks to be processed. Vehicles from the candidate park Edge nodes of the region The round-trip communication time. This represents the observable succession time required for one request confirmation for existing pending tasks and currently candidate park operating vehicles, where... This does not indicate a new task, but rather a combined count of the pending tasks in the local queue of 500 and the corresponding request confirmations for the current candidate park operation vehicles.

[0033] The earliest connection time is a derived time calculated from the remaining task time, the number of tasks to be processed, and the round-trip communication time. If the remaining task times of two candidate park operation vehicles are similar, but the edge node 200 of the region to which one candidate park operation vehicle belongs has a larger number of tasks to be processed or a longer round-trip communication time, then the earliest connection time of the candidate park operation vehicle may be later than that of the other candidate park operation vehicle.

[0034] Example 7: After obtaining the earliest connection time for each candidate park operation vehicle in the candidate park operation vehicle set, the cloud-based operation scheduling platform 100 compares the available vehicle order based on the remaining task time with the actual cloud-edge connection order based on the earliest connection time. When the two are inconsistent, the cloud-based operation scheduling platform 100 generates an order reversal relationship and forms a cloud-edge connection order reversal band 600. The available vehicle order represents the order obtained solely based on the remaining task time in ascending order; the actual cloud-edge connection order represents the order obtained based on the earliest connection time in ascending order.

[0035] For the first candidate park operation vehicles Second candidate park operation vehicles When the first candidate park operating vehicles The remaining time for the task is shorter than that of the second candidate park operation vehicle. The remaining time for the task, and the first candidate park operation vehicle The earliest connection time was later than that of the second candidate park operating vehicles. At the earliest possible connection time, the cloud-based operation and dispatch platform will select the first candidate park operation vehicle. Vehicles operating in the second candidate park This record represents a group of candidate park operation vehicles with a reversed order relationship. Reversal marker. It can be determined in the following way.

[0036]

[0037]

[0038] Reverse mark Used to record the operating vehicles of the first candidate park Second candidate park operation vehicles Has the sequential relationship between them been reversed? When Pick At that time, the cloud-based operation and dispatch platform 100 treats the candidate park operation vehicle pair as an object with a reversed order relationship; when Pick At that time, the candidate park's operating vehicles did not enter the cloud-edge connection sequence reversal zone 600. The cloud operation scheduling platform summarized all reversal markers as follows. The candidate park operation vehicle pairs are selected to limit the scope of subsequent local sorting adjustments.

[0039]

[0040] In this specific implementation, the corresponding cloud-edge continuation order reversal band 600 is within the set. Corresponding to the first candidate park operation vehicles Vehicles operating in the second candidate park The candidate park operation vehicle pairs constitute the set of relationships or local sorting adjustment range formed by the candidate park operation vehicle pairs in the current operating state. The cloud-edge continuation order reversal band 600 is used.

[0041] Example 8: The cloud-based operation and dispatch platform 100 utilizes the cloud-edge connection order reversal zone 600 to perform partial sorting adjustments only on candidate park operation vehicles with a reversal relationship. For candidate park operation vehicles not within the cloud-edge connection order reversal zone 600, the cloud-based operation and dispatch platform 100 maintains the vehicle's own available order; for candidate park operation vehicles within the cloud-edge connection order reversal zone 600, the cloud-based operation and dispatch platform 100 re-determines the local priority order based on the earliest connection time.

[0042] When generating the real-time scheduling table 700, the cloud-based operation scheduling platform 100 first sorts the real-time operation tasks to be assigned according to the task completion time, task occurrence time, and task priority. Then, it prioritizes selecting idle park operation vehicles 400 from the candidate park operation vehicle set corresponding to each real-time operation task. If there is no order reversal relationship between the candidate park operation vehicles, the cloud-based operation scheduling platform 100 continues to generate candidate orders in ascending order of remaining task time. If there is an order reversal relationship between the candidate park operation vehicles, the cloud-based operation scheduling platform 100 performs local sorting adjustments on the relevant candidate park operation vehicles based on the earliest connection time, from smallest to largest.

[0043] The real-time scheduling table 700 can include a task number, vehicle number, target area edge node, planned start time, and scheduling version number. The scheduling version number is used by the area edge node 200 to determine if the scheduling result is the latest version when receiving scheduling instructions. The task number is used for status merging between the cloud-based operation scheduling platform 100 and the area edge node 200. The vehicle number points to the specific park operation vehicle 400, and the target area edge node determines the recipient of the scheduling instruction. If multiple candidate park operation vehicles have the same earliest connection time, the cloud-based operation scheduling platform 100 can process them according to the order determined by the vehicle number or the most recent task completion time; this processing follows a standard parallel sorting rule.

[0044] Example 9: After generating a real-time dispatch table 700 based on the candidate park operation vehicle order after local sorting adjustments, the cloud-based operation dispatch platform 100 outputs corresponding dispatch instructions via the regional edge node 200. Specifically, the cloud-based operation dispatch platform 100 splits the real-time dispatch table 700 by the regional edge node 200 and sends the split dispatch results to the corresponding regional edge node 200. Upon receiving the results, the regional edge node 200 checks the vehicle running status, task status, and dispatch version number in the real-time dispatch table 700. If the checks pass, it forwards the real-time operation task to the vehicle terminal 300.

[0045] After receiving the scheduling instruction forwarded by the regional edge node 200, the vehicle terminal 300 returns a task confirmation result. The task confirmation result can indicate acceptance, rejection, or postponement of confirmation. The regional edge node 200 transmits the task confirmation result returned by the vehicle terminal 300 back to the cloud-based operation and scheduling platform 100. The cloud-based operation and scheduling platform 100 updates the task status based on the task confirmation result and archives the scheduling instruction sending time, the regional edge node 200 receiving time, the vehicle terminal 300 confirmation time, and the scheduling version number. These status records are used for subsequent task deduplication, status merging, and abnormal reassignment.

[0046] Example 10: When the regional edge node 200 is unable to communicate with the cloud-based operation and dispatch platform 100 within a preset communication confirmation time stored by the regional edge node 200, or when the dispatch instruction is not delivered to the park operation vehicle 400, the regional edge node 200 performs edge backup dispatch from among the park operation vehicles 400 that are idle locally and meet the requirements of load, service area, and task type. The preset communication confirmation time can be determined by existing operation and maintenance configurations, interface timeout time, or business response time limits, and is a standard communication confirmation condition. Edge backup dispatch is used to prevent real-time operation tasks from being stalled for extended periods when the cloud-based operation and dispatch platform 100 is temporarily unreachable or the dispatch instruction is not confirmed.

[0047] When the regional edge node 200 performs edge backup scheduling, it can allocate tasks locally based on the task occurrence time and the idle status of the park operation vehicles 400, and generate temporary scheduling records. These temporary scheduling records must at least identify the real-time operation task, the park operation vehicle 400, the regional edge node 200, and the generation time. After communication with the cloud-based operation scheduling platform 100 is restored, the regional edge node 200 uploads the temporary scheduling records to the cloud-based operation scheduling platform 100. The cloud-based operation scheduling platform 100 then performs task deduplication and status merging based on the task number, vehicle number, and scheduling version number to prevent the same real-time operation task from being executed repeatedly.

[0048] Edge backup scheduling is triggered when the cloud-based operation and scheduling platform 100 becomes unreachable or the scheduling command is not delivered to the park's operating vehicle 400. The processing result is sent back to the cloud-based operation and scheduling platform 100 after communication is restored, and the cloud-based operation and scheduling platform 100 performs state merging. This preserves the local continuous operation capability of the regional edge node 200 while avoiding duplicate scheduling results with the cloud-based operation and scheduling platform 100.

[0049] Example 11: During the real-time operation of park vehicles 400, vehicle terminals 300 report execution statuses such as acceptance, arrival, start of operation, departure, and completion to the regional edge node 200. The regional edge node 200 synchronously updates the remaining task time, the number of pending tasks, and the round-trip communication time, and uploads the updated vehicle status information to the cloud-based operation scheduling platform 100. Based on this, the cloud-based operation scheduling platform 100 re-determines the earliest pick-up time for relevant candidate park vehicles and updates the order reversal relationship and the cloud-edge pick-up order reversal band 600.

[0050] Before a real-time operation task is confirmed by the vehicle terminal 300, if a new order reversal relationship emerges between the originally assigned park operation vehicle 400 and other candidate park operation vehicles, and the earliest connection time of the other candidate park operation vehicles is earlier, the cloud-based operation scheduling platform 100 will only re-execute a partial candidate sorting and update the scheduling version number for the affected real-time operation tasks. Unaffected real-time operation tasks and park operation vehicles 400 will maintain their original scheduling results and will not be rearranged as a whole due to the partial changes in the cloud-edge connection order reversal belt 600.

[0051] For routine anomalies such as vehicle terminal 300 rejection, park operation vehicle 400 malfunction, timeout failure to start, or cancellation of real-time operation tasks, the cloud-based operation scheduling platform 100 can re-place the corresponding real-time operation task in the pending allocation state and regenerate a new set of candidate park operation vehicles. For real-time operation tasks already in progress, they are not automatically reassigned due to changes in the order of execution; reassignment only occurs when a park operation vehicle 400 malfunctions or the real-time operation task is terminated, after manual confirmation or confirmation by existing business rules. This constraint prevents already executed real-time operation tasks from being repeatedly reassigned.

[0052] As an alternative implementation, the local task queues 500 of multiple regional edge nodes 200 are nearly empty, and the round-trip communication time is within a stable range. At this time, for two candidate park operation vehicles... and ,like ,because and The differences are small, usually there are The cloud-based operation and dispatch platform will not create a reversed order relationship without basis; the order of candidate park operation vehicles basically maintains the order in which the vehicles are available.

[0053] As an optional implementation method, the remaining task time for park operation vehicle A is Seconds, the edge node of the region has 200 The number of pending tasks has a round-trip communication time of [time missing]. seconds; the remaining time for task B of the park operation vehicle is Seconds, the edge node of the region has 200 The number of pending tasks has a round-trip communication time of [time missing]. Seconds. The earliest corresponding connection time is as follows.

[0054]

[0055]

[0056] Although ,but Therefore, park operation vehicle A and park operation vehicle B form a reversed order relationship. The cloud-based operation scheduling platform 100 includes this group of candidate park operation vehicles in the cloud-edge sequential reversed order zone 600, and prioritizes park operation vehicle B in the local sorting adjustment, so that the next real-time operation task can enter the confirmation and execution state earlier.

[0057] As an optional implementation, if the regional edge node 200 is unable to communicate with the cloud-based operation and dispatch platform 100 within a preset communication confirmation time, or if the dispatch instructions are not delivered to the park operation vehicle 400, the regional edge node 200 will perform edge backup dispatch from among the park operation vehicles 400 that are idle locally and meet the requirements of load, service area, and task type, and generate a temporary dispatch record. After communication is restored, the regional edge node 200 will upload the temporary dispatch record to the cloud-based operation and dispatch platform 100, and the cloud-based operation and dispatch platform 100 will perform task deduplication and status merging based on the task number and dispatch version number. This operating condition ensures that real-time operation tasks can still be processed locally when cloud-edge communication is abnormal, and will return to the unified status management of the cloud-based operation and dispatch platform 100 after communication is restored.

[0058] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A real-time operation scheduling method based on cloud-edge collaboration, applied to an operation system where a cloud-based operation scheduling platform and regional edge nodes collaboratively manage park operation vehicles, characterized in that... include: The cloud-based operation and scheduling platform obtains real-time operation tasks and vehicle status information of park operation vehicles, and generates a candidate set of park operation vehicles based on the real-time operation tasks and vehicle status information. For each candidate park operation vehicle in the candidate park operation vehicle set, obtain the remaining task time, the number of tasks to be processed, and the round-trip communication time. The earliest possible time for the candidate park operation vehicle to receive the next real-time operation task is determined based on the remaining time of the task, the number of tasks to be processed, and the round-trip communication time. Compare the available order of candidate park operating vehicles formed by the remaining time of the task with the actual cloud-edge connection order formed by the earliest connection time. When the two are inconsistent, generate an order reversal relationship and form a cloud-edge connection order reversal band. The cloud-edge continuation order reversal band is used to perform local sorting adjustments only on candidate park operation vehicles that have the order reversal relationship. A real-time scheduling table is generated based on the candidate park operation vehicle order after local sorting adjustment, and the corresponding scheduling instructions are output through the edge node of the region.

2. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, The real-time operation tasks collected by the regional edge nodes include task number, task type, task occurrence time, operation location, target location, required completion time, load requirement, and task status. A local queue of tasks to be processed is maintained according to the task occurrence time, required completion time, and task status. The number of tasks to be processed is obtained from the records of uncompleted or unconfirmed real-time operation tasks in the local queue of tasks to be processed.

3. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, The regional edge node collects vehicle status information of park operating vehicles, including receiving vehicle location, current task stage, estimated end time, available load, vehicle operating status and task confirmation status reported by vehicle terminals, and determines the remaining time of the task based on the current task stage, current time and estimated end time.

4. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, Determining the earliest connection time includes: Based on the remaining time required for the park's operating vehicles to complete the current task, the local task queue status of the regional edge nodes represented by the number of tasks to be processed, and the communication status between the regional edge nodes and the cloud-based operation and scheduling platform represented by the round-trip communication time, the earliest possible connection time for the park's operating vehicles to receive the next real-time operation task is determined.

5. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, Generating the order reversal relation includes: When the remaining task time of the first candidate park operation vehicle is shorter than that of the second candidate park operation vehicle, and the earliest pick-up time of the first candidate park operation vehicle is later than that of the second candidate park operation vehicle, the first candidate park operation vehicle and the second candidate park operation vehicle are recorded as a group of candidate park operation vehicles with the aforementioned order reversal relationship.

6. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, Generating the candidate set of park operation vehicles includes: For real-time operational tasks with a pending task status, park operation vehicles with offline, faulty, or suspended service status, as well as park operation vehicles with insufficient available load or that do not support the task type, are excluded. Park operation vehicles that can participate in the allocation are determined based on service area, permitted cross-regional range, vehicle location, work location, and target location.

7. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, The local sorting adjustment includes: For candidate park operation vehicles that are not in the cloud-edge connection order reversal zone, the vehicle's own available order is maintained. For candidate park operation vehicles that are in the cloud-edge connection order reversal zone, the local order is re-determined according to the earliest connection time. When multiple candidate park operation vehicles have the same earliest connection time, they are processed according to the order determined by the vehicle number or the most recent task completion time.

8. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, The dispatch instructions include: The cloud-based operation and scheduling platform splits the real-time scheduling table into regional edge nodes and sends them to the corresponding regional edge nodes. After checking the vehicle running status, task status, and scheduling version number in the real-time scheduling table, the regional edge node forwards the real-time operation task to the vehicle terminal and sends the task confirmation result returned by the vehicle terminal back to the cloud-based operation and scheduling platform.

9. The real-time operation scheduling method based on cloud-edge collaboration according to claim 1, characterized in that, When the regional edge node is unable to communicate with the cloud-based operation and dispatch platform within a preset communication confirmation time stored by the regional edge node, or when the dispatch instruction is not delivered to the park operation vehicle, the regional edge node performs edge backup dispatch from the park operation vehicles that are idle locally and meet the requirements of load, service area and task type, and uploads temporary dispatch records to the cloud-based operation and dispatch platform after communication with the cloud-based operation and dispatch platform is restored for task deduplication and status merging.

10. A real-time operation scheduling system based on cloud-edge collaboration, characterized in that, This includes a cloud-based operation and dispatch platform, regional edge nodes, and vehicle terminals; The regional edge node includes a local task queue maintenance module, a vehicle status information collection module, a round-trip communication time collection module, a data verification and deduplication module, an instruction forwarding and confirmation module, and an edge backup scheduling module; the cloud-based operation and scheduling platform includes a status summary module, an earliest connection time determination module, an order reversal identification module, a candidate park operation vehicle screening module, a real-time scheduling table generation module, a scheduling instruction management module, and a scheduling log archiving module. The status aggregation module is used to receive the remaining task time, the number of tasks to be processed, the round-trip communication time, and the vehicle status information. The earliest connection time determination module is used to determine the earliest connection time based on the remaining task time, the number of tasks to be processed, and the round-trip communication time. The order reversal identification module is used to form the cloud-edge connection order reversal band. The candidate park operation vehicle screening module is used to generate the candidate park operation vehicle set based on the real-time operation task and the vehicle status information. The real-time scheduling table generation module is used to generate the real-time scheduling table using the cloud-edge connection order reversal band. The scheduling instruction management module is used to issue the scheduling instructions; the data verification and deduplication module is used to perform source verification and duplicate record removal on the remaining task time, the number of tasks to be processed, the round-trip communication time, the vehicle status information, and the task status; the scheduling log archiving module is used to archive the real-time scheduling table, the scheduling instructions, and the task confirmation results for status merging; the vehicle terminal includes a vehicle status information reporting unit, a task confirmation unit, and a task status reporting unit; the real-time operation scheduling system is configured to execute the real-time operation scheduling method based on cloud-edge collaboration as described in any one of claims 1 to 9.

Images