Power distribution network fault processing method and system

Abstract

This invention relates to the field of power distribution network fault handling technology, and discloses a method and system for power distribution network fault handling. The method includes receiving fault data from multiple fault points to form a fault dataset; performing cluster analysis on the dataset to obtain one or more fault-affected areas; identifying multiple collaborating entities involved in each fault-affected area and configuring a data interface for each collaborating entity; acquiring the status parameters of all data interfaces and calculating the communication health index of each data interface based on the status parameters; establishing a data exchange link based on the communication health index; obtaining corresponding emergency repair resource status information through this link; and finally using this information to handle the fault in the affected area. The method and system described in this invention fundamentally improve the success rate and efficiency of a single request, and effectively enhance the reliability and stability of acquiring key cross-departmental collaborative data.

Description

Technical Field

[0001] This invention relates to the field of power distribution network fault handling technology, and in particular to a power distribution network fault handling method and system. Background Technology

[0002] After a fault occurs in the power distribution network, efficient and accurate fault handling depends on the rapid and precise allocation of emergency repair resources (such as personnel, vehicles, equipment, and materials). This usually requires the dispatch system to interact with multiple external collaborative departments (also known as collaborative entities), such as power distribution operation and maintenance, material storage, municipal landscaping, and traffic management, to obtain real-time and accurate resource inventory information, personnel location information, and environmental information.

[0003] Currently, cross-departmental (also known as cross-entity) data exchange is mainly achieved through application programming interfaces (APIs). However, in practical applications, the channels for cross-departmental collaborative data exchange suffer from significant instability, severely restricting the efficiency and reliability of fault repair decisions. This is mainly reflected in the following aspects:

[0004] First, the performance status of interfaces in various departmental systems is difficult to perceive and assess in real time. Typically, simple timeout retry mechanisms or statically configured interface priority strategies are used. When requesting data, the scheduling system cannot know the real-time communication quality and historical availability of the target interface. For example, when an interface of a materials management system experiences high latency and high packet loss due to internal network congestion, resource inventory query requests initiated by the scheduling system may remain unresponsive for extended periods or ultimately fail. This blind selection mechanism results in a persistently high failure rate for data requests.

[0005] Secondly, for a specific data service (such as querying crane resources), there may be multiple alternative interfaces that provide similar data (such as the main interface, backup interface, or mirror interfaces of data centers in different regions). It is impossible to dynamically select the optimal path for the current communication status among these alternative interfaces. As a result, the system may continuously send requests to an interface that is already in a semi-paralyzed state, while other healthy interfaces are idle, resulting in low overall coordination efficiency. Summary of the Invention

[0006] Therefore, the purpose of this invention is to overcome the problem of unstable cross-departmental collaborative data exchange channels in the prior art, and to provide a method and system for handling power distribution network faults. By introducing a communication health index, the system dynamically selects the exchange link for cross-departmental collaborative data, avoids unstable data interfaces with high latency and high packet loss, and always tries to obtain data through the best available channel, thereby fundamentally improving the success rate and efficiency of a single request and effectively improving the reliability and stability of obtaining key cross-departmental collaborative data.

[0007] Firstly, to solve the above-mentioned technical problems, the present invention provides a method for handling power distribution network faults, comprising: Receive fault data from multiple fault points to obtain a fault dataset; perform cluster analysis on the fault dataset to obtain one or more fault-affected areas. Identify multiple collaborating entities involved in each of the aforementioned fault-affected areas, and configure a data interface for each of the aforementioned collaborating entities; Obtain the status parameters of all the data interfaces, and calculate the communication health index of each data interface based on the status parameters; wherein, the status parameters include network latency, packet loss rate, and historical request success rate; A data exchange link is established based on the communication health index, and the corresponding emergency repair resource status information is obtained through the data exchange link. Based on the status information of the emergency repair resources, fault handling is performed on the affected area.

[0008] Preferably, cluster analysis of the fault dataset to obtain one or more fault-affected areas includes: for each fault point, extracting geospatial features, power grid topology features, and fault type features from the fault data to obtain three-modal features; calculating the similarity between any two fault points based on the three-modal features; performing cluster analysis on the fault dataset based on the similarity to generate one or more fault point clusters; and outputting a fault-affected area for each fault point cluster.

[0009] Preferably, before calculating the similarity between any two fault points, the method further includes power grid topology feature correction, which includes: determining whether the power grid topology feature of the fault point P is missing; if it is missing, searching for K fault points geographically adjacent to the fault point P in the fault point set; counting the number of fault points belonging to the same feeder among the K fault points; if the number of fault points exceeds a threshold, correcting the power grid topology feature of the fault point P based on the feeder information.

[0010] Preferably, calculating the similarity between any two fault points based on the three-modal features includes: calculating the Euclidean distance between any two fault points based on the geospatial features; calculating the topological distance between any two fault points based on the power grid topology features; calculating the type distance between any two fault points based on the fault type features; and performing a weighted summation of the Euclidean distance, topological distance, and type distance to obtain the similarity; wherein the topological distance has the largest weight.

[0011] Preferably, determining the multiple cooperating entities involved in each of the fault-affected areas includes: performing spatial overlay analysis on the geographical boundaries of the fault-affected areas and the electronic fences of the geographical jurisdiction to obtain a first set of candidate cooperating entities; querying a device-entity mapping table based on the affected devices in the fault-affected areas to obtain a second set of candidate cooperating entities; querying a fault type-entity mapping table based on the fault type of the fault-affected areas to obtain a third set of candidate cooperating entities; and determining the union of the first set of candidate cooperating entities, the second set of candidate cooperating entities, and the third set of candidate cooperating entities as the multiple cooperating entities involved.

[0012] Preferably, before determining the plurality of cooperating entities, the method further includes detecting whether there is an entity conflict; the detection of whether there is an entity conflict includes: for the affected device, if a first entity is mapped based on the device-entity mapping table, and a second entity is matched based on the spatial overlay analysis result of the geographic jurisdiction electronic fence, and the first entity and the second entity are different, then a conflict one is detected; for the fault type, if a third entity is mapped based on the fault type-entity mapping table, and a fourth entity is mapped based on the device-entity mapping table, and the third entity and the fourth entity are different, then a conflict two is detected.

[0013] Preferably, it further includes: if conflict one or conflict two is detected, then conflict resolution is performed; the conflict resolution includes using the subject mapped by the device-subject mapping table as the execution subject.

[0014] Preferably, establishing a data exchange link based on the communication health index includes: maintaining a dynamic routing table, which stores the mapping relationship between data service identifiers, alternative data interface addresses, and communication health indices; querying the dynamic routing table using the data service identifier of the data request as an index to obtain all alternative data interfaces providing the data service and the communication health index corresponding to each alternative data interface; sorting the communication health indices of all alternative data interfaces in descending order, and obtaining the alternative data interface with the highest communication health index as the target data interface; forwarding the data request to the target data interface to obtain the corresponding emergency repair resource status information through the target data interface.

[0015] Preferably, the status parameters include network latency, packet loss rate, and historical request success rate; calculating the communication health index for each data interface based on the status parameters includes: mapping a latency score value based on the network latency; mapping a packet loss score value based on the packet loss rate; mapping a success rate score value based on the historical request success rate; and fusing the latency score value, packet loss score value, and success rate score value to obtain the communication health index.

[0016] Secondly, to solve the above-mentioned technical problems, the present invention provides a power distribution network fault handling system, comprising: The data receiving module is used to receive fault data from multiple fault points and obtain a fault dataset. The clustering analysis module is used to perform clustering analysis on the fault dataset to obtain one or more fault-affected regions; The collaborative entity determination module is used to determine multiple collaborative entities involved in each of the fault-affected areas, and a data interface is configured for each of the collaborative entities. The communication health index calculation module is used to obtain the status parameters of all the data interfaces and calculate the communication health index of each data interface based on the status parameters. The data exchange module is used to establish a data exchange link based on the communication health index and to obtain the corresponding emergency repair resource status information through the data exchange link. The fault handling module is used to handle the fault-affected area based on the emergency repair resource status information.

[0017] Compared with the prior art, the above-described technical solution of the present invention has the following advantages: The power distribution network fault handling method and system described in this invention determines the communication health index based on network latency, packet loss rate, and historical request success rate. Based on the communication health index, it dynamically selects cross-departmental collaborative data exchange links, avoids unstable data interfaces with high latency and high packet loss, and always attempts to obtain data through the best available channel. This fundamentally improves the success rate and efficiency of a single request and effectively enhances the reliability and stability of cross-departmental collaborative data acquisition. Attached Figure Description

[0018] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings, wherein: Figure 1 This is a flowchart of a power distribution network fault handling method in a preferred embodiment of the present invention; Figure 2 This is a flowchart of obtaining the fault-affected area in a preferred embodiment of the present invention; Figure 3 This is a flowchart illustrating the determination of multiple collaborative entities in a preferred embodiment of the present invention; Figure 4 This is a flowchart of establishing a data exchange link in a preferred embodiment of the present invention; Figure 5 This is a structural block diagram of the power distribution network fault handling system in a preferred embodiment of the present invention. Detailed Implementation

[0019] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0020] The purpose of this invention is to overcome the instability of cross-departmental collaborative data exchange channels in the prior art, and to provide a method and system for handling power distribution network faults. By introducing a communication health index, the system dynamically selects the exchange link for cross-departmental collaborative data, avoids unstable data interfaces with high latency and high packet loss, and always tries to obtain data through the best available channel, thereby fundamentally improving the success rate and efficiency of a single request and effectively enhancing the reliability and stability of obtaining key cross-departmental collaborative data.

[0021] Example 1: Refer to Figure 1 As shown, an embodiment of the present invention provides a method for handling power distribution network faults, including: S100: Receive fault data from multiple fault points to obtain a fault dataset; perform cluster analysis on the fault dataset to obtain one or more fault-affected areas; S200. Determine the multiple coordinating entities involved in each of the fault-affected areas, and configure a data interface for each of the coordinating entities; S300. Obtain the status parameters of all the data interfaces, and calculate the communication health index of each data interface based on the status parameters; wherein, the status parameters include network latency, packet loss rate, and historical request success rate; S400. Establish a data exchange link based on the communication health index, and obtain the corresponding emergency repair resource status information through the data exchange link; S500. Based on the emergency repair resource status information, perform fault processing on the affected area.

[0022] In specific application scenarios, fault data is received in real time from multiple sources such as power distribution automation system, electricity consumption information collection system, production management system and user work order system through message queue (such as Kafka, RabbitMQ) or data bus to obtain fault dataset; each data contains at least geographical coordinates and fault type.

[0023] Cluster analysis is performed on the obtained fault dataset to obtain one or more fault-affected areas. Here, the fault-affected area refers to one or more power distribution equipment, such as lines, transformers, switches, etc. After a fault occurs, the geographical range of power outages or abnormal power quality caused by the fault is not the fault point itself, but a continuous area derived from the fault point that needs to be handled collaboratively. It is the processing unit and coordination basis for fault handling. The core characteristics of the fault-affected area include: (1) Geographical continuity: Users and equipment in the area are usually geographically adjacent or connected by the power grid, rather than discrete, isolated points; for example, a feeder tripping will cause a power outage in the entire street or area supplied by the feeder, and this area is a fault-affected area. (2) Electrical correlation: The equipment in the area is closely connected in the power grid topology, and the fault of one equipment will directly affect other equipment through electrical connection. This is the most important technical basis for dividing the area. (3) Operation and maintenance coordination: A fault-affected area may involve the responsibilities of multiple operation and maintenance departments; for example, an area may involve the power transmission department, power distribution department, power service department and external units at the same time. The power transmission department is responsible for high-voltage lines, the power distribution department is responsible for medium and low voltage lines and distribution transformers, the power service department is responsible for user meters and access, and external units, such as municipal departments (repairing the cut cables) and forestry departments (clearing the trees that are pressing on the lines), are also cross-departmental collaborative areas.

[0024] Addressing each fault individually would lead to significant coordination complexity and resource waste. By clustering fault datasets to identify affected areas, numerous scattered fault points can be aggregated into a few key, continuous regional issues. This makes complex fault scenarios clearer and more manageable, facilitating the coordinated allocation of repair resources (manpower, vehicles, and materials). Instead of sending a team to each fault point, a comprehensive repair team can be dispatched to a region, greatly improving efficiency.

[0025] In practice, to facilitate understanding of the area affected by the fault, the following example illustrates the process: Scenario: After the typhoon, a power distribution network in a certain area received hundreds of fault reports.

[0026] Traditional approach: The dispatch center may see a map filled with hundreds of red alerts, making it difficult to quickly sort things out and easily falling into a chaotic situation of treating symptoms rather than the root cause.

[0027] After cluster analysis based on the implementation scheme of this invention: First: After receiving fault data from multiple fault points, standardize the format of all fault data.

[0028] Secondly, clustering analysis revealed that these hundreds of fault points actually clustered into three main fault-affected areas: Area A (Chengdong Industrial Zone): Mainly caused by the collapse of 35 power poles and the breakage of 2 10kV lines, involving power distribution operation and maintenance departments and large user management departments.

[0029] Area B (City Center Business District): Mainly caused by trees pressing on power lines and two ring main unit malfunctions, involving power distribution operation and maintenance departments and municipal landscaping departments.

[0030] Area C (Northern Residential Area): Mainly caused by the tripping of the outlet switch of a substation, involving the substation operation and maintenance department and the power distribution operation department.

[0031] Next steps: The dispatch center can establish three cross-departmental emergency repair teams for the three clear targets of regions A, B, and C, allocate different resources and formulate different strategies to achieve the transformation from chaos to order.

[0032] The system has a built-in departmental responsibility knowledge base. For each fault-affected area generated by the aforementioned steps, it performs spatial matching, equipment matching, and type matching to identify all involved collaborating entities (such as the power distribution operation and maintenance department and the municipal landscaping bureau).

[0033] Each collaborative entity is configured with a data interface. A lightweight data collection agent is deployed on the data interface. The agent periodically sends probe messages to the target interface to actively measure network latency and packet loss rate, and listens to and records the historical success rate of business requests. For each data interface, a communication health index (HI) is calculated based on network latency, packet loss rate, and historical success rate of business requests. This enables a quantitative perception of the interface data communication quality, provides objective data for subsequent intelligent routing decisions, and solves the problem of unknown interface status.

[0034] The system maintains a dynamic routing table that records the mapping relationship between data services, interfaces, and HI values. When resource information is needed, the routing decision engine queries this table and selects the interface with the highest HI value as the target data interface for this request. Following the predefined RESTful API specification, the request is encapsulated into an HTTP message and sent to the target data interface. The interface returns standardized JSON data, which includes the status information of the requested repair resources. This achieves stable and reliable acquisition of critical data, effectively avoiding faulty or congested channels by selecting the optimal interface, thus improving the success rate and timeliness of data requests.

[0035] The power distribution network fault handling method described in this invention determines the communication health index based on network latency, packet loss rate, and historical request success rate. Based on the communication health index, it dynamically selects cross-departmental collaborative data exchange links, avoids unstable data interfaces with high latency and high packet loss, and always attempts to obtain data through the best available channel. This fundamentally improves the success rate and efficiency of a single request and significantly enhances the reliability and stability of cross-departmental collaborative data acquisition.

[0036] Based on the above embodiments, referring to Figure 2 As shown, cluster analysis of the fault dataset to obtain one or more fault-affected areas includes: for each fault point, extracting geospatial features, power grid topology features, and fault type features from the fault data to obtain three-modal features; calculating the similarity between any two fault points based on the three-modal features; performing cluster analysis on the fault dataset based on the similarity to generate one or more fault point clusters; and outputting a fault-affected area for each fault point cluster.

[0037] In specific application scenarios, for each fault point, three modal features are extracted, including geospatial features, power grid topology features, and fault type features. Geospatial features are directly obtained by parsing the latitude and longitude fields from the fault reporting data, acquiring geographical coordinates representing the fault point's location, for example: [121.4737, 31.2304]. The geographical coordinates of the fault point are then correlated with the distribution network geographic information system and the power grid topology model. Based on the coordinates, the nearest power grid equipment (such as poles or switching stations) is located, and the logical location information and topology identifier of this equipment in the power grid are obtained, forming the power grid topology features. For example, fault points A and B may be geographically close, but if A belongs to the "10kV Binhe Line" and B belongs to the "10kV Industrial Line," their topology features will be different. The fault types described in the text are standardized and vectorized; for example, a fault type dictionary is constructed, mapping short circuits to the number 1 and grounding to 2; a numerical value or vector representing the physical properties of the fault is output.

[0038] The clustering algorithm's distance metric function is based on a weighted distance of three modal features. The topological distance determined by the power grid topology features has the highest weight, ensuring that fault points on the same feeder are preferentially clustered into one class. By fusing power grid topology information, it overcomes the problems of erroneous merging (geographically close but electrically unrelated) and erroneous splitting (electrically related but geographically dispersed) that may be caused by clustering based solely on geographical distance, providing accurate and reliable delineation of the affected area for subsequent coordinated handling.

[0039] Specifically, calculating the similarity between any two fault points based on the three-modal features includes: calculating the Euclidean distance between any two fault points based on the geospatial features; calculating the topological distance between any two fault points based on the power grid topology features; calculating the type distance between any two fault points based on the fault type features; and performing a weighted summation of the Euclidean distance, topological distance, and type distance to obtain the similarity; wherein the topological distance has the largest weight.

[0040] In specific application scenarios, similarity calculation based on three-modal features includes: calculating the Euclidean distance between the latitude and longitude of two fault points and performing normalization to obtain the geographical distance; if the two fault points belong to the same feeder, the topological distance is 0; if they belong to different feeders, the topological distance is a large constant, such as 100; this reflects that electrical correlation is a stronger clustering constraint than geographical proximity; if the two fault points are of the same type, the distance is 0; if they are of different types, the distance is 1. Configure the comprehensive distance function. D represents the composite distance, and D1, D2, and D3 represent the normalized Euclidean distance, topological distance, and categorical distance, respectively. , , These represent the weights of their respective distances. Typical values ​​for distance weights are... , , It is suitable for all four types of scenarios.

[0041] For example: Scenario 1: Two fault points are on the same feeder, but geographically far apart; D2=0, D1=0.8 (relatively far), D3=1 (different type); D=0.7×0+0.2×0.8+0.1×1=0+0.16+ 0.1=0.26; Conclusion: Despite the geographical distance and different types, the overall distance D is still very small, and the algorithm tends to cluster them into one category, which is as expected: as long as they are electrically connected, they should be preferentially classified into one area.

[0042] Scenario 2: The two fault points are geographically very close, but belong to different feeders; D2=100, D1=0.1 (very close), D3=0 (same type); D=0.7×100+0.2×0.1+0.1×0=70+0.02+0=70.02; Conclusion: Despite being geographically close and of the same type, the huge topological distance makes the overall distance D very large. The algorithm will resolutely divide them into different clusters, effectively preventing erroneous merging.

[0043] Scenario 3: Two fault points are on the same feeder, geographically close, but of different types; D2 = 0, D1 = 0.2, D3 = 1; D=0.7×0+0.2×0.2+0.1×1=0+0.04+0.1=0.14; Conclusion: The overall distance is very small, and they will cluster into one category. The small difference (0.1) between different types does not affect the overall situation.

[0044] Scenario 4: Two fault points are on the same feeder, geographically close, and of the same type (ideal case). D2=0, D1=0.2, D3=0; D=0.7×0+0.2×0.2+0.1×0=0+0.04+0=0.04; Conclusion: If the overall distance is extremely small, they will inevitably be clustered into one category.

[0045] The three sub-distances are combined into a single comprehensive distance, or similarity, by using a weighted summation. The topological distance is given the highest weight, while the fault type is given the lowest weight. This means that priority is given to whether the fault points belong to the same circuit (same feeder) electrically, followed by geographical proximity, and finally, whether the fault types are consistent. By assigning the highest weight to the topological distance, the clustering algorithm is ensured to force fault points on the same feeder to be classified into the same category. This fundamentally prevents the incorrect merging of electrically unrelated fault points and also prevents the incorrect segmentation of multiple power outage points caused by the same fault.

[0046] By replacing the original distance calculation module of the algorithm with the aforementioned custom weighted comprehensive distance function, the algorithm scans all fault points and determines the similarity between points based on the comprehensive distance. Since topological distance dominates the comprehensive distance, dense fault points on the same feeder are identified as a core cluster. The output is that all fault points are divided into different clusters. Points within each cluster are highly similar in electrical, geographical, and fault type aspects, while points between different clusters differ significantly in these characteristics. This achieves automated and rational grouping of fault points; the output is no longer scattered points but several clear fault point clusters. Each cluster typically corresponds to a continuous power supply island or an independent fault event, providing dispatchers with a clear view of the fault impact range.

[0047] For each generated cluster of fault points, its geographical convex hull or minimum bounding rectangle is calculated to form the geographical boundary of the cluster. This geographical boundary is then bound to the cluster's intrinsic characteristics (such as the dominant feeder ID and dominant fault type) to form a complete fault-affected area object, which is then output to the downstream process. For example, Area Alpha = {Geographical boundary: [coordinate set], Main feeder: "10kV Binhe Line", Main fault type: "Short circuit"}. This generates collaborative handling units with clear electrical significance and geographical scope. Downstream steps for determining collaborative entities and resource allocation can be based on this clear area object. For example, the system can know that the problem in "Area Alpha" is in the "10kV Binhe Line," requiring notification of the maintenance team responsible for this line and preparation of corresponding equipment and materials based on the "short circuit" fault type. This transforms the system from a massive, chaotic alarm to a limited, clear, and executable task, a key step in improving emergency repair efficiency.

[0048] The core technical effect of the entire clustering process is that by introducing the topological features of the power grid and assigning them the highest weight, the regional division results strictly follow the physical connection relationship of the power grid, thereby ensuring that the divided fault-affected areas are not only statistically of the same type, but also an electrical logical whole that needs to be uniformly processed. This overcomes the drawback of traditional methods that are divorced from the actual structure of the power grid.

[0049] Based on the above embodiments, before calculating the similarity between any two fault points, a power grid topology feature correction is also included. The power grid topology feature correction includes: determining whether the power grid topology feature of the fault point P is missing; if it is missing, searching for K fault points that are geographically adjacent to the fault point P in the fault point set; counting the number of fault points belonging to the same feeder among the K fault points; if the number of fault points exceeds a threshold, then correcting the power grid topology feature of the fault point P according to the feeder information.

[0050] In specific application scenarios, when processing each fault point P, the system checks the value of the power grid topology feature field in its data structure. If the field is empty, unknown, or contains an illegal value (such as a feeder ID of "N / A"), this situation may be due to terminal communication interruption, data parsing error, or the fault point coming from a system that is not linked to the main network topology map (such as a simple user telephone repair report). By identifying gaps in the data stream, instead of blindly sending data with missing features downstream, clustering errors caused by this can be avoided.

[0051] Once it is confirmed that the topological features of fault point P are missing, a K-Nearest Neighbors (KNN) search is performed on all currently received fault point sets. Here, proximity is calculated solely based on Euclidean distance from geospatial features to find the K fault points geographically closest to fault point P (e.g., K=5). Inference is made based on the domain knowledge that geographically proximate fault points have a higher probability of belonging to the same power grid feeder. By finding spatial neighbors, the correlation of fault points in spatial distribution is used to compensate for the missing topological information. The power grid topological features of these K neighboring points are checked one by one, and the number of fault points belonging to the same specific feeder F is counted. A statistical threshold θ is set (e.g., θ=3 when K=5). If the number of neighboring points belonging to feeder F, K>θ, then the feeder information in the power grid topological feature field of fault point P is updated or completed with the inferred identifier of feeder F.

[0052] In this embodiment of the invention, by correcting the characteristics of the power grid topology, the fault tolerance of the clustering algorithm to data incompleteness is greatly enhanced, improving the accuracy and completeness of the fault impact area division and avoiding distortion of the entire clustering result due to the lack of features of a single data point. For example, it prevents the area where a key fault point is located from being incorrectly divided into two small areas due to the lack of information on a key fault point; it enables more effective fault points to be included in the correct clusters for analysis, ensuring that the divided fault impact area can more comprehensively reflect the true fault range.

[0053] Based on the above embodiments, referring to Figure 3 As shown, determining the multiple cooperating entities involved in each of the fault-affected areas includes: performing spatial overlay analysis on the geographical boundaries of the fault-affected areas and the electronic fences of the geographical jurisdiction to obtain a first set of candidate cooperating entities; querying the device-entity mapping table based on the affected devices in the fault-affected areas to obtain a second set of candidate cooperating entities; querying the fault type-entity mapping table based on the fault type of the fault-affected areas to obtain a third set of candidate cooperating entities; and determining the union of the first set of candidate cooperating entities, the second set of candidate cooperating entities, and the third set of candidate cooperating entities as the multiple cooperating entities involved.

[0054] In specific application scenarios, when generating the fault-affected area, a polygonal geographical boundary is obtained. The digital jurisdictional boundaries of all relevant departments are pre-stored; for example, the jurisdiction of "Shinan Power Supply Branch" is a precise polygonal electronic fence, while the greening maintenance area under the responsibility of "XX District Municipal and Landscape Bureau" is another polygon. Spatial overlay analysis is performed using the spatial analysis engine of the geographic information system, specifically intersection analysis. This determines which department's (or other departments') electronic fence polygons intersect with the polygon of the fault-affected area. All departments whose jurisdictions intersect with the fault-affected area are included in the first candidate collaborative entity set. For example, if the fault-affected area covers parts of Street A and Street B, and Street A belongs to "Distribution Operation and Maintenance Team 1" while Street B belongs to "Distribution Operation and Maintenance Team 2," then both are included in the first candidate collaborative entity set. This ensures that all departments whose geographical jurisdictions involve the fault-affected area are considered without omission, resolving the problem of missing responsible departments due to human unfamiliarity with administrative divisions, and providing the most basic list of responsible parties for collaborative work.

[0055] From the analysis of the affected area, key identifiers of the affected power grid equipment are identified, such as feeder IDs, ring main unit numbers, and transformer substation numbers. An equipment-entity mapping table is maintained to record the correspondence between power grid assets and their respective operation and maintenance (O&M) responsible entities; for example, Equipment ID: 10kV Binhe Line - Responsible Entity: Distribution Operation and Maintenance Team 3. Based on the identified equipment identifiers, the equipment-entity mapping table is queried in batches to find the legal O&M responsible entities for these devices. All found responsible entities are included in the second candidate collaborative entity set.

[0056] The dominant fault type is determined from the fault analysis. Another mapping table is maintained to define the collaborating departments required to handle specific fault types. For example, fault type: tree crushed - responsible entity: municipal landscaping bureau; fault type: cable cut - responsible entity: road construction party / urban construction department. Based on the fault type, the mapping table is queried to find all professional departments that need to collaborate. All matching departments are included in the third candidate collaborating entity set.

[0057] The three candidate sets mentioned above—the first candidate collaborative entity set (geographical jurisdiction), the second candidate collaborative entity set (equipment ownership), and the third candidate collaborative entity set (professional cooperation)—are combined using a mathematical operation to remove duplicate entities, forming a unique and complete list of collaborative entities. This list is then used to identify the final number of collaborative entities involved in the area affected by the fault.

[0058] In actual implementation, there are conflicts of command and ambiguity of leadership among multiple collaborating entities. For example, if a feeder fault occurs across administrative regions, the equipment belongs to the "municipal company's directly affiliated team," but the fault point is located within the jurisdiction of the "district power supply branch company." The system will simultaneously issue emergency repair instructions to two departments at the same level. Both sides may believe that the other should take the lead, or both may actively intervene but with different strategies. This results in the on-site repair personnel receiving conflicting instructions ("the directly affiliated team requires operation of switch A first, while the district power supply branch company requires handling line B first"), causing chaos on-site and delaying the golden time for emergency repair.

[0059] To address the above issues, the present invention, in its embodiments, further includes detecting whether subject conflicts exist before determining the plurality of cooperating subjects. This detection includes: for the affected device, if a first subject is mapped based on the device-subject mapping table, and a second subject is matched based on the spatial overlay analysis results of the geographic jurisdiction electronic fence, and the first and second subjects are different, then conflict one is detected; for the fault type, if a third subject is mapped based on the fault type-subject mapping table, and a fourth subject is mapped based on the device-subject mapping table, and the third and fourth subjects are different, then conflict two is detected.

[0060] In a specific application scenario, the first conflict is between equipment ownership and geographical jurisdiction. Two preliminary determinations have been obtained for a certain affected equipment (such as a feeder named "10kV Coastal Line"): First subject: Query results from the equipment-subject mapping table; for example, the table clearly stipulates that the operation and maintenance responsibility subject of the "10kV Haibin Line" is "Distribution Operation and Maintenance Department Directly Subordinate Shift 3"; The second subject: Spatial overlay analysis, comparing the geographical area where the fault point of the "10kV Haibin Line" is located with the electronic fence, found that the area falls within the jurisdiction of the "Chengdong Branch of the Distribution Operation and Maintenance Department".

[0061] Perform string matching or ID comparison: If the first entity is found to be different from the second entity, i.e., "Distribution Operation and Maintenance Department Directly Subordinate Shift 3" != "Distribution Operation and Maintenance Department Chengdong Branch", then a conflict event is immediately triggered, and the detailed conflict information (equipment ID, entity A, entity B) is recorded. In the traditional model, such conflicts require manual discovery and coordination, which is prone to delays. By automatically detecting and alarming, hidden management conflicts are made explicit, providing a clear target for subsequent automatic resolution or priority manual intervention, and avoiding potential disputes over responsibility between departments after instructions are issued.

[0062] Conflict 2 involves a conflict between professional responsibilities and equipment ownership, and two determinations have been obtained regarding the type of fault: The third entity: derived from the fault type-entity mapping table; for example, for the fault type "trees crossing the line", the table specifies that the "Municipal Parks and Gardens Bureau" needs to cooperate in handling it; The fourth entity: from the equipment-entity mapping table; that is, the responsible entity for the line itself that has experienced the "tree pressing the line" fault, for example, still "the third shift directly under the power distribution operation and maintenance department".

[0063] Similarly, if "Municipal Gardening Bureau" !="Power Distribution Operation and Maintenance Department Directly Subordinate Shift 3", then a "Conflict 2" event is triggered. It should be noted that the "conflict" here does not mean that the two are mutually exclusive, but rather that there may be a difference of understanding or unclear command authority regarding who bears the primary responsibility for handling the fault.

[0064] It also includes: if conflict one or conflict two is detected, conflict resolution is performed; the conflict resolution includes using the entity mapped by the device-entity mapping table as the executing entity. The core of this conflict resolution rule is the principle of device ownership priority: in the step of detecting whether there is a conflict between entities, the system has identified and marked the specific conflict event (conflict one or conflict two) and recorded the specific entity information involved in the conflict (such as the first entity, the second entity). Once a conflict is detected, the system will not wait for manual intervention, but will automatically trigger and execute the predefined resolution rule; regardless of how the conflict arises, the entity mapped by the device-entity mapping table is designated as the sole executing entity; for conflict one (device ownership vs. geographical jurisdiction): the first entity (device owner) is selected as the executing entity, the second entity is ignored, and the geographical jurisdiction is usually downgraded to a cooperating entity, responsible for providing localization support. For conflict two (device ownership vs. professional responsibility): the fourth entity (device owner) is selected as the executing entity, and the professional responsibility party (the third entity, such as the municipal landscaping bureau) is clearly identified as a cooperating entity, accepting the coordination instructions of the device owner. The system automatically updates the collaborative solutions generated for the affected area with the resolution results. The solutions clearly specify the implementing entity (lead department) and cooperating entities. At the same time, the system generates a resolution log, recording the content of the conflict, the rules applied, and the final decision.

[0065] Based on conflict resolution, the potentially time-consuming manual coordination process is transformed into an automated decision-making process that is completed instantly. The system can immediately output a clear instruction without waiting for the dispatcher to call for confirmation, which greatly shortens the response time from the occurrence of a fault to the issuance of a coordination instruction, thus saving valuable time for emergency repairs.

[0066] Based on the above embodiments, refer to Figure 4As shown, establishing a data exchange link based on the communication health index includes: maintaining a dynamic routing table, which stores the mapping relationship between data service identifiers, alternative data interface addresses, and communication health indices; querying the dynamic routing table using the data service identifier of the data request as an index to obtain all alternative data interfaces providing the data service and the communication health index corresponding to each alternative data interface; sorting the communication health indices of all alternative data interfaces in descending order and obtaining the alternative data interface with the highest communication health index as the target data interface; and forwarding the data request to the target data interface to obtain the corresponding emergency repair resource status information through the target data interface.

[0067] In a specific application scenario, a routing table is created in the in-memory database. Its core fields include: data service identifier, alternative data interface address, communication health index, and last update time. The communication health index is updated periodically by the health calculation module. When each collaborating department accesses the system, it registers its provided data services and corresponding API addresses in this table. A separate background task periodically retrieves the latest HI values ​​for all interfaces from the health calculation module and refreshes the communication health index field in the table.

[0068] When an upper-layer application needs to retrieve data, it sends a request to the routing decision engine. This request explicitly carries a data service identifier. Upon receiving the request, the routing decision engine uses this data service identifier as the key to perform an SQL query or a NoSQL key-value query in the dynamic routing table. For example: SELECT* FROM routing_table WHERE service_id = 'getCraneAvailability'; The query results return a list of all alternative interfaces that can provide the "Crane Availability Query" service and their current HI values. Upper-layer applications do not need to care about which entity or data interface to call; they only need to declare what service is required, and the system will automatically discover all available service providers, achieving high flexibility and scalability.

[0069] The routing decision engine sorts the candidate interface list obtained in the previous step in descending order according to the communication health index field in memory, selects the interface address ranked first, and determines it as the target data interface for this data request; ensuring that every data request is automatically guided to the healthiest and most stable communication channel, maximizing the success rate and speed of a request, and fundamentally avoiding poor link.

[0070] The routing decision engine encapsulates the original data request into a standard format that the target interface can recognize, forwards it to the selected target data interface over the network, waits for the response from the target interface, performs necessary parsing and verification on the response data, and then returns the emergency repair resource status information to the original upper-layer application.

[0071] Specifically, the status parameters include network latency, packet loss rate, and historical request success rate; the communication health index for each data interface is calculated based on the status parameters, including: mapping a latency score value based on the network latency; mapping a packet loss score value based on the packet loss rate; mapping a success rate score value based on the historical request success rate; and fusing the latency score value, packet loss score value, and success rate score value to obtain the communication health index.

[0072] In specific application scenarios, latency scores are mapped based on predefined scoring rules and preset segmented scoring functions. The configuration of these segmented scoring functions reflects business requirements, meaning the tolerance for latency is non-linear. For example: latency ≤ 50ms: score 100; 50ms < latency ≤ 200ms: score linearly decreases from 100 to 80; 200ms < latency ≤ 500ms: score linearly decreases from 80 to 60; latency > 500ms: score 0. When the real-time raw network latency value (e.g., 120ms) is obtained, it is mapped to a corresponding latency score value according to the above rules, either by looking up a table or by calculation (e.g., 120ms falls within the 50-200ms range, and the score is calculated as 90 through linear interpolation). Packet loss has a fatal impact on communication reliability. This step effectively identifies and quantifies the stability of the interface. The scoring rules ensure the system remains sensitive to even small packet loss rates, meeting the requirements of high-reliability services.

[0073] Packet loss scores are based on predefined scoring rules: another set of piecewise scoring functions are preset, for example: Packet loss rate = 0%: score is 100; 0% < packet loss rate ≤ 1%: score linearly decreases from 100 to 95; 1% < packet loss rate ≤ 5%: score linearly decreases from 95 to 70; packet loss rate > 5%: score is 0. The real-time collected raw packet loss rate value (e.g., 0.5%) is mapped to a packet loss score value according to the rules (e.g., 0.5% falls in the 0-1% range, and the score is calculated as 97.5).

[0074] Success rate scores are based on linear or quasi-linear mappings. For example: success rate ≥ 99.9%: score 100; success rate < 99.9%: score = success rate × 100 (e.g., a success rate of 98.5% maps to 98.5 points); or a minimum threshold can be set, such as a score of 0 for success rates below 95%. The success rate score (e.g., 99.2%) is directly calculated or mapped from the raw success rate value (e.g., 99.2%) within a statistical period (e.g., the most recent 100 requests). This quantifies the final availability of the data interface from the perspective of historical behavior. A high success rate score means that the interface not only has good link quality (low latency, low packet loss) but also high service availability.

[0075] A weighted average algorithm is used for fusion, with the formula: Communication Health Index = Wd × Latency Score + Wl × Packet Loss Score + Ws × Success Rate Score; where Wd, Wl, and Ws are the weight coefficients of each indicator, and Wd + Wl + Ws = 1. Substituting the three scores obtained in the first three steps into the formula, a final Communication Health Index between 0 and 100 is calculated. The weights are related to service priority. Typically, the success rate weight Ws is the highest (e.g., 0.5) because it most directly reflects availability; the packet loss rate weight Wl is second (e.g., 0.3) because it affects stability; and the latency weight Wd is relatively the lowest (e.g., 0.2) because latency has a relatively small impact on data query services within a certain range. The calculated Communication Health Index HI is no longer three isolated indicators, but a comprehensive score integrating latency, packet loss, and success rate. This score allows the routing decision engine to easily and efficiently determine which data interface has the best overall quality by comparing a single HI value, thus making the most reasonable route selection.

[0076] Example 2: Refer to Figure 5 As shown in the figure, an embodiment of the present invention provides a power distribution network fault handling system, comprising: The power distribution network fault handling system includes: The data receiving module is used to receive fault data from multiple fault points and obtain a fault dataset. The clustering analysis module is used to perform clustering analysis on the fault dataset to obtain one or more fault-affected regions; The collaborative entity determination module is used to determine multiple collaborative entities involved in each of the fault-affected areas, and a data interface is configured for each of the collaborative entities. The communication health index calculation module is used to obtain the status parameters of all the data interfaces and calculate the communication health index of each data interface based on the status parameters. The data exchange module is used to establish a data exchange link based on the communication health index and to obtain the corresponding emergency repair resource status information through the data exchange link. The fault handling module is used to handle the fault-affected area based on the emergency repair resource status information.

[0077] The embodiments of the present invention are based on the same inventive concept as Embodiment 1 and have the same technical effects, which will not be repeated here.

[0078] In summary, the power distribution network fault handling method and system described in this invention determines the communication health index based on network latency, packet loss rate, and historical request success rate. Based on the communication health index, it dynamically selects cross-departmental collaborative data exchange links, avoids unstable data interfaces with high latency and high packet loss, and always attempts to obtain data through the best available channel. This fundamentally improves the success rate and efficiency of a single request and effectively enhances the reliability and stability of cross-departmental collaborative data acquisition.

[0079] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for fault handling in an electrical distribution network, characterized in that include: Receive fault data from multiple fault points to obtain a fault dataset; Cluster analysis of the fault dataset is used to obtain one or more fault-affected regions. Identify multiple collaborating entities involved in each of the aforementioned fault-affected areas, and configure a data interface for each of the aforementioned collaborating entities; Obtain the status parameters of all the data interfaces, and calculate the communication health index of each data interface based on the status parameters; wherein, the status parameters include network latency, packet loss rate, and historical request success rate; A data exchange link is established based on the communication health index, and the corresponding emergency repair resource status information is obtained through the data exchange link. Based on the status information of the emergency repair resources, fault handling is performed on the affected area.

2. The power distribution network fault handling method of claim 1, wherein, Cluster analysis of the fault dataset yields one or more fault-affected regions, including: For each fault point, geospatial features, power grid topology features, and fault type features are extracted from the fault data to obtain three-modal features; The similarity between any two fault points is calculated based on the three modal features, and cluster analysis is performed on the fault dataset based on the similarity to generate one or more fault point clusters. For each cluster of fault points, output a fault-affected area.

3. The power distribution network fault handling method of claim 2, wherein, The calculation of the similarity between any two fault points includes a power grid topology feature correction, which includes: Determine whether the power grid topology features at the fault point P are missing; If there is a missing point, then search for K fault points that are geographically adjacent to the fault point P in the fault point set. The number of fault points belonging to the same feeder among the K fault points is counted. If the number of fault points exceeds a threshold, the power grid topology characteristics of the fault point P are corrected based on the feeder information.

4. The power distribution network fault handling method of claim 2 or 3, wherein, Calculating the similarity between any two fault points based on the three-modal features includes: Based on the geospatial features, calculate the Euclidean distance between any two fault points; Based on the power grid topology characteristics, calculate the topological distance between any two fault points; Based on the fault type characteristics, calculate the type distance between any two fault points; The similarity is obtained by weighted summation of the Euclidean distance, topological distance, and type distance; among which, the topological distance has the largest weight.

5. The power distribution network fault handling method of claim 1, wherein, Identify the multiple coordinating entities involved in each of the aforementioned fault-affected areas, including: Spatial overlay analysis of the geographical boundary of the area affected by the fault and the electronic fence of the geographical jurisdiction is performed to obtain the first candidate set of cooperative subjects; Based on the affected devices within the fault-affected area, query the device-subject mapping table to obtain the second set of candidate collaborative subjects; Based on the fault type in the affected area, query the fault type-subject mapping table to obtain the third candidate collaborative subject set; The union of the first set of candidate collaborative entities, the second set of candidate collaborative entities, and the third set of candidate collaborative entities is determined as the multiple collaborative entities involved.

6. The power distribution network fault handling method of claim 5, wherein, Before determining the plurality of cooperating entities, the method further includes detecting whether there is an entity conflict; the detection of whether there is an entity conflict includes: For the affected device, if a first subject is mapped based on the device-subject mapping table, and a second subject is matched based on the spatial overlay analysis results of the geographic jurisdiction electronic fence, and the first subject and the second subject are different, then a conflict is detected. For the aforementioned fault type, if a third entity is mapped based on the fault type-entity mapping table, and a fourth entity is mapped based on the device-entity mapping table, and the third entity and the fourth entity are different, then a second conflict is detected.

7. The power distribution network fault handling method of claim 6, wherein, Also includes: If conflict one or conflict two is detected, conflict resolution is performed; the conflict resolution includes using the subject mapped by the device-subject mapping table as the execution subject.

8. The power distribution network fault handling method of claim 1, wherein, Establishing a data exchange link based on the aforementioned communication health index includes: Maintain a dynamic routing table, which stores the mapping relationship between data service identifiers, alternative data interface addresses, and communication health indices; The dynamic routing table is queried using the data service identifier of the data request as an index to obtain all alternative data interfaces that provide the data service and the communication health index corresponding to each alternative data interface; The communication health index of all the candidate data interfaces is sorted in descending order, and the candidate data interface with the highest communication health index is selected as the target data interface. The data request is forwarded to the target data interface to obtain the corresponding emergency repair resource status information through the target data interface.

9. The power distribution network fault handling method of claim 1, wherein, The communication health index of each data interface is calculated based on the status parameters, including: A latency score is mapped based on the network latency; a packet loss score is mapped based on the packet loss rate; and a success rate score is mapped based on the historical request success rate. The communication health index is obtained by combining the latency score, packet loss score, and success rate score.

10. A power distribution network fault handling system, characterized by, include: The data receiving module is used to receive fault data from multiple fault points and obtain a fault dataset. The clustering analysis module is used to perform clustering analysis on the fault dataset to obtain one or more fault-affected regions; The collaborative entity determination module is used to determine multiple collaborative entities involved in each of the fault-affected areas, and a data interface is configured for each of the collaborative entities. The communication health index calculation module is used to obtain the status parameters of all the data interfaces and calculate the communication health index of each data interface based on the status parameters. The data exchange module is used to establish a data exchange link based on the communication health index and to obtain the corresponding emergency repair resource status information through the data exchange link. The fault handling module is used to handle the fault-affected area based on the emergency repair resource status information.

Images