A cloud-edge collaborative charging and battery swapping distributed management method and system

CN122554413APending Publication Date: 2026-08-11长城电气股份有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-10
Publication Date
2026-08-11

AI Technical Summary

Technical Problem

[0004]针对以上问题,本申请提供一种云边协同的充换电分布式管理方法及系统,用于至少解决多区域充换电网络中跨区域调度滞后、数据同步固定和局部负荷再分配不及时的问题

Benefits of technology

[0029] By acquiring site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records, and constructing a site load distribution map, a unified expression of site load status, user demand changes, and historical operation patterns is achieved, enabling resource utilization deviations to serve as a clear basis for triggering scheduling.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122554413A_ABST
    Figure CN122554413A_ABST
Patent Text Reader

Abstract

This application belongs to the field of distributed control technology, specifically relating to a cloud-edge collaborative distributed management method and system for charging and swapping. The method includes: acquiring site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records; constructing a site load distribution map and determining resource utilization deviation; determining resource scheduling priority when the resource utilization deviation meets trigger conditions; determining the degree of impact of inter-regional load balancing deviation and synchronization delay based on cross-regional resource scheduling records, and adjusting the data synchronization frequency; determining and correcting the collaborative scheduling path based on resource scheduling priority, data synchronization frequency, and communication quality data; generating local load reallocation instructions based on the target collaborative scheduling path, and updating the cross-regional resource scheduling records based on instruction execution feedback to determine a stable collaborative scheduling path. This application can improve the timeliness of cross-regional resource scheduling and the stability of local load adjustment.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of distributed control technology, specifically relating to a cloud-edge collaborative distributed management method and system for charging and swapping. Background Technology

[0002] With the continuous growth of new energy vehicle ownership, charging and battery swapping infrastructure is gradually evolving from single-site management to multi-regional collaborative management. The number of devices, service requests, energy constraints, and communication links all exhibit high concurrency, strong fluctuations, and cross-regional coupling characteristics. Distributed control can combine centralized decision-making with regional execution, enabling control nodes at different levels to complete data acquisition, load assessment, command issuance, and execution feedback under a unified scheduling objective. This is of great significance for ensuring energy replenishment efficiency, improving equipment utilization, and reducing user waiting time.

[0003] In existing technologies, some management methods rely primarily on the real-time status of individual sites or static rules for scheduling, making it difficult to promptly identify load differences between regions. While some systems introduce centralized scheduling, the lack of coordination between cross-regional resource scheduling records, communication delays, and local execution feedback leads to fixed data synchronization frequencies, delayed adjustments to collaborative paths, and the inability to promptly offload high-load sites. In actual operation, when load fluctuations occur simultaneously in multiple regions, the system is prone to problems such as slow command response, inaccurate selection of collaborative sites, and persistent load imbalances after scheduling, affecting the stable operation of the charging and swapping network. Summary of the Invention

[0004] To address the above issues, this application provides a cloud-edge collaborative distributed management method and system for charging and swapping, which can at least solve the problems of lagging cross-regional scheduling, fixed data synchronization, and untimely local load redistribution in multi-regional charging and swapping networks.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0006] Firstly, this application provides a cloud-edge collaborative distributed management method for charging and swapping, the method comprising:

[0007] Acquire site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records; construct a site load distribution map and determine resource utilization deviation.

[0008] When the resource utilization deviation meets the triggering conditions, the resource scheduling priority is determined based on the site load distribution map and historical resource usage records;

[0009] Based on cross-regional resource scheduling records, determine the degree of impact of load balancing deviation and synchronization delay between regions, and adjust the data synchronization frequency accordingly;

[0010] The collaborative scheduling path is determined based on resource scheduling priority, data synchronization frequency, and communication quality data.

[0011] When the site load in the cooperative scheduling path is unbalanced, the cooperative scheduling path is corrected to obtain the target cooperative scheduling path.

[0012] Based on the target collaborative scheduling path, generate local load redistribution instructions, and update cross-regional resource scheduling records based on instruction execution feedback to determine a stable collaborative scheduling path.

[0013] In one possible implementation, determining the resource utilization deviation includes: determining the overall resource utilization rate of the target site and the average resource utilization rate of each site in the area to which the target site belongs based on the site load distribution map; determining the resource utilization deviation based on the absolute difference between the overall resource utilization rate and the average resource utilization rate; wherein, the overall resource utilization rate is determined based on the charging power occupancy rate, the charging interface occupancy rate, the available ratio of swapped batteries and the number of users queuing, and the overall resource utilization rate is negatively correlated with the available ratio of swapped batteries.

[0014] In one possible implementation, the resource utilization deviation meets the triggering conditions, including: the resource utilization deviation exceeds a preset deviation threshold in at least two collection cycles.

[0015] In one possible implementation, resource scheduling priority is determined based on site load distribution maps and historical resource usage records, including: identifying sites to be coordinated based on resource utilization deviations, and identifying candidate sites with available resource reserves based on site load distribution maps; determining the frequency and duration of high load occurrences for sites to be coordinated based on historical resource usage records; and determining resource scheduling priority based on resource utilization deviations, high load frequency, high load duration, and available resource reserves of candidate sites.

[0016] In one possible implementation, the degree of impact of inter-regional load balancing deviation and synchronization delay is determined based on cross-regional resource scheduling records, including: determining the inter-regional load balancing deviation based on the pre-scheduling site load, post-scheduling site load, and number of sites within the region in the cross-regional resource scheduling records; and determining the degree of impact of synchronization delay based on the time interval between the scheduling instruction generation time, scheduling instruction issuance time, site response confirmation time, and execution feedback time in the cross-regional resource scheduling records, as well as the change in post-scheduling site load relative to pre-scheduling site load.

[0017] In one possible implementation, adjusting the data synchronization frequency includes: increasing the data synchronization frequency of the target area when the inter-regional load balancing deviation exceeds a preset balance deviation threshold and the impact of synchronization delay exceeds a preset delay threshold; wherein the target area is the area in the cross-regional resource scheduling record that participates in resource scheduling and is used to determine the inter-regional load balancing deviation.

[0018] In one possible implementation, the charging and swapping network includes a cloud-side management platform, regional edge collaborative nodes, and site control terminals. Communication quality data includes communication latency, available bandwidth, packet loss rate, and node online status between the cloud-side management platform, regional edge collaborative nodes, and site control terminals. The collaborative scheduling path is determined based on resource scheduling priority, data synchronization frequency, and communication quality data, including: determining the data synchronization path and scheduling instruction issuance path based on the data synchronization frequency and communication quality data; determining the site resource scheduling path based on resource scheduling priority; and determining the collaborative scheduling path based on the data synchronization path, scheduling instruction issuance path, and site resource scheduling path.

[0019] In one possible implementation, modifying the collaborative scheduling path to obtain the target collaborative scheduling path includes: adjusting the site resource scheduling path according to resource scheduling priority when the site load in the site resource scheduling path is unbalanced; adjusting the data synchronization path or scheduling instruction issuance path according to communication quality data when the communication quality data corresponding to the data synchronization path or scheduling instruction issuance path does not meet the preset communication conditions; and updating the collaborative scheduling path according to the adjusted path to obtain the target collaborative scheduling path.

[0020] In one possible implementation, generating a local load redistribution instruction based on the target collaborative scheduling path includes: determining the sites to be adjusted and the load adjustment method based on the target collaborative scheduling path, and generating a local load redistribution instruction based on the load adjustment method; wherein, the load adjustment method includes at least one of charging power adjustment, battery swapping allocation, and user diversion guidance; the instruction execution feedback includes instruction execution status, execution completion time, and resource utilization deviation after execution.

[0021] Secondly, this application provides a cloud-edge collaborative distributed management system for charging and swapping, used to implement a cloud-edge collaborative distributed management method for charging and swapping. The system includes:

[0022] The load analysis module is used to acquire site operation status data, user demand data, historical resource usage records and cross-regional resource scheduling records, construct site load distribution maps and determine resource utilization deviations;

[0023] The priority module is used to determine the resource scheduling priority based on the site load distribution map and historical resource usage records when the resource utilization deviation meets the triggering conditions.

[0024] The frequency adjustment module is used to determine the degree of impact of load balancing deviation and synchronization delay between regions based on cross-regional resource scheduling records, and to adjust the data synchronization frequency.

[0025] The path determination module is used to determine the cooperative scheduling path based on resource scheduling priority, data synchronization frequency, and communication quality data.

[0026] The path correction module is used to correct the collaborative scheduling path when the site load is unbalanced in the collaborative scheduling path, so as to obtain the target collaborative scheduling path.

[0027] The instruction feedback module is used to generate local load redistribution instructions based on the target collaborative scheduling path, and update the cross-regional resource scheduling record based on instruction execution feedback to determine a stable collaborative scheduling path.

[0028] Compared with existing technologies, the advantages and beneficial effects of this application are as follows:

[0029] By acquiring site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records, and constructing a site load distribution map, a unified expression of site load status, user demand changes, and historical operation patterns is achieved, enabling resource utilization deviations to serve as a clear basis for triggering scheduling.

[0030] By combining site load distribution maps and historical resource usage records when resource utilization deviations meet trigger conditions to determine resource scheduling priorities, a joint judgment on current load anomalies and historical high load patterns is achieved, avoiding misscheduling caused by relying solely on instantaneous data.

[0031] By determining the impact of load imbalance and synchronization delay between regions based on cross-regional resource scheduling records, and adjusting the data synchronization frequency accordingly, the correlation processing between load imbalance and data synchronization lag is realized, enabling key areas to obtain more timely data updates.

[0032] By determining the collaborative scheduling path based on resource scheduling priority, data synchronization frequency, and communication quality data, and correcting the collaborative scheduling path when site load is unbalanced, the coordinated adjustment of resource scheduling path and communication transmission path is realized.

[0033] By generating local load redistribution instructions based on the target collaborative scheduling path and updating cross-regional resource scheduling records using instruction execution feedback, the scheduling execution results are used to correct subsequent collaborative paths in reverse, forming a continuous closed-loop control. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating the method described in this application;

[0035] Figure 2 This is a block diagram of the module composition of the system in this application. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solution, the present application will be described in detail below with reference to the embodiments. The description in this section is only exemplary and explanatory, and should not be used to limit the scope of protection of the present application in any way.

[0037] Cloud-edge collaboration refers to the coordinated configuration of the cloud's global data aggregation, cross-regional analysis, and policy generation capabilities with the edge's proximity sensing, rapid response, and local execution capabilities, enabling the system to complete hierarchical decision-making and distributed control under a unified control objective. For charging and swapping networks, the cloud is suitable for processing cross-regional resource scheduling records, historical resource usage records, communication quality data, and global load relationships, while the edge is suitable for receiving site operation status data, identifying local load changes, and executing site control commands. Therefore, this application, under the cloud-edge collaborative architecture, incorporates site load distribution, resource scheduling priority, data synchronization frequency, collaborative scheduling paths, and command execution feedback into the same control link, enabling cross-regional scheduling and local load reallocation to form a closed loop according to the process of data acquisition, path determination, command execution, and feedback updates.

[0038] like Figure 1 As shown, a cloud-edge collaborative distributed management method for charging and swapping includes:

[0039] Acquire site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records; construct a site load distribution map and determine resource utilization deviation.

[0040] During the operation of the charging and battery swapping network, the cloud-side management platform receives site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records uploaded by edge collaborative nodes in various regions. Site operation status data includes the online status of charging equipment, charging power, charging interface occupancy status, battery swapping inventory, battery swapping equipment status, and site queuing information. User demand data includes scheduled charging demand, scheduled battery swapping demand, user arrival time, expected service time, and acceptable waiting time. The cloud-side management platform aligns the above data according to a unified time window, removing data that is obviously missing, duplicate, or exceeds the physical limits of the equipment, forming a site load dataset. Based on site identifiers, region identifiers, and the schedulable relationships between sites, each site is configured as a site node, each region as a region node, and the schedulable relationships between sites are configured as cross-regional scheduling edges, forming a site load distribution map. Nodes in the site load distribution map record the current resource usage status, and edges record the direction, distance, and historical scheduling relationships for resource collaboration between sites. The cloud-based management platform calculates the resource utilization deviation of each site relative to the average level of its region based on the site load distribution map, and uses the resource utilization deviation as input for subsequent triggering of scheduling judgments and generation of resource scheduling priorities.

[0041] Determining the resource utilization deviation includes: determining the overall resource utilization rate of the target site and the average resource utilization rate of each site in the area to which the target site belongs based on the site load distribution map; determining the resource utilization deviation based on the absolute difference between the overall resource utilization rate and the average resource utilization rate; wherein, the overall resource utilization rate is determined based on the charging power occupancy rate, the charging interface occupancy rate, the available ratio of swapped batteries and the number of users queuing, and the overall resource utilization rate is negatively correlated with the available ratio of swapped batteries.

[0042] In one embodiment, to ensure that resource utilization deviation simultaneously reflects charging service pressure, battery swapping service pressure, and user waiting pressure, the determination process for resource utilization deviation is further limited to comparing the overall resource utilization rate of the target site with the average resource utilization rate of all sites within the target site's area. The target site can be any site on the site load distribution map, or a site showing signs of high load during the current data collection period. The overall resource utilization rate is not directly represented by a single device occupancy rate, but is determined jointly by multiple resource occupancy states, enabling the value to reflect the site's overall carrying capacity in terms of charging, battery swapping, and user services.

[0043] The overall resource utilization rate of the target site at the time of data collection can be determined as follows:

[0044]

[0045] in, This represents the overall resource utilization rate of the target site at the time of data collection. Number the target site; The time of data collection; The charging power utilization rate of the target site at the time of data collection is determined by the ratio of the actual output power of the target site to the maximum available charging power. The charging interface occupancy rate of the target site at the time of data collection is determined by the ratio of the number of occupied charging interfaces to the number of available charging interfaces. The user queuing ratio at the target site at the time of data collection is determined by the ratio of the number of queuing users to the site's acceptable queuing limit. The percentage of batteries available for swapping at the target site at the time of data collection is determined by the ratio of the number of batteries available for swapping to the number of batteries configured for swapping. , , and These are weighting parameters, representing the impact of charging power, charging interface, user queuing, and battery swapping on the site's resource utilization. Their values ​​are set based on the site's service type, historical peak load records, and operational management rules. Since a higher battery swapping availability ratio results in lower pressure on the battery swapping service, the formula uses... This indicates the contribution of insufficient battery swapping capacity to the overall resource utilization rate, thus maintaining a negative correlation between the overall resource utilization rate and the available battery swapping capacity.

[0046] The average resource utilization rate of all stations within the target site's area is calculated based on the comprehensive resource utilization rate of stations within the same area at the same data collection time. The area can be determined according to the power grid access area, administrative operation area, or edge collaborative node management scope, and must be kept consistent in the system configuration. Resource utilization rate deviations can be determined as follows:

[0047]

[0048] in, This refers to the resource utilization deviation of the target site at the time of data collection. This represents the average resource utilization rate of the target site's region at the time of data collection. The target site is assigned a region number. The formula takes the target site's overall resource utilization rate and the region's average resource utilization rate as input, and outputs the resource utilization rate deviation. This deviation indicates the degree of the target site's deviance from the region's average load level. When this deviation consistently exceeds the system's set trigger conditions, it indicates a identifiable load difference between the target site and other sites within the region, allowing the process to proceed to the resource scheduling priority determination stage.

[0049] To avoid misjudgments caused by a sudden surge in user arrivals or short-term communication jitter, the data collection period and triggering conditions are set based on the intensity of site service fluctuations. Shorter collection periods can be used for urban fast-charging stations, highway service area charging stations, and sites with high battery swapping frequency; longer collection periods can be used for ordinary sites with slower load changes. At the end of each collection period, the system updates the site load distribution map and saves the target site's overall resource utilization rate, regional average resource utilization rate, and resource utilization rate deviation. If a target site experiences equipment failure, communication downtime, or battery maintenance lockout, the corresponding data is not directly included in the regional average resource utilization rate calculation; instead, the cause of the anomaly is recorded separately to prevent abnormal sites from raising or lowering the regional average. Through this processing method, the resource utilization rate deviation can serve as a stable input for subsequent scheduling decisions and maintain consistency with the regional relationships in the site load distribution map.

[0050] When the resource utilization deviation meets the triggering conditions, the resource scheduling priority is determined based on the site load distribution map and historical resource usage records;

[0051] After the resource utilization deviation is calculated, the cloud-side management platform reads the site load distribution map and historical resource usage records according to the collection cycle, and judges the continuity of deviation changes for each site. If the resource utilization deviation of a certain site exceeds the deviation threshold within a set number of consecutive collection cycles, the cloud-side management platform marks the site as a site to be coordinated. Based on the site load distribution map, the system identifies candidate coordinating sites located in the same operating area, adjacent power supply area, or within the acceptable user diversion range as the site to be coordinated, and reads the frequency and duration of high load occurrences for the corresponding time period in the historical resource usage records. The cloud-side management platform uses the current deviation level, historical high load characteristics, and available resource reserves of the candidate coordinating sites as sorting criteria to determine resource scheduling priority. The resource scheduling priority serves as the input for subsequently determining the cooperative scheduling path and generating local load reallocation instructions.

[0052] Resource utilization deviation meets the triggering conditions, including: the resource utilization deviation exceeds the preset deviation threshold in at least two collection periods.

[0053] In one embodiment, to avoid misjudging a site as needing scheduling due to short-term concentrated user arrivals, single-data collection anomalies, or communication jitter, the determination process for resource utilization deviation meeting the trigger condition is further limited to at least two data collection cycles exceeding the deviation threshold. The data collection cycle is configured by the cloud-side management platform according to the site type, service fluctuation intensity, and communication transmission capacity. Shorter data collection cycles can be used for urban fast charging stations and highway service area charging stations with significant peak fluctuations; longer data collection cycles can be used for ordinary operating sites where user arrivals are relatively stable. The data collection cycle should not be set too short to avoid the communication link being occupied by a large amount of status data; nor should it be set too long to avoid delayed identification of load anomalies.

[0054] The deviation threshold is determined based on the site's historical operation records and operational management rules. The cloud-based management platform can select the distribution data of resource utilization deviations of sites in the same region within the most recent statistical period, and use the deviation value that exceeds the normal fluctuation range as the deviation threshold; alternatively, it can be manually configured based on the site's service capacity, power supply capacity, lower limit of battery swapping inventory, and upper limit of user queuing. For newly connected sites, the system can adopt the initial deviation threshold of similar sites and update it after accumulating operational data. The deviation threshold is used to determine whether the target site significantly deviates from the regional average load level, and is not used to directly indicate the site's fault status.

[0055] The number of consecutive data collection cycles is set based on the rate of change of site load. For scenarios with rapid load changes, a smaller number of consecutive collection cycles can be set, enabling the system to quickly identify high-load sites. For scenarios with slow load changes or large data fluctuations, a larger number of consecutive collection cycles can be set to improve the stability of the judgment. The cloud-side management platform saves the resource utilization deviation and collection timestamp within each collection cycle and updates the number of consecutive threshold exceedances at the end of a new collection cycle. If the resource utilization deviation of the current collection cycle does not exceed the deviation threshold, the number of consecutive threshold exceedances is reset to zero; if the number of consecutive threshold exceedances reaches the set number, the system marks the corresponding site as a site requiring coordination.

[0056] During the judgment process, if a target site experiences equipment offline, unresponsive on-site control terminal, battery swapping equipment maintenance lockout, or missing data fields, the cloud-side management platform will not directly trigger scheduling based on the deviation value of that collection period. Instead, it will mark that collection period as invalid and record the reason for the anomaly. If the number of invalid periods continuously reaches the system's set limit, the cloud-side management platform will transfer the site to an abnormal state and will no longer consider it as a candidate for resource scheduling. Through this processing method, the triggering conditions can distinguish between actual load imbalance and data anomalies, ensuring that sites entering the resource scheduling priority ranking have a stable data foundation and actual scheduling value.

[0057] The resource scheduling priority is determined based on the site load distribution map and historical resource usage records, including: identifying sites to be coordinated based on resource utilization deviation, and identifying candidate sites with available resource reserves based on the site load distribution map; determining the frequency and duration of high load occurrences for sites to be coordinated based on historical resource usage records; and determining the resource scheduling priority based on resource utilization deviation, frequency of high load occurrences, duration of high load, and available resource reserves of candidate sites.

[0058] In one embodiment, to ensure that resource scheduling priority simultaneously reflects the current load deviation, historical high load patterns, and schedulable resource conditions, the process of determining resource scheduling priority is further limited to jointly ranking the sites to be coordinated and the candidate coordinating sites. When the cloud-side management platform determines the sites to be coordinated based on resource utilization deviation, it includes sites that continuously meet the triggering conditions in the set of sites to be coordinated. Sites with schedulable relationships with the sites to be coordinated in the site load distribution map are screened as candidate coordinating sites. Schedulable relationships include power supply area allowing coordination, geographical distance within an acceptable range for users, site communication link reachability, matching site service types, and the site having sufficient resource margin to accommodate scheduling demands.

[0059] The available resource margin of candidate collaborative sites is determined based on available charging power, idle charging interfaces, available battery swapping capacity, and current queuing pressure. Available charging power represents the charging power a candidate collaborative site can continue to handle without exceeding its internal power supply capacity and equipment operating limits. Idle charging interfaces represent the number of charging interfaces a candidate collaborative site can provide service immediately or within a set time window. Available battery swapping capacity represents the number of batteries a candidate collaborative site can still use for battery swapping after maintaining a safety stock. Current queuing pressure represents the relationship between the number of currently queued users at a candidate collaborative site and the site's capacity limit. The cloud-side management platform quantifies the above information to determine the resource margin a candidate collaborative site can handle for load transfer from other sites. If a candidate collaborative site experiences equipment failure, communication downtime, battery swapping capacity below safety stock, or a queue exceeding its capacity limit during the current period, that site will not participate in this round of ranking. Historical resource usage records are used to determine the frequency and duration of high loads at sites to be coordinated within similar time periods. Similar time periods can be defined based on weekdays, holidays, weather conditions, operational area activities, or vehicle arrival patterns. The frequency of high load occurrences indicates the degree of historical repetition of high loads at the sites to be coordinated, while the duration of high loads indicates the length of time that high load conditions occupy scheduling resources.

[0060] Resource scheduling priorities can be determined as follows:

[0061]

[0062] in, Score the resource scheduling priority for the sites to be coordinated; The site number to be coordinated; The standardized value of the resource utilization deviation of the sites to be coordinated; Standardized values ​​for the frequency of high load occurrences at sites to be coordinated; Standardized values ​​for the duration of high load at the sites to be coordinated; Standardized values ​​for available resource reserves of candidate collaborative sites that match the site to be coordinated; , , and This is the priority weight parameter. The input to this formula is the current load deviation, historical high load characteristics, and candidate collaborative resource conditions. The output is a resource scheduling priority score. The higher the score, the more priority the site to be coordinated needs to be in subsequent collaborative scheduling paths.

[0063] Priority weight parameters are set by operation management rules and historical scheduling results. If the system needs to prioritize handling current load surge scenarios, the weight corresponding to resource utilization deviation can be increased; if the system needs to suppress periodic peaks in advance, the weight corresponding to the frequency and duration of high loads can be increased; if the system focuses more on scheduling feasibility, the weight corresponding to the available resource reserves of candidate collaborative sites can be increased. All input values ​​are normalized before participating in the calculation to avoid the influence of differences in the dimensions of power, time, frequency, and resource reserves on the ranking results.

[0064] The cloud-based management platform sorts the sites to be coordinated based on resource scheduling priority scores, and retains at least one candidate cooperating site for each site. If multiple sites have the same score, the system prioritizes the site with a larger number of users queuing, shorter acceptable waiting times, or a larger number of consecutive periods exceeding the threshold. If no candidate cooperating sites exist in the vicinity of a site to be coordinated, the system marks that site as having local resource shortages and uses it as a key node for subsequent data synchronization frequency adjustments and collaborative scheduling path determination. In this way, resource scheduling priority not only indicates the severity of site load but also reflects the feasibility of scheduling, providing stable input for subsequent cross-regional load balancing analysis.

[0065] Based on cross-regional resource scheduling records, determine the degree of impact of load balancing deviation and synchronization delay between regions, and adjust the data synchronization frequency accordingly;

[0066] After prioritizing resource scheduling, the cloud-side management platform reads the cross-regional resource scheduling records associated with the ranking results. These records include the participating regions, sites, scheduling command times, site load changes, and execution feedback status. The cloud-side management platform calculates the inter-regional load balancing deviation based on the site load before and after scheduling, and the number of sites within the region. It also determines the impact of synchronization delay based on the time interval between scheduling command generation, issuance, site response confirmation, and execution feedback. If the inter-regional load balancing deviation exceeds a preset deviation threshold, and the impact of synchronization delay also exceeds a preset delay threshold, it indicates a correlation between cross-regional load differences and data synchronization lag. The cloud-side management platform then designates the region participating in this cross-regional resource scheduling as the target region and increases the data synchronization frequency of the target region, enabling it to provide more timely site status data and execution feedback data during subsequent collaborative scheduling path determination.

[0067] The degree of impact of load balancing deviation and synchronization delay between regions is determined based on cross-regional resource scheduling records, including: determining the load balancing deviation between regions based on the site load before scheduling, the site load after scheduling, and the number of sites in the region in the cross-regional resource scheduling records; and determining the degree of impact of synchronization delay based on the time interval between the time of scheduling instruction generation, the time of scheduling instruction issuance, the time of site response confirmation, and the time of execution feedback in the cross-regional resource scheduling records, as well as the change in site load after scheduling relative to site load before scheduling.

[0068] In one embodiment, to ensure that the inter-regional load balancing deviation reflects the load difference status after cross-regional scheduling, the determination process of the inter-regional load balancing deviation is further limited to calculation based on the pre-scheduling site load, post-scheduling site load, and the number of sites within the region from the cross-regional resource scheduling record. The cross-regional resource scheduling record can be generated by the cloud-side management platform after each cross-regional scheduling execution, or it can be uploaded and aggregated by regional edge collaborative nodes. The pre-scheduling site load represents the resource usage status of each participating site when the scheduling command is generated, and the post-scheduling site load represents the resource usage status of each participating site when the execution feedback is returned. The number of sites within the region uses the number of valid sites participating in this load balancing assessment; valid sites do not include sites that are offline, have equipment maintenance lockouts, or have missing load data.

[0069] For any region, the average load before scheduling and the average load after scheduling can be determined as follows:

[0070]

[0071]

[0072] in, The average load of the region before scheduling; The average load of the region after scheduling; For area code; The number of valid sites participating in the assessment within the region; Station numbers within the region; For the first in the region The site load before scheduling; For the first in the region The formula takes the site load before and after scheduling as inputs from the cross-regional resource scheduling record, the site load after scheduling, and the number of effective sites in the region, and outputs the average load before and after regional scheduling, which is used to provide basic data for load balancing deviations between regions.

[0073] In this embodiment, the inter-regional load balancing deviation is used to represent the degree of load difference between participating regions; a larger value indicates a more significant load difference between regions after scheduling. The inter-regional load balancing deviation can be determined as follows:

[0074]

[0075] in, This refers to the load balance deviation between regions; The number of regions participating in the cross-regional load balancing assessment; This represents the average load after scheduling for each participating region. The output of this formula is used to determine whether cross-regional scheduling has brought the loads of each region closer together. The preset load balancing deviation threshold is set based on the normal range of differences in historical cross-regional scheduling records, site service capacity, and scheduling management requirements. For scenarios with a small number of sites within a region, the cloud-side management platform can use the average results from multiple collection periods to participate in the judgment, avoiding excessive impact of fluctuations in a small number of sites on the load balancing deviation between regions. If load data before and after scheduling is missing, the system will not use this record for calculating the load balancing deviation between regions, but will instead record it as an invalid scheduling evaluation record.

[0076] Adjusting the data synchronization frequency includes: increasing the data synchronization frequency of the target area when the load balancing deviation between regions exceeds a preset balance deviation threshold and the impact of synchronization delay exceeds a preset delay threshold; wherein, the target area is the area in the cross-regional resource scheduling record that participates in resource scheduling and is used to determine the load balancing deviation between regions.

[0077] In one embodiment, to distinguish whether cross-regional load differences are caused by actual resource shortages or by data synchronization and command transmission delays, the determination of the impact of synchronization delay is further limited to analysis combining time intervals and load changes. The cross-regional resource scheduling record stores the time of scheduling command generation, the time of scheduling command issuance, the time of site response confirmation, and the time of execution feedback. The scheduling command generation time is the time when the cloud-side management platform completes the scheduling decision; the scheduling command issuance time is the time when the scheduling command enters the target area communication link; the site response confirmation time is the time when the site control terminal returns confirmation of receipt; and the execution feedback time is the time when the site completes load adjustment and returns the execution result.

[0078] The impact of synchronization delay can be determined as follows:

[0079]

[0080] in, The degree of impact of synchronization delay; The time interval between the issuance of the scheduling instruction and the generation of the scheduling instruction; The time interval between the site's response confirmation and the issuance of the scheduling instruction; The time interval between the execution feedback time and the site response confirmation time; This refers to the deviation value formed when the change in the site load after scheduling relative to the site load before scheduling does not reach the expected adjustment range. , , and The parameter represents the weighting of the delay impact. The input to this formula is the load change before and after each time point in the cross-regional resource scheduling record, and the output is the degree of synchronization delay impact, used to determine whether the data synchronization frequency of the target area needs to be increased.

[0081] The latency impact weighting parameter is set based on communication link characteristics and site execution characteristics. If the system is concerned about the lag between cloud-side decision-making and command entry into the link, it can be increased. Corresponding weights; if the system focuses on the communication reliability from edge nodes to site control terminals, the weights can be increased. Corresponding weights; if the system focuses on the site execution process and feedback return time, the weights can be increased. Corresponding weights; if the system is concerned about insufficient load improvement after scheduling execution, the weights can be increased. Corresponding weights. The preset delay threshold is set based on the distribution of time intervals in historical normal scheduling records and the execution capacity of the sites. The degree of impact of synchronization delays exceeding the normal fluctuation range is used to trigger adjustments to the data synchronization frequency.

[0082] The target area is the region that participates in resource scheduling in the cross-regional resource scheduling record and is used to determine the load balancing deviation between regions. When the load balancing deviation between regions exceeds a preset deviation threshold and the impact of synchronization delay exceeds a preset delay threshold, the cloud-side management platform increases the data synchronization frequency of the target area from the base frequency to a high-frequency monitoring frequency. The high-frequency monitoring frequency cannot exceed the upper limit that the communication link and the regional edge collaborative nodes can bear, to prevent excessive uploading of status data from causing new link congestion. If the communication link is already under high occupancy, the cloud-side management platform prioritizes increasing the synchronization frequency of the sites to be coordinated, candidate collaborative sites, and the target area edge collaborative nodes, while maintaining the base frequency for low-load sites. If the load balancing deviation between regions and the impact of synchronization delay both fall below the threshold within at least two subsequent collection cycles, the cloud-side management platform restores the data synchronization frequency of the target area to the base frequency to avoid long-term high-frequency synchronization occupying communication resources.

[0083] The collaborative scheduling path is determined based on resource scheduling priority, data synchronization frequency, and communication quality data.

[0084] After the data synchronization frequency is adjusted, the cloud-side management platform reads the resource scheduling priority, data synchronization frequency, and communication quality data. Based on the region identifier, site identifier, and communication link identifier, it associates the participating regions, sites, and communication links into the same scheduling view. According to the resource scheduling priority, the cloud-side management platform selects sites to be coordinated and sites that can participate in coordination from the site load distribution map, forming site resource scheduling paths. It also selects data synchronization paths between regional edge coordination nodes based on the data synchronization frequency and communication quality data, as well as scheduling instruction distribution paths for the cloud-side management platform to send scheduling commands to the site control terminals. The cloud-side management platform combines the site resource scheduling paths, data synchronization paths, and scheduling instruction distribution paths to generate collaborative scheduling paths. These collaborative scheduling paths record the participating sites, regional edge coordination nodes, data synchronization direction, scheduling instruction distribution direction, and execution feedback return direction, serving as the basis for path correction and local load reallocation.

[0085] The charging and swapping network includes a cloud-side management platform, regional edge collaborative nodes, and site control terminals. Communication quality data includes communication latency, available bandwidth, packet loss rate, and node online status between the cloud-side management platform, regional edge collaborative nodes, and site control terminals. The collaborative scheduling path is determined based on resource scheduling priority, data synchronization frequency, and communication quality data, including: determining the data synchronization path and scheduling instruction issuance path based on data synchronization frequency and communication quality data; determining the site resource scheduling path based on resource scheduling priority; and determining the collaborative scheduling path based on the data synchronization path, scheduling instruction issuance path, and site resource scheduling path.

[0086] In one embodiment, to ensure that the collaborative scheduling path simultaneously meets the requirements of site resource scheduling and cloud-edge communication transmission, the charging and swapping network may include a cloud-side management platform, regional edge collaborative nodes, and site control terminals. The cloud-side management platform stores cross-regional resource scheduling records, resource scheduling priorities, and data synchronization frequencies. Regional edge collaborative nodes aggregate site operation status data and execution feedback uploaded by site control terminals within their respective regions. Site control terminals receive scheduling instructions and control charging equipment, swapping equipment, or user guidance equipment to perform corresponding actions. Communication quality data is generated by the cloud-side management platform based on link monitoring results and node online detection results. This communication quality data includes communication latency, available bandwidth, packet loss rate, and node online status between the cloud-side management platform, regional edge collaborative nodes, and site control terminals.

[0087] The data synchronization path is used to transmit site operation status data, resource utilization deviations, execution feedback, and cross-regional resource scheduling records. The scheduling instruction issuance path is used to transmit local load redistribution instructions and path correction instructions. Both types of paths need to be selected from available communication links. To avoid selecting paths based solely on a single communication metric, the cloud-side management platform can calculate the path cost of communication links based on communication quality data.

[0088]

[0089] in, The path cost of the communication link; Number the communication link; This refers to the communication delay of the communication link; This serves as a reference upper limit for the system's allowed communication latency; The available bandwidth of the communication link; The upper limit of bandwidth configured for the system; This refers to the packet loss rate of the communication link. This represents the online status of nodes associated with the communication link. The value is 1 when the node is online and 0 when the node is offline. , , and This is the communication quality weight parameter. The formula takes communication quality data as input and outputs the path cost value, used to select the data synchronization path and the scheduling instruction delivery path among multiple available communication links. The smaller the path cost value, the more suitable the communication link is for carrying the scheduling data or instructions for this round.

[0090] Communication quality weight parameters are set according to the type of scheduling service. Status data synchronization has high continuity requirements, so the weights corresponding to available bandwidth and packet loss rate can be appropriately increased; scheduling command issuance has high response time requirements, so the weights corresponding to communication latency and node online status can be appropriately increased. The upper limits for communication latency and bandwidth are determined by the communication standard of the charging / swapping network, the processing capacity of regional edge collaborative nodes, and the response capability of the site control terminal. If a node's online status is offline, the cloud-side management platform will not select that communication link for the data synchronization path or the scheduling command issuance path, and will record the offline node identifier for subsequent path correction.

[0091] Site resource scheduling paths are determined based on resource scheduling priorities. The cloud-side management platform designates higher-priority sites to be coordinated as resource receivers and candidate sites with available resource reserves as resource recipients. The platform then determines the site resource scheduling path between the resource receiver and resource recipient based on region affiliation, service radius, and site service type. When data synchronization paths, scheduling command issuance paths, and site resource scheduling paths are combined, the regional edge collaboration nodes within the path must be consistent or reachable. If a site resource scheduling path spans multiple regions, the cloud-side management platform prioritizes regional edge collaboration nodes that can simultaneously support data synchronization and command issuance. If no regional edge collaboration node simultaneously meets the requirements, the system retains the site resource scheduling path as a candidate path and reselects the communication link or reduces the data synchronization frequency of some low-priority sites during subsequent path correction phases.

[0092] When the site load in the cooperative scheduling path is unbalanced, the cooperative scheduling path is corrected to obtain the target cooperative scheduling path.

[0093] After forming a collaborative scheduling path, the cloud-side management platform reads the site resource scheduling path, data synchronization path, and scheduling command issuance path involved in the path, and verifies the path execution status. Verification includes checking whether there are still significant differences in site load, whether the communication links in the data synchronization path meet the synchronization frequency requirements, and whether the communication links in the scheduling command issuance path meet the response requirements. If high-load sites in the site resource scheduling path are not effectively offloaded, or if the available resources of candidate collaborative sites are insufficient, the cloud-side management platform readjusts the site resource scheduling path according to resource scheduling priority. If the communication quality data of the data synchronization path or scheduling command issuance path does not meet the communication conditions, the cloud-side management platform reselects communication links or enables edge collaborative nodes in the available area. The adjusted site resource scheduling path, data synchronization path, and scheduling command issuance path are recombined into a target collaborative scheduling path for use in generating local load redistribution commands.

[0094] The process of revising the collaborative scheduling path to obtain the target collaborative scheduling path includes: adjusting the site resource scheduling path according to the resource scheduling priority when the site load is unbalanced in the site resource scheduling path; adjusting the data synchronization path or scheduling instruction issuance path according to the communication quality data when the communication quality data corresponding to the data synchronization path or scheduling instruction issuance path does not meet the preset communication conditions; and updating the collaborative scheduling path according to the adjusted path to obtain the target collaborative scheduling path.

[0095] In one embodiment, to enable the correction process of the collaborative scheduling path to distinguish between site load issues and communication link issues, the path correction process is further limited to separately judging the site resource scheduling path, data synchronization path, and scheduling command issuance path. The cloud-side management platform reads the sites to be coordinated and candidate collaborative sites in the site resource scheduling path based on the site load distribution map. If the site to be coordinated still maintains a resource utilization deviation higher than the deviation threshold during the continuous collection period after the path is generated, or if the resource utilization of the candidate collaborative site is close to the operating limit after accepting the scheduling request, the system determines that the site load in the site resource scheduling path is unbalanced. At this time, the communication link is not directly changed, but the candidate collaborative sites are re-determined according to the resource scheduling priority, prioritizing sites that meet the requirements in terms of available charging power, idle charging interfaces, number of available swapped batteries, and user acceptance capacity. If the original candidate collaborative site only has partial resource shortages, such as insufficient number of swapped batteries but idle charging interfaces, the system can retain its charging service acceptance capacity and allocate the battery swapping service demand to other candidate collaborative sites.

[0096] The preset communication conditions are set by the cloud-side management platform according to the data synchronization frequency, scheduling response time limit, and communication link capacity. The communication conditions for the data synchronization path include: communication latency not exceeding the upper limit allowed by the synchronization cycle; available bandwidth sufficient to carry the current round of status data uploads; packet loss rate within a retransmissionable range; and regional edge collaborative nodes being online. The communication conditions for the scheduling command issuance path include: command transmission latency lower than the acceptable time limit for the site control terminal; no continuous packet loss on the link; and stable node online status. If the data synchronization path does not meet the communication conditions, the cloud-side management platform prioritizes a reachable backup regional edge collaborative node within the same area; if the backup regional edge collaborative node is unavailable, the system reduces the data synchronization frequency of low-priority sites, allocating communication resources to sites to be coordinated and candidate collaborative sites. If the scheduling command issuance path does not meet the communication conditions, the cloud-side management platform prioritizes switching to a link with lower latency and online nodes; if necessary, the regional edge collaborative node issues commands to the site control terminal on behalf of the site.

[0097] During path updates, the cloud-side management platform writes the adjusted site resource scheduling path, the adjusted data synchronization path, and the adjusted scheduling instruction issuance path into the same scheduling record, and verifies whether the regional edge collaborative nodes in the three types of paths are reachable, whether the site control terminal is online, and whether the instruction execution window is still within the valid range. If there are inconsistent regional nodes among the three types of paths but they can be connected through available communication links, the system retains that path combination; if there are unreachable nodes, the system continues to fall back to the suboptimal path combination. After the target collaborative scheduling path is generated, the cloud-side management platform synchronously saves the path version, the reason for correction, and the effective time. The path version is used to distinguish between the original path and the corrected path in the same round of scheduling, the reason for correction is used for subsequent analysis of whether the site load imbalance is due to insufficient resources or communication anomalies, and the effective time is used to limit the issuance window of the local load redistribution instruction. Through this process, the path correction result can directly inherit the previous collaborative scheduling path and provide clear site objects and communication channels for the subsequent generation of local load redistribution instructions.

[0098] Based on the target collaborative scheduling path, generate local load redistribution instructions, and update cross-regional resource scheduling records based on instruction execution feedback to determine a stable collaborative scheduling path.

[0099] After obtaining the target collaborative scheduling path, the cloud-side management platform reads the site resource scheduling path, data synchronization path, and scheduling instruction issuance path within the target collaborative scheduling path. Based on the site resource scheduling path, it determines the sites requiring load adjustment and the sites participating in the collaboration. Based on the data synchronization path and scheduling instruction issuance path, it determines the available communication channels. For sites to be adjusted, the cloud-side management platform generates a local load reallocation instruction based on the load source, resource gap, and candidate collaborative site capabilities recorded in the target collaborative scheduling path. This local load reallocation instruction is issued to the site control terminal via the corresponding regional edge collaborative node, and the site control terminal controls the charging equipment, battery swapping equipment, or user guidance equipment to execute it. After execution, the site control terminal returns the instruction execution status, execution completion time, and post-execution resource utilization deviation. The cloud-side management platform updates the cross-regional resource scheduling record based on the instruction execution feedback and determines the path whose execution result meets the stability conditions as a stable collaborative scheduling path.

[0100] The process of generating local load redistribution instructions based on the target collaborative scheduling path includes: determining the sites to be adjusted and the load adjustment method based on the target collaborative scheduling path, and generating local load redistribution instructions based on the load adjustment method; wherein, the load adjustment method includes at least one of charging power adjustment, battery swapping allocation, and user diversion guidance; the instruction execution feedback includes instruction execution status, execution completion time, and resource utilization deviation after execution.

[0101] In one embodiment, to ensure that the local load redistribution instructions are consistent with the target collaborative scheduling path, the generation process of the local load redistribution instructions is further limited to being based on the sites to be adjusted and the load adjustment method. The cloud-side management platform reads the sites to be coordinated, candidate collaborative sites, regional edge collaborative nodes, and instruction issuance paths in the target collaborative scheduling path, and determines the sites to be adjusted by combining real-time data from the site load distribution map. Sites to be adjusted include sites whose resource utilization deviation continuously exceeds the triggering conditions, as well as sites that still need to perform power, battery swapping, or user diversion actions after path correction. If a site has communication offline, equipment maintenance lockout, unavailable charging interface, or battery swapping inventory below the safety value, the site will not be considered as a collaborative site to receive new scheduling requests, but will only be retained as a site to be adjusted that needs to be diverted or have its load limited.

[0102] The load adjustment method is determined based on the type of resource shortage at the site to be adjusted. If the site to be adjusted mainly exhibits excessively high charging power occupancy, the cloud-side management platform generates charging power adjustment content, including reducing the power limit of non-urgent charging tasks, allocating newly scheduled charging demands to candidate collaborative sites, or setting candidate collaborative sites with more idle power as acceptance sites. If the site to be adjusted mainly exhibits excessively low battery availability, the cloud-side management platform generates battery allocation content, including transferring battery swapping demands to sites with higher battery reserves, adjusting the reserved number of battery swapping units, or delaying the execution window of low-priority battery swapping requests. If the site to be adjusted mainly exhibits excessively high user queue lengths, the cloud-side management platform generates user diversion guidance content, including returning candidate collaborative sites to user terminals, estimating waiting times, and acceptable service time windows. Various load adjustment methods can be used individually or in combination within the same local load reallocation instruction. However, when using them in combination, the available resource reserves of candidate collaborative sites must be verified to avoid transferring high load from one site to another.

[0103] After a local load redistribution instruction is issued, the site control terminal controls the load according to the execution time window and load adjustment method specified in the instruction, and returns instruction execution feedback to the regional edge collaborative nodes. Instruction execution feedback includes the instruction execution status, execution completion time, and post-execution resource utilization deviation. The instruction execution status distinguishes between executed, partially executed, failed, and timed out without feedback; the execution completion time determines whether the scheduling instruction was completed within the valid time window; and the post-execution resource utilization deviation determines whether the load difference between the site to be adjusted and the candidate collaborative sites has fallen back to an acceptable range. If the instruction execution status is "execution failed," the cloud-side management platform records the reason for the failure and removes the corresponding site from the current round of stable path confirmation. If the execution completion time exceeds the valid time window in the target collaborative scheduling path, the cloud-side management platform re-triggers path correction without directly confirming path stability.

[0104] The cloud-side management platform updates the cross-regional resource scheduling record based on instruction execution feedback. The update includes the sites to be adjusted in this round, candidate collaborative sites, load adjustment methods, instruction delivery paths, execution results, and post-execution resource utilization deviations. If the updated cross-regional resource scheduling record shows that the resource utilization deviation of participating sites is within the allowable range for at least two data collection cycles, and the communication quality data of the data synchronization path and the scheduling instruction delivery path meets the communication conditions, the cloud-side management platform confirms the target collaborative scheduling path as a stable collaborative scheduling path. Stable collaborative scheduling paths retain participating sites, regional edge collaborative nodes, communication paths, load adjustment methods, and applicable scenarios. When subsequent occurrences of similar regions, similar load types, and similar user demand distributions, the cloud-side management platform can prioritize calling stable collaborative scheduling paths, verifying site resource availability and communication quality data before calling to ensure the path still has execution capabilities.

[0105] like Figure 2 As shown, a cloud-edge collaborative distributed management system for charging and swapping is used to implement a cloud-edge collaborative distributed management method for charging and swapping. The system includes:

[0106] The load analysis module is used to acquire site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records, construct site load distribution maps, and determine resource utilization deviations. The load analysis module consists of a site data acquisition interface, an edge computing processor, a data cache, and a graph data storage unit. It is used to receive data uploaded by charging and swapping equipment, site control terminals, and user servers, and to generate site load distribution maps locally or in the cloud.

[0107] The priority module is used to determine the resource scheduling priority based on the site load distribution map and historical resource usage records when the resource utilization deviation meets the trigger conditions. The priority module consists of a cloud computing server, a historical data storage unit and a sorting processor. It is used to read the resource utilization deviation, the site load distribution map and historical resource usage records and generate the resource scheduling priority.

[0108] The frequency adjustment module is used to determine the degree of impact of load balancing deviation and synchronization delay between regions based on cross-regional resource scheduling records, and to adjust the data synchronization frequency. The frequency adjustment module consists of a communication status acquisition interface, a clock synchronization unit, a network control processor, and a frequency configuration unit. It is used to read cross-regional resource scheduling records and communication delay data, and to adjust the data synchronization frequency of the target region.

[0109] The path determination module is used to determine the collaborative scheduling path based on resource scheduling priority, data synchronization frequency, and communication quality data. The path determination module consists of a cloud-side path calculation server, a network topology storage unit, and a communication quality detection unit, and is used to determine the collaborative scheduling path based on resource scheduling priority, data synchronization frequency, and communication quality data.

[0110] The path correction module is used to correct the cooperative scheduling path when the site load is unbalanced in the cooperative scheduling path, and obtain the target cooperative scheduling path. The path correction module consists of an edge cooperative controller, a backup link selection unit and a path update processor. It is used to correct the cooperative scheduling path and output the target cooperative scheduling path when the site load is unbalanced or the communication link does not meet the conditions.

[0111] The instruction feedback module is used to generate local load redistribution instructions based on the target collaborative scheduling path, and to update the cross-regional resource scheduling record based on instruction execution feedback, thereby determining a stable collaborative scheduling path. The instruction feedback module consists of a site control terminal, an instruction issuance interface, an execution feedback acquisition unit, and a scheduling record storage unit. It is used to generate local load redistribution instructions, receive instruction execution feedback, and update the cross-regional resource scheduling record.

[0112] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the technical solutions of this application. The above examples are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are merely preferred embodiments of this application. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes, or combinations, or the direct application of the concept and technical solutions of this application to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A cloud-edge collaborative charging and battery swapping distributed management method, characterized in that, The method includes: Acquire site operation status data, user demand data, historical resource usage records, and cross-regional resource scheduling records; construct a site load distribution map and determine resource utilization deviation. When the resource utilization deviation meets the triggering condition, the resource scheduling priority is determined based on the site load distribution map and the historical resource usage records; Based on the cross-regional resource scheduling records, determine the degree of impact of load balancing deviation and synchronization delay between regions, and adjust the data synchronization frequency accordingly; The cooperative scheduling path is determined based on the resource scheduling priority, the data synchronization frequency, and the communication quality data. When the site load in the cooperative scheduling path is unbalanced, the cooperative scheduling path is corrected to obtain the target cooperative scheduling path; A local load redistribution instruction is generated based on the target collaborative scheduling path, and the cross-regional resource scheduling record is updated based on the instruction execution feedback to determine a stable collaborative scheduling path.

2. The method according to claim 1, characterized in that, The determination of resource utilization deviation includes: The overall resource utilization rate of the target site and the average resource utilization rate of each site in the area to which the target site belongs are determined based on the site load distribution map. The resource utilization rate deviation is determined based on the absolute difference between the overall resource utilization rate and the average resource utilization rate. The overall resource utilization rate is determined based on the charging power occupancy rate, charging interface occupancy rate, battery swapping availability ratio, and user queue number, and the overall resource utilization rate is negatively correlated with the battery swapping availability ratio.

3. The method according to claim 2, characterized in that, The resource utilization deviation meets the triggering conditions, including: The resource utilization deviation exceeds the preset deviation threshold in at least two collection cycles.

4. The method according to claim 1, characterized in that, The step of determining resource scheduling priority based on the site load distribution map and the historical resource usage records includes: The sites to be coordinated are determined based on the resource utilization deviation, and candidate sites with available resource margins are determined based on the site load distribution map. The frequency and duration of high load occurrences at the sites to be coordinated are determined based on the historical resource usage records. The resource scheduling priority is determined based on the resource utilization deviation, the frequency of high load occurrence, the duration of high load, and the available resource reserves of the candidate collaborative sites.

5. The method according to claim 1, characterized in that, The determination of the impact of inter-regional load balancing deviation and synchronization delay based on the cross-regional resource scheduling records includes: The inter-regional load balancing deviation is determined based on the site load before scheduling, the site load after scheduling, and the number of sites within the region in the cross-regional resource scheduling record. The degree of impact of the synchronization delay is determined based on the time interval between the generation time of the scheduling instruction, the issuance time of the scheduling instruction, the confirmation time of the site response, and the execution feedback time in the cross-regional resource scheduling record, as well as the change in the site load after scheduling relative to the site load before scheduling.

6. The method according to claim 5, characterized in that, The adjustment of the data synchronization frequency includes: If the load balancing deviation between the regions exceeds a preset balance deviation threshold, and the impact of the synchronization delay exceeds a preset delay threshold, the data synchronization frequency of the target region shall be increased. The target region is the region in the cross-regional resource scheduling record that participates in resource scheduling and is used to determine the load balance deviation between regions.

7. The method according to claim 1, characterized in that, The charging and swapping network includes a cloud-side management platform, regional edge collaborative nodes, and site control terminals. The communication quality data includes communication latency, available bandwidth, packet loss rate, and node online status between the cloud-side management platform, the regional edge collaborative nodes, and the site control terminals. The step of determining the cooperative scheduling path based on the resource scheduling priority, the data synchronization frequency, and communication quality data includes: The data synchronization path and the scheduling instruction issuance path are determined based on the data synchronization frequency and the communication quality data. The site resource scheduling path is determined based on the resource scheduling priority. The collaborative scheduling path is determined based on the data synchronization path, the scheduling instruction issuance path, and the site resource scheduling path.

8. The method according to claim 7, characterized in that, The step of revising the cooperative scheduling path to obtain the target cooperative scheduling path includes: In the event of uneven site load in the site resource scheduling path, the site resource scheduling path is adjusted according to the resource scheduling priority; If the communication quality data corresponding to the data synchronization path or the scheduling instruction issuance path does not meet the preset communication conditions, the data synchronization path or the scheduling instruction issuance path shall be adjusted according to the communication quality data. The cooperative scheduling path is updated based on the adjusted path to obtain the target cooperative scheduling path.

9. The method according to claim 1, characterized in that, The step of generating local load redistribution instructions based on the target cooperative scheduling path includes: The site to be adjusted and the load adjustment method are determined according to the target collaborative scheduling path, and the local load redistribution instruction is generated according to the load adjustment method; The load adjustment method includes at least one of charging power adjustment, battery swapping allocation, and user diversion guidance; The instruction execution feedback includes instruction execution status, execution completion time, and resource utilization deviation after execution.

10. A cloud-edge collaborative distributed management system for charging and swapping, used to implement the cloud-edge collaborative distributed management method for charging and swapping as described in any one of claims 1 to 9, characterized in that, The system includes: The load analysis module is used to acquire site operation status data, user demand data, historical resource usage records and cross-regional resource scheduling records, construct site load distribution maps and determine resource utilization deviations; The priority module is used to determine the resource scheduling priority based on the site load distribution map and the historical resource usage records when the resource utilization deviation meets the triggering conditions. The frequency adjustment module is used to determine the degree of impact of inter-regional load balancing deviation and synchronization delay based on the cross-regional resource scheduling records, and to adjust the data synchronization frequency. The path determination module is used to determine the cooperative scheduling path based on the resource scheduling priority, the data synchronization frequency, and communication quality data. The path correction module is used to correct the cooperative scheduling path when the site load in the cooperative scheduling path is unbalanced, so as to obtain the target cooperative scheduling path. The instruction feedback module is used to generate local load redistribution instructions based on the target cooperative scheduling path, and update the cross-regional resource scheduling record based on instruction execution feedback to determine a stable cooperative scheduling path.