Electric power knowledge graph multi-tenant cluster management system based on cloud native

Abstract

The invention is applicable to the technical field of tenant management, and provides a cloud-native-based power knowledge graph multi-tenant cluster management system, which comprises a multi-tenant cluster, a cloud native platform and a central dispatching center, and is characterized in that the multi-tenant cluster manages power grid data of tenants and allocates computing resources through a data access unit and a tenant management unit; the cloud native platform generates an electric power knowledge graph through a knowledge modeling unit and a data extraction unit; and the central dispatching center determines a fault propagation path and key equipment through the knowledge fusion unit, the reasoning calculation unit and the service interface unit, generates a fault diagnosis result, feeds back the fault diagnosis result to the tenant management unit, and triggers a tenant alarm or operation and maintenance instruction. According to the invention, through cooperative work of the multi-tenant cluster, the cloud native platform and the central dispatching center, the precision and efficiency of substation equipment fault diagnosis are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of tenant management technology, and in particular to a cloud-native multi-tenant cluster management system based on power knowledge graph. Background Technology

[0002] In the field of power system operation and maintenance, substation fault diagnosis is a crucial link in ensuring the safe and stable operation of the power grid. Current substation fault diagnosis mainly relies on real-time data analysis from data acquisition and monitoring control systems, rule-based reasoning from expert systems, and traditional knowledge graphs. This involves real-time acquisition of electrical quantity data such as voltage and current from equipment, using threshold comparison and trend analysis to identify abnormal states. Expert systems depend on fault rule bases built by domain experts, using logical reasoning to determine the type and location of faults. Traditional knowledge graph technology pre-builds entity relationship models of power equipment and combines them with historical fault data to achieve fault correlation analysis.

[0003] With the digital transformation of power systems, different tenants have increasingly higher demands for real-time fault diagnosis, data isolation, and personalization. Traditional architectures, lacking elastic computing resource allocation mechanisms, struggle to respond quickly to concurrent access from multiple tenants, resulting in insufficient real-time fault diagnosis. Furthermore, existing knowledge graph construction processes rely on manually defined entity relationships and manual data annotation. Given the diverse types of power grid equipment and the unstructured nature of fault text, this leads to incomplete equipment entity identification and inaccurate fault relationship extraction, resulting in incomplete fault propagation path analysis and affecting the accuracy of diagnostic results.

[0004] In view of this, a cloud-native multi-tenant cluster management system based on power knowledge graph is proposed. Summary of the Invention

[0005] This invention provides a cloud-native power knowledge graph multi-tenant cluster management system to solve the problems of insufficient real-time performance and inaccurate diagnostic results in substation fault diagnosis.

[0006] This invention provides a cloud-native, multi-tenant cluster management system based on a power knowledge graph, comprising:

[0007] The multi-tenant cluster includes a data access unit and a tenant management unit. The data access unit is connected to the tenant management unit and is used to receive and classify the power grid data uploaded by tenants. The tenant management unit is used to allocate independent computing resources to each tenant and restrict the access rights of the target tenant to the data of other tenants through a preset tenant isolation policy.

[0008] The cloud-native platform includes a knowledge modeling unit and a data extraction unit. The knowledge modeling unit is connected to both the data access unit and the data extraction unit, and the data extraction unit is connected to the data access unit. The knowledge modeling unit is used to define the entity types, relationship types, and attribute constraints of power equipment through an ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit. The data extraction unit is used to extract equipment attribute information from the structured data received from the data access unit, identify the relationship between equipment entities and faults from unstructured text, and fill the extraction results into the initial power knowledge graph framework to generate a target power knowledge graph.

[0009] The central dispatch center includes a knowledge fusion unit, an inference and computation unit, and a service interface unit. The knowledge fusion unit is connected to the data extraction unit, the inference and computation unit is connected to both the knowledge fusion unit and the service interface unit, and the service interface unit is connected to the tenant management unit. Based on the target power knowledge graph fused by the knowledge fusion unit, the inference and computation unit determines the fault propagation path and key equipment, and generates fault diagnosis results. The service interface unit then feeds back the fault diagnosis results to the tenant management unit, triggering tenant alarms or maintenance instructions.

[0010] Furthermore, the tenant management unit is used to allocate independent computing resources to each tenant, including:

[0011] The resource demand identifier in the power grid data uploaded by the tenant is parsed. The resource demand identifier includes a high-priority demand identifier, a computationally intensive task identifier, and a real-time processing demand identifier. If any of the three identifiers is present, computing resources corresponding to a special resource pool are allocated to the current tenant. Specifically, a dedicated resource node cluster is allocated to the current tenant, and the current tenant's tasks are prioritized for scheduling to idle computing nodes.

[0012] If the resource demand identifier does not contain a high-priority demand marker, a computationally intensive task marker, or a real-time processing demand marker, then computing resources corresponding to the shared resource pool will be allocated to the current tenant; specifically, computing resources will be allocated to the current tenant in a balanced manner using a round-robin algorithm.

[0013] Furthermore, the round-robin algorithm for evenly allocating computing resources to the current tenant includes:

[0014] Add the current tenant's task to the shared resource pool queue and allocate it to idle computing nodes in the order of task submission;

[0015] If the shared resource pool load exceeds the preset load, the processing of non-real-time tasks for the current tenant will be delayed until the resources are released and rescheduled.

[0016] Furthermore, the cloud-native platform also includes a containerized orchestration unit, which is connected to the tenant management unit and the knowledge modeling unit respectively. The containerized orchestration unit is used to parse the computing resource types allocated by the tenant management unit and generate container group configurations that match the tenant tasks.

[0017] When a tenant's task is assigned to a dedicated resource node cluster, the containerized orchestration unit creates a container instance containing a GPU driver and a parallel computing framework based on a preset hardware acceleration template, and splits the ontology visualization editor service of the knowledge modeling unit into microservice modules according to device type and deploys them to the dedicated container instance.

[0018] When a tenant's task is assigned to the shared resource pool, the containerized orchestration unit calls an elastic scaling strategy to monitor the computational load of the knowledge modeling unit. If it detects that the amount of unstructured text parsing tasks exceeds the container group's processing threshold, it automatically expands the distributed text processing container instance and adds the new instance to the load balancer for task distribution. Based on the data scale of the initial power knowledge graph framework generated by the knowledge modeling unit, it dynamically adjusts the memory allocation ratio of the graph database container and the mounting strategy of the persistent storage volume.

[0019] Furthermore, the knowledge modeling unit is used to define the entity types, relation types, and attribute constraints of power equipment through an ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit, including:

[0020] The entity types of power equipment and the hierarchical relationships of each entity type are defined in the ontology visualization editor through a drag-and-drop interface. The connection rules and attribute constraints between entities are set to generate an initial power knowledge graph framework containing ontology patterns.

[0021] The initial power knowledge graph framework is converted into RDF triples and pushed to the data extraction unit through the API interface of the cloud-native platform.

[0022] Furthermore, the step of extracting device attribute information from structured data received from the data access unit and identifying the relationship between device entities and faults from unstructured text includes:

[0023] Based on the entity attribute fields defined in the initial power knowledge graph framework, the column names and attribute constraints of the structured data table are matched, and the equipment model, rated power and installation location fields are extracted through regular expressions to generate standardized equipment attribute key-value pairs.

[0024] A pre-trained BERT model for the power industry is used to perform named entity recognition on equipment logs and inspection reports, extracting equipment number and fault code entities; based on dependency parsing tree analysis, fault causal relationships between equipment entities are extracted, and triples of <faulty equipment, fault type, affected equipment> are constructed.

[0025] The device attribute key-value pairs extracted from structured data are aligned with the fault relationship triples extracted from unstructured text to filter out abnormal association data where the device type and fault type do not match.

[0026] Furthermore, the step of filling the extracted results into the initial power knowledge graph framework to generate the target power knowledge graph includes:

[0027] The standardized device attribute key values ​​are converted into triplet format and then inserted into the initial power knowledge graph framework;

[0028] Link the fault relationship triples to the device instances in the knowledge graph, and add relationship edges to the device entities that have fault causal relationships, provided that the connection rules are satisfied.

[0029] Detect conflicts between newly added data and entity attributes in the existing graph, use a tenant-defined priority strategy to cover or merge conflicting attributes, generate a knowledge graph version snapshot and record data traceability information.

[0030] Furthermore, determining the fault propagation path and key equipment includes:

[0031] Based on the global power knowledge graph generated by the knowledge fusion unit, scan all device entities marked as abnormal states;

[0032] Along the electrical connections between equipment entities, the improved Diikstra algorithm is used to calculate the shortest path for fault propagation, where the edge weights are dynamically adjusted by the equipment type and connection distance.

[0033] The detected loop propagation path is automatically truncated and marked as a self-excitation fault;

[0034] Generate a device connection chain with directional arrows, and label the propagation probability and impact range.

[0035] Furthermore, determining the fault propagation path and key equipment also includes:

[0036] The topological centrality score of the device in the graph is calculated, and a comprehensive score is calculated by combining the predefined device functional weights and historical failure frequency.

[0037] If the score meets the first threshold range, it is marked as a critical device and a red alarm is triggered. If the score meets the second threshold range, it is marked as an important device and a yellow warning is triggered.

[0038] Furthermore, the fault diagnosis results include a structured JSON object containing the fault propagation path, a list of key equipment, and handling suggestions.

[0039] As can be seen from the above technical solutions, the present invention has the following advantages:

[0040] This invention features a multi-tenant cluster, a cloud-native platform, and a central dispatch center. Through a data access unit and a tenant management unit, it ensures real-time response to high-priority fault tasks in multi-tenant concurrent scenarios. Based on a knowledge modeling unit and a data extraction unit, it addresses the omissions in identification and the biases in relation extraction caused by manual annotation. A knowledge fusion unit, combined with a reasoning and computation unit, locates fault propagation paths and identifies key equipment. Finally, a service interface unit outputs structured diagnostic results, significantly shortening fault location time and improving the accuracy of substation equipment fault diagnosis. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the structure of a cloud-native power knowledge graph-based multi-tenant cluster management system in this invention.

[0042] Figure 2 This is a schematic diagram of an embodiment of the invention for generating an initial power knowledge graph framework;

[0043] Figure 3 This is a schematic diagram of an embodiment of the present invention for generating a target power knowledge graph;

[0044] Figure 4 This is a schematic diagram of an embodiment of the present invention for generating fault diagnosis results. Detailed Implementation

[0045] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding to,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0046] Example 1

[0047] See also Figure 1The cloud-native power knowledge graph multi-tenant cluster management system of this invention includes a multi-tenant cluster 1, a cloud-native platform 2, and a central dispatch center 3. The multi-tenant cluster 1 includes a data access unit 101 and a tenant management unit 102. The data access unit 101 is connected to the tenant management unit 102 and is used to receive and classify the power grid data uploaded by the tenants. The tenant management unit 102 is used to allocate independent computing resources to each tenant and restrict the access rights of the target tenant to the data of other tenants through a preset tenant isolation policy.

[0048] The cloud-native platform 2 includes a knowledge modeling unit 201 and a data extraction unit 202. The knowledge modeling unit 201 is connected to the data access unit 101 and the data extraction unit 202, respectively. The data extraction unit 202 is connected to the data access unit 101. The knowledge modeling unit 201 is used to define the entity type, relationship type and attribute constraints of power equipment through an ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit 202. The data extraction unit 202 is used to extract equipment attribute information from the structured data received from the data access unit 101, identify the relationship between equipment entities and faults from unstructured text, and fill the extraction results into the initial power knowledge graph framework to generate a target power knowledge graph.

[0049] The central dispatch center 3 includes a knowledge fusion unit 301, an inference and calculation unit 302, and a service interface unit 303. The knowledge fusion unit 301 is connected to the data extraction unit 202. The inference and calculation unit 302 is connected to both the knowledge fusion unit 301 and the service interface unit 303. The service interface unit 303 is connected to the tenant management unit 102. Based on the target power knowledge graph fused by the knowledge fusion unit 301, the inference and calculation unit 302 determines the fault propagation path and key equipment, and generates fault diagnosis results. This enables the service interface unit 303 to feed back the fault diagnosis results to the tenant management unit 102, triggering tenant alarms or maintenance instructions.

[0050] Specifically, the data flow and control flow implementation principles of the cloud-native power knowledge graph multi-tenant cluster management system are as follows:

[0051] First, the data access unit 101 receives structured, semi-structured, and unstructured power grid data uploaded by tenants and completes data preprocessing through classification and storage. Second, the knowledge modeling unit 201 defines the entity types, relationships, and constraints of power equipment through an ontology visualization editor, generates an initial knowledge graph framework, and transmits it to the data extraction unit 202. The data extraction unit 202 extracts equipment attributes from the structured data, uses an NLP model to identify the relationship between equipment entities and faults from unstructured text, and fills the framework with the results to generate the target power knowledge graph. The target graph knowledge fusion unit 301 performs multi-source entity alignment and conflict resolution to form a global graph. The reasoning and calculation unit 302 uses the graph to locate fault propagation paths using the shortest path algorithm and the PageRank algorithm to identify key equipment, generating fault diagnosis results. Finally, the service interface unit 303 feeds back the results to the tenant management unit 102, triggering alarms or maintenance instructions.

[0052] Among them, the tenant management unit 102 dynamically allocates computing resources based on preset strategies and restricts cross-tenant data access to ensure multi-tenant isolation; the cloud-native platform 2 dynamically schedules knowledge modeling and data extraction resources through containerization technology and elastically scales up and down Pod instances according to task load; the central scheduling center 3 coordinates the time logic of knowledge fusion, reasoning and service interfaces to ensure graph construction, reasoning and result feedback.

[0053] Furthermore, the tenant management unit is used to allocate independent computing resources to each tenant, including the following steps:

[0054] 1. Parse the resource demand identifiers in the power grid data uploaded by the tenant. The resource demand identifiers include high-priority demand markers, computationally intensive task markers, and real-time processing demand markers. If any of the following identifiers are present in the resource demand identifiers, then the current tenant is allocated computing resources corresponding to a special resource pool. Specifically, a dedicated resource node cluster is allocated to the current tenant, and the current tenant's tasks are prioritized for scheduling to idle computing nodes.

[0055] Specifically, the tenant management unit uses its built-in metadata parsing engine to examine the header of the power grid data files uploaded by tenants, identifying whether any of the three requirement tags exist: high priority, computationally intensive, or real-time processing. If any tag is detected, the system determines that the tenant's task requires special computing resource guarantees. At this point, the tenant management unit sends a request to the underlying container orchestration platform, requesting that the tenant's task be scheduled onto a pre-configured dedicated physical node cluster. This dedicated cluster has more powerful hardware resources. The platform ensures that the task runs only on these dedicated nodes by setting strict node affinity rules and pre-reserves a portion of core resources exclusively for the tenant. If resources are scarce, the platform will also allow the tenant's high-priority task to interrupt other low-priority tenants' tasks to ensure their tasks are processed promptly, thereby achieving resource isolation and priority guarantee.

[0056] 2. If there are no high-priority demand markers, computationally intensive task markers, or real-time processing demand markers for resource demand identifiers, then computing resources corresponding to the shared resource pool will be allocated to the current tenant; specifically, computing resources will be allocated to the current tenant in a balanced manner using a round-robin algorithm.

[0057] Specifically, when no high-priority, computationally intensive, or real-time processing requirements are detected in the data uploaded by a tenant, their task will be assigned to a shared resource pool for processing. The tenant management unit places these tasks into a shared distributed task queue. Resource allocation uses an improved round-robin algorithm, which first considers the tenant's service level agreement (SLA) and assigns different base weight values ​​to tenants of different SLA levels. When allocating computing resources, the system dynamically calculates the resource quota that each tenant should receive based on the proportion of each tenant's weight value to the total weight value of all active tenants.

[0058] The method of allocating computing resources to the current tenant in a balanced manner using a round-robin algorithm includes the following:

[0059] 1. Add the current tenant's task to the shared resource pool queue and allocate it to idle computing nodes in the order of task submission;

[0060] 2. If the shared resource pool load exceeds the preset load, delay the processing of non-real-time tasks for the current tenant until the resources are released and rescheduled.

[0061] Specifically, tasks are categorized by characteristics and placed into different queues, such as latency-sensitive real-time tasks and latency-insensitive batch processing tasks. The priority of tasks in the queues is dynamically calculated according to preset rules. Real-time tasks are primarily prioritized based on their deadline urgency, with more urgent tasks having higher priority. Batch processing tasks are prioritized by considering factors such as data volume, processing complexity, and the service level of their respective tenants. The system continuously monitors the load of compute nodes. If a node's load exceeds a set safety threshold, the system will pause scheduling new batch processing tasks, temporarily placing newly arriving real-time tasks into a special backlog queue, and automatically triggering horizontal scaling of container instances to increase processing capacity. Once the node load returns to a safe level and stabilizes for a period, the system will prioritize processing the backlog of real-time tasks and perform rate limiting and backfilling on the backlog of batch processing tasks, adding a portion of them back into the processing queue according to their original order to avoid excessive instantaneous pressure.

[0062] Furthermore, the cloud-native platform also includes a containerized orchestration unit, which connects to the tenant management unit and the knowledge modeling unit respectively. The containerized orchestration unit is used to parse the types of computing resources allocated by the tenant management unit and generate container group configurations that match the tenant's tasks.

[0063] When a tenant's task is assigned to a dedicated resource node cluster, the containerized orchestration unit creates a container instance containing GPU drivers and a parallel computing framework based on a preset hardware acceleration template, and splits the ontology visualization editor service of the knowledge modeling unit into microservice modules according to device type and deploys them to the dedicated container instance.

[0064] When tenant tasks are assigned to the shared resource pool, the containerized orchestration unit calls the elastic scaling strategy to monitor the computing load of the knowledge modeling unit. If it detects that the amount of unstructured text parsing tasks exceeds the container group's processing threshold, it automatically expands the distributed text processing container instance and adds the new instance to the load balancer for task distribution. Based on the data scale of the initial power knowledge graph framework generated by the knowledge modeling unit, it dynamically adjusts the memory allocation ratio of the graph database container and the mounting strategy of the persistent storage volume.

[0065] Specifically, based on the type of computing resources allocated by the tenant management unit, a suitable containerized runtime environment is dynamically generated. For tenant tasks allocated to a dedicated resource node cluster, the unit calls a preset hardware acceleration template to automatically create a dedicated container instance equipped with GPU drivers and a parallel computing framework. At the same time, the ontology visualization editor service of the knowledge modeling unit is intelligently decomposed into microservice modules divided by device type, such as transformer modeling module and circuit breaker modeling module, and these microservices are precisely deployed to dedicated container instances to achieve a strong binding between computing resources and modeling tasks.

[0066] For tasks assigned to the shared resource pool, the computational load of the knowledge modeling unit is tracked in real time. When the amount of unstructured text parsing tasks exceeds the processing capacity threshold of the container group, horizontal scaling is automatically triggered—increasing the number of distributed text processing container instances and seamlessly connecting the new instances to the load balancer to achieve task distribution. At the same time, based on the data scale characteristics of the initial power knowledge graph framework generated by the knowledge modeling unit, the memory allocation ratio of the graph database container and the mounting strategy of the persistent storage volume are dynamically adjusted. Through real-time optimization of container resources, the efficiency and stability of knowledge modeling in a multi-tenant environment are ensured.

[0067] Example 2

[0068] See also Figure 2 The knowledge modeling unit is used to define the entity types, relation types, and attribute constraints of power equipment through the ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit, including the following steps:

[0069] S21. Define the power equipment entity types and the hierarchical relationships of each entity type in the ontology visualization editor through a drag-and-drop interface, set the connection rules and attribute constraints between entities, and generate an initial power knowledge graph framework containing ontology patterns.

[0070] Users define power equipment entities and their hierarchical relationships through a drag-and-drop interactive interface in the ontology visual editor, and bind semantic rules between entities using connection lines, such as "only 'connection' relationships are allowed between transformers and circuit breakers," and attribute constraints, such as "rated voltage attributes must be floating-point types." The system converts the graphical modeling operations into the OWL ontology language in real time, generating a structured ontology schema that includes entity classification systems, relationship constraints, and data type definitions, forming the metadata skeleton of the initial power knowledge graph framework.

[0071] S22. Convert the initial power knowledge graph framework into RDF triples and push them to the data extraction unit through the API interface of the cloud-native platform.

[0072] The system invokes the RDF transformation engine. RDF is a knowledge representation standard framework defined by the W3C. Its core uses triples to describe the relationships between resources, mapping entity types, relations, and attribute constraints in the ontology schema into triples in the form of <subject, predicate, object>, such as <circuit breaker, rdf: type, switchgear>, <circuit breaker, rated voltage, xsd: float>. The generated RDF triple dataset is pushed to the data extraction unit through the cloud-native platform's message bus, triggering the subsequent data extraction process.

[0073] Example 3

[0074] See also Figure 3 The data extraction unit is used to extract equipment attribute information from the structured data received by the data access unit, identify the relationship between equipment entities and faults from unstructured text, and fill the extraction results into the initial power knowledge graph framework to generate the target power knowledge graph. This includes the following steps:

[0075] S31. Based on the entity attribute fields defined in the initial power knowledge graph framework, match the column names and attribute constraints of the structured data table, extract the equipment model, rated power and installation location fields through regular expressions, and generate standardized equipment attribute key-value pairs;

[0076] S32. A pre-trained BERT model for the power industry is used to perform named entity recognition on equipment logs and inspection reports, extracting equipment number and fault code entities; based on dependency parsing tree analysis, fault causal relationships between equipment entities are extracted, and triples of <faulty equipment, fault type, affected equipment> are constructed.

[0077] S33. Align the key-value pairs of device attributes extracted from structured data with the triplets of fault relationships extracted from unstructured text to filter out abnormal association data where the device type and fault type do not match.

[0078] S34. After converting the standardized device attribute key values ​​into triplet format, insert them into the initial power knowledge graph framework;

[0079] S35. Link the fault relationship triples to the device instances in the knowledge graph, and add relationship edges to the device entities that have fault causal relationships, provided that the connection rule constraints are met.

[0080] S36. Detect conflicts between newly added data and existing graph entity attributes, use tenant-defined priority strategies to cover or merge conflicting attributes, generate a knowledge graph version snapshot and record data traceability information.

[0081] Specifically, for structured data, based on predefined attribute constraints within the knowledge graph framework, key attributes such as equipment model are accurately extracted through field mapping and regular expressions to generate standardized key-value pairs. For unstructured text, a BERT model for the power sector is used to identify equipment entities and fault codes, and fault causal relationship triples are constructed based on dependency parsing. Structured attributes and unstructured fault relationships are aligned using equipment numbers and spatiotemporal labels, filtering out anomalous data with conflicting types. Equipment attributes are converted into RDF triples and inserted into graph entity slots, while fault triples are linked to graph equipment instances, adding weighted fault relationship edges while satisfying ontology constraints. By comparing new data with existing graphs, conflicting attributes are covered / merged according to tenant priority strategies, generating versioned snapshots and recording data traceability, forming a target power knowledge graph that integrates multi-source data and possesses complete equipment status and fault logic.

[0082] Example 4

[0083] See also Figure 4 The reasoning and computation unit, based on the target power knowledge graph fused by the knowledge fusion unit, determines the fault propagation path and key equipment, and generates fault diagnosis results, including the following steps:

[0084] S41. Based on the global power knowledge graph generated by the knowledge fusion unit, scan all device entities marked as abnormal states;

[0085] S42. Calculate the shortest path for fault propagation using the improved Diikstra algorithm along the electrical connections between equipment entities, where the edge weights are dynamically adjusted by the equipment type and connection distance;

[0086] S43. Automatically cut off the loop propagation path detected and mark it as a self-excitation fault;

[0087] S44. Generate a device connection chain with directional arrows, and label the propagation probability and the scope of influence.

[0088] Specifically, the inference and computation unit first scans all abnormal state device entities in the global power knowledge graph. Based on the electrical connection topology between devices, it dynamically calculates the shortest path for fault propagation using an improved Dijkstra algorithm—the edge weights in the algorithm are adjusted in real time according to the device type and physical connection distance, such as the weight coefficient of transformers being greater than that of circuit breakers. When a fault signal is detected to form a closed loop along the device connection, the system automatically breaks the loop and marks it as a self-excited fault, ultimately generating a visual fault chain with directional arrows, labeled propagation probability, and impact range.

[0089] Furthermore, identifying key equipment includes:

[0090] 1. Calculate the topological centrality score of the device in the graph, and combine it with the predefined device functional weights and historical failure frequency to calculate the comprehensive score;

[0091] 2. If the score meets the first threshold range, it is marked as a critical device and a red alarm is triggered. If the score meets the second threshold range, it is marked as an important device and a yellow warning is triggered.

[0092] The system calculates the centrality score of a device within the network graph, measuring its hub status. Predefined device function weights and historical fault frequency coefficients are then overlaid, such as a main transformer weight of 0.8. Devices with a comprehensive score exceeding the red threshold (≥90 points) are marked as critical devices and trigger real-time alarms; devices exceeding the yellow threshold (70–89 points) are marked as important devices and trigger early warnings, forming a diagnostic result. This diagnostic result includes a structured JSON object containing the fault propagation path, a list of critical devices, and suggested remediation measures.

[0093] It is understood that those skilled in the art can combine various implementation methods in the above embodiments under the guidance of the above examples to obtain technical solutions with multiple implementation methods.

[0094] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud-native, multi-tenant cluster management system based on power knowledge graphs, characterized in that, include: A multi-tenant cluster includes a data access unit and a tenant management unit. The data access unit is connected to the tenant management unit and is used to receive power grid data uploaded by tenants and store it in a categorized manner. The tenant management unit is used to allocate independent computing resources to each tenant and restrict the target tenant's access to other tenants' data through a preset tenant isolation policy; The cloud-native platform includes a knowledge modeling unit and a data extraction unit. The knowledge modeling unit is connected to both the data access unit and the data extraction unit, and the data extraction unit is connected to the data access unit. The knowledge modeling unit is used to define the entity types, relationship types, and attribute constraints of power equipment through an ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit. The data extraction unit is used to extract equipment attribute information from the structured data received from the data access unit, identify the relationship between equipment entities and faults from unstructured text, and fill the extraction results into the initial power knowledge graph framework to generate a target power knowledge graph. The central dispatch center includes a knowledge fusion unit, an inference and computing unit, and a service interface unit. The knowledge fusion unit is connected to the data extraction unit, the inference and computing unit is connected to both the knowledge fusion unit and the service interface unit, and the service interface unit is connected to the tenant management unit. The reasoning and computing unit determines the fault propagation path and key equipment based on the target power knowledge graph fused by the knowledge fusion unit, and generates fault diagnosis results. This enables the service interface unit to feed back the fault diagnosis results to the tenant management unit, triggering tenant alarms or operation and maintenance instructions.

2. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 1, characterized in that, The tenant management unit is used to allocate independent computing resources to each tenant, including: The resource demand identifier in the power grid data uploaded by the tenant is parsed. The resource demand identifier includes a high-priority demand identifier, a computationally intensive task identifier, and a real-time processing demand identifier. If any of the three identifiers is present, computing resources corresponding to a special resource pool are allocated to the current tenant. Specifically, a dedicated resource node cluster is allocated to the current tenant, and the current tenant's tasks are prioritized for scheduling to idle computing nodes. If the resource demand identifier does not contain a high-priority demand marker, a computationally intensive task marker, or a real-time processing demand marker, then computing resources corresponding to the shared resource pool will be allocated to the current tenant; specifically, computing resources will be allocated to the current tenant in a balanced manner using a round-robin algorithm.

3. The cloud-native power knowledge graph-based multi-tenant cluster management system according to claim 2, characterized in that, The round-robin algorithm evenly allocates computing resources to the current tenant, including: Add the current tenant's task to the shared resource pool queue and allocate it to idle computing nodes in the order of task submission; If the shared resource pool load exceeds the preset load, the processing of non-real-time tasks for the current tenant will be delayed until the resources are released and rescheduled.

4. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 2, characterized in that, The cloud-native platform also includes a containerized orchestration unit, which is connected to the tenant management unit and the knowledge modeling unit respectively. The containerized orchestration unit is used to parse the computing resource types allocated by the tenant management unit and generate container group configurations that match the tenant tasks. When a tenant's task is assigned to a dedicated resource node cluster, the containerized orchestration unit creates a container instance containing a GPU driver and a parallel computing framework based on a preset hardware acceleration template, and splits the ontology visualization editor service of the knowledge modeling unit into microservice modules according to device type and deploys them to the dedicated container instance. When a tenant's task is assigned to the shared resource pool, the containerized orchestration unit calls an elastic scaling strategy to monitor the computational load of the knowledge modeling unit. If it detects that the amount of unstructured text parsing tasks exceeds the container group's processing threshold, it automatically expands the distributed text processing container instance and adds the new instance to the load balancer for task distribution. Based on the data scale of the initial power knowledge graph framework generated by the knowledge modeling unit, it dynamically adjusts the memory allocation ratio of the graph database container and the mounting strategy of the persistent storage volume.

5. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 1, characterized in that, The knowledge modeling unit is used to define the entity types, relation types, and attribute constraints of power equipment through an ontology visualization editor, generate an initial power knowledge graph framework, and transmit the initial power knowledge graph framework to the data extraction unit, including: The entity types of power equipment and the hierarchical relationships of each entity type are defined in the ontology visualization editor through a drag-and-drop interface. The connection rules and attribute constraints between entities are set to generate an initial power knowledge graph framework containing ontology patterns. The initial power knowledge graph framework is converted into RDF triples and pushed to the data extraction unit through the API interface of the cloud-native platform.

6. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 5, characterized in that, The step of extracting device attribute information from structured data received from the data access unit and identifying the relationship between device entities and faults from unstructured text includes: Based on the entity attribute fields defined in the initial power knowledge graph framework, the column names and attribute constraints of the structured data table are matched, and the equipment model, rated power and installation location fields are extracted through regular expressions to generate standardized equipment attribute key-value pairs. A pre-trained BERT model for the power industry is used to perform named entity recognition on equipment logs and inspection reports, extracting equipment number and fault code entities; based on dependency parsing tree analysis, fault causal relationships between equipment entities are extracted, and triples of <faulty equipment, fault type, affected equipment> are constructed. The device attribute key-value pairs extracted from structured data are aligned with the fault relationship triples extracted from unstructured text to filter out abnormal association data where the device type and fault type do not match.

7. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 6, characterized in that, The step of filling the extracted results into the initial power knowledge graph framework to generate the target power knowledge graph includes: The standardized device attribute key values ​​are converted into triplet format and then inserted into the initial power knowledge graph framework; Link the fault relationship triples to the device instances in the knowledge graph, and add relationship edges to the device entities that have fault causal relationships, provided that the connection rules are satisfied. Detect conflicts between newly added data and entity attributes in the existing graph, use a tenant-defined priority strategy to cover or merge conflicting attributes, generate a knowledge graph version snapshot and record data traceability information.

8. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 1, characterized in that, The determination of fault propagation paths and key equipment includes: Based on the global power knowledge graph generated by the knowledge fusion unit, scan all device entities marked as abnormal states; Along the electrical connections between equipment entities, the improved Diikstra algorithm is used to calculate the shortest path for fault propagation, where the edge weights are dynamically adjusted by the equipment type and connection distance. The detected loop propagation path is automatically truncated and marked as a self-excitation fault; Generate a device connection chain with directional arrows, and label the propagation probability and impact range.

9. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 8, characterized in that, The determination of fault propagation paths and key equipment also includes: The topological centrality score of the device in the graph is calculated, and a comprehensive score is calculated by combining the predefined device functional weights and historical failure frequency. If the score meets the first threshold range, it is marked as a critical device and a red alarm is triggered. If the score meets the second threshold range, it is marked as an important device and a yellow warning is triggered.

10. The cloud-native power knowledge graph multi-tenant cluster management system according to claim 9, characterized in that, The fault diagnosis results include a structured JSON object containing the fault propagation path, a list of key equipment, and handling suggestions.

Images