A method and apparatus for recommending scheduling plans using multiple knowledge graphs.

Abstract

This invention relates to the field of computer technology, specifically to a method and apparatus for recommending dispatch plans using a multi-knowledge graph approach. The method includes: establishing a matching rule base for alarm event types and alarm signal types; importing information from a third-party system into a relational database, performing information extraction, knowledge fusion, and knowledge processing, and storing the information in a graph database; receiving alarm events and alarm signals; and calling knowledge graph services to build intelligent alarm plan push, historical maintenance event association push, and historical dispatch log association push, etc. Through this approach, while meeting the real-time requirements of power grid dispatch operations, it can provide dispatchers with auxiliary decision-making support when handling power grid faults, enrich dispatchers' recovery decision-making methods, push optimal fault handling solutions, provide services externally in the form of APIs, improve the efficiency of power grid fault handling, and enhance the robustness of the entire power grid business system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a method and apparatus for recommending scheduling plans that combine multiple knowledge graphs. Background Technology

[0002] With the continuous development of my country's power industry, the scale of power grid construction is also expanding. Power grid safety is crucial to stable economic development and the stable supply of electricity for people's daily lives. Currently, problems such as complex power grid operation modes, increased equipment load, and insufficient power supply capacity are becoming increasingly prominent. The pressure on power grid safety operation is growing daily, and power grid failures are becoming more frequent, leading to serious consequences for power grid operation safety.

[0003] Among these, contingency plans for power grid faults need to be rapidly assessed and provided for dispatch emergency response when alarms occur. However, due to the frequent and complex changes in these contingency plans, dispatching and operation personnel face difficulties in their operations. Therefore, how to apply knowledge graph technology to online decision-making support for power grid fault contingency plans has become a pressing technical problem that needs to be solved to ensure the safe and stable operation of the power grid. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for recommending scheduling plans that combine multiple knowledge graphs.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] According to a first aspect of the present invention, a scheduling plan recommendation method combining multiple knowledge graphs is provided, applied to a knowledge graph management platform. The scheduling plan recommendation method includes the following steps:

[0007] Based on the knowledge graph management platform, a matching rule base for alarm event types and alarm signal types is established. The knowledge graph management platform includes an alarm knowledge base based on expert experience, a power grid model knowledge graph, and a fault contingency plan knowledge graph.

[0008] Information is imported from a third-party system into a relational database, and information is extracted, knowledge is integrated, knowledge is processed, and then stored in a graph database.

[0009] Upon receiving alarm events and alarm signals, based on the matching rule base and the alarm knowledge base of expert experience, the system uses the association analysis of the power grid model knowledge graph and the fault contingency plan knowledge graph to call the knowledge graph service to determine whether there is a signal missing and to build and recommend dispatch contingency plans.

[0010] As a further aspect of the present invention, importing information from a third-party system into a relational database includes:

[0011] The system connects to the OMS (Operation Management System), imports fault plans, historical maintenance records, historical operation ticket information, dispatch log information, and dispatcher processing information, and stores them in a relational database; and

[0012] Connect to the OCS system and import information including alarm signals, power grid models, operating data, and dispatcher operations.

[0013] As a further aspect of the present invention, the knowledge graph management platform in the scheduling plan recommendation method is also used to extract fault plans, historical operation ticket information, and scheduling log information from the relational database, perform information extraction, knowledge fusion, and knowledge processing to form a searchable fault plan knowledge base, and store it in the graph database.

[0014] As a further aspect of the present invention, receiving alarm events and alarm signals includes: acquiring fault-type and abnormal-type alarm events according to a configurable time frequency using an interface for interacting with an intelligent alarm system; and acquiring alarm signals according to a configurable time frequency using an interface for interacting with an OCS system.

[0015] As a further aspect of the present invention, when calling the knowledge graph service to determine whether there is a missing signal, if there is a missing signal, the alarm event is marked; if there is no missing signal, it is determined whether it is a fault alarm; if it is a fault alarm, a fault contingency plan is recommended; otherwise, an exception handling strategy is recommended.

[0016] As a further aspect of the present invention, when calling the knowledge graph service to determine whether there is a signal deficiency, the method further includes:

[0017] By using the plant, bay, equipment information and occurrence time information associated with alarm events and alarm signals, the alarm signals related to the alarm events are analyzed and obtained.

[0018] The fault contingency plan knowledge graph provides services that, based on given alarm events and alarm signals, use a pre-established matching rule base to determine whether a given alarm event has missing alarm signals.

[0019] As a further aspect of the present invention, when determining whether it is a fault alarm, if not, an anomaly handling strategy is recommended. The recommended anomaly handling strategy further includes: based on the type of abnormal event, the type of equipment, and the current status of power grid operation, using knowledge reasoning to extract corresponding handling strategy information from the abnormal event handling strategy knowledge base.

[0020] As a further aspect of the present invention, based on the type of abnormal event, the type of equipment, and the current status of power grid operation, knowledge reasoning is used to extract corresponding handling strategy information from the abnormal event handling strategy knowledge base, including: based on information such as faulty equipment and fault type, obtaining fault-related fault plan information, historical maintenance information, historical operation ticket information, and dispatch log information from the fault plan knowledge base.

[0021] As a further aspect of the present invention, the knowledge graph management platform is also used to provide periodic services, automatically generating scheduling logs using abnormal alarm event information and scheduler processing operation information.

[0022] As a further aspect of the present invention, information is imported from a third-party system into a relational database, and information extraction, knowledge fusion, knowledge processing, and storage in a graph database are performed, including:

[0023] The knowledge graph management platform extracts alarm events, dispatcher processing operations, automatic control program operations, and power grid operation modes from the relational database, performs information extraction, knowledge fusion, and knowledge processing on them, and forms a searchable knowledge base of power grid abnormal event handling strategies, which is then stored in the graph database.

[0024] As a further aspect of the present invention, a fault contingency plan is recommended, which also includes determining whether a fault contingency plan exists. If so, the fault contingency plan is displayed; if not, a fault contingency plan editing interface is provided.

[0025] As a further aspect of the present invention, an anomaly handling strategy is recommended, which also includes determining whether there is a fault handling strategy. If there is, a fault contingency plan is displayed; otherwise, a handling strategy editing interface is provided.

[0026] According to a second aspect of the present invention, a scheduling plan recommendation device combining multiple knowledge graphs is provided, comprising:

[0027] The multi-knowledge graph construction module is used to establish a matching rule library between alarm event types and alarm signal types based on the knowledge graph management platform;

[0028] The scheduling plan module is used to import information from third-party systems into the relational database, and to extract, integrate, and process information before storing it in the graph database.

[0029] The alarm access module is used to receive alarm events and alarm signals;

[0030] The contingency plan recommendation module is used to call the knowledge graph service to determine whether there is a missing signal. If there is a missing signal, the alarm event is marked; if there is no missing signal, it is determined whether it is a fault alarm; if it is a fault alarm, a fault contingency plan is recommended; otherwise, an exception handling strategy is recommended.

[0031] According to a third aspect of the present invention, a computer device is provided, including a processor and a storage device, the storage device being configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the multi-knowledge graph combined scheduling plan recommendation method as described in the first aspect of the above embodiments.

[0032] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the multi-knowledge graph combined scheduling plan recommendation method as described in the first aspect of the above embodiments.

[0033] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0034] Through the above technical solutions, the present invention provides a multi-knowledge graph-based dispatch plan recommendation method and apparatus. This method establishes a matching rule base for alarm event types and alarm signal types; imports information from third-party systems into a relational database, performs information extraction, knowledge fusion, and knowledge processing, and stores the information in a graph database; receives alarm events and alarm signals; and invokes knowledge graph services to build intelligent alarm plan push, historical maintenance event association push, and historical dispatch log association push. This approach, while meeting the real-time requirements of power grid dispatch operations, provides dispatchers with auxiliary decision-making support when handling power grid faults, enriches dispatchers' recovery decision-making methods, and can push optimal fault handling solutions. It provides services externally in the form of APIs (Application Programming Interfaces), improving the efficiency of power grid fault handling and the robustness of the entire power grid business system.

[0035] These or other aspects of this application will become more apparent from the following description of embodiments. It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the application. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. In the drawings:

[0037] Figure 1 This is a flowchart illustrating a scheduling plan recommendation method combining multiple knowledge graphs in an exemplary embodiment of the present invention.

[0038] Figure 2 This is a flowchart of the scheduling plan processing in a multi-knowledge graph combined scheduling plan recommendation method in an exemplary embodiment of the present invention;

[0039] Figure 3This is a schematic diagram of the interface prototype in a scheduling plan recommendation method combining multiple knowledge graphs in an exemplary embodiment of the present invention;

[0040] Figure 4 This is a schematic diagram of the fault plan interface in the scheduling plan recommendation method combining multiple knowledge graphs in an exemplary embodiment of the present invention.

[0041] Figure 5 This is a schematic diagram of the operation ticket interface in the scheduling plan recommendation method combining multiple knowledge graphs in an exemplary embodiment of the present invention;

[0042] Figure 6 A nine-zone graph constructed for voltage limit exceedance in the multi-knowledge graph combined scheduling plan recommendation method in an exemplary embodiment of the present invention;

[0043] Figure 7 This is a schematic diagram of the interface prototype for editing accident plans in the scheduling plan recommendation method that combines multiple knowledge graphs in an exemplary embodiment of the present invention.

[0044] Figure 8 This is a schematic diagram of the structure of a computer device that is an exemplary embodiment of the present invention.

[0045] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] The present application will now be further described in conjunction with the accompanying drawings and specific embodiments. It should be noted that, without conflict, the various embodiments or technical features described below can be arbitrarily combined to form new embodiments.

[0047] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0048] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0050] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0051] Frequent and complex changes in fault handling plans pose challenges to dispatching personnel. To address these issues, embodiments of this application provide a method and apparatus for recommending dispatching plans using a multi-knowledge graph approach. By applying knowledge graph technology, combining its association analysis capabilities with fault plan knowledge graphs, it enables intelligent push notifications of alarm plans, historical maintenance events, and historical dispatch logs, thereby achieving online decision support.

[0052] In some implementations, the scheduling plan recommendation method combining multiple knowledge graphs can be applied to computer devices, such as PCs, laptops, mobile terminals, or other devices with display and processing capabilities, but is not limited to these.

[0053] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the scheduling plan recommendation method combining multiple knowledge graphs according to this application. In the embodiments of this application, the scheduling plan recommendation method combining multiple knowledge graphs can utilize the scheduling plan recommendation process combining multiple knowledge graphs executed by a knowledge graph management platform. The method includes the following steps S10-S30:

[0054] Step S10: Based on the knowledge graph management platform, establish a matching rule base for alarm event types and alarm signal types. The knowledge graph management platform includes an alarm knowledge base based on expert experience, a power grid model knowledge graph, and a fault contingency plan knowledge graph.

[0055] Step S20: Import information from the third-party system into the relational database, and perform information extraction, knowledge fusion, knowledge processing and store it in the graph database;

[0056] Step S30: Receive alarm events and alarm signals. Based on the matching rule base and the alarm knowledge base of expert experience, through the correlation analysis of the power grid model knowledge graph and the fault contingency plan knowledge graph, call the knowledge graph service to determine whether there is a signal missing and build a dispatch contingency plan recommendation.

[0057] The following will describe in more detail each step of the scheduling plan recommendation method combining multiple knowledge graphs in this exemplary embodiment, with reference to the accompanying drawings and embodiments.

[0058] Among them, see Figure 2As shown, in an embodiment of the present invention, in step S20, importing information from a third-party system into a relational database includes: accessing the OMS system, importing information including fault plans, historical maintenance records, historical operation ticket information, dispatch log information, and dispatcher processing operations, and storing them in the relational database; and accessing the OCS system, importing information including alarm signals, power grid models, operating data, and dispatcher operations.

[0059] See Figure 2 As shown, when calling the knowledge graph service to determine whether there is a missing signal, if there is a missing signal, the alarm event is marked; if there is no missing signal, it is determined whether it is a fault alarm; if it is a fault alarm, a fault contingency plan is recommended; otherwise, an exception handling strategy is recommended.

[0060] See Figure 2 As shown, in an embodiment of the present invention, the recommended fault contingency plan also includes determining whether there is a fault contingency plan; if there is, the fault contingency plan is displayed; if not, a fault contingency plan editing interface is provided.

[0061] See Figure 2 As shown, in the embodiments of the present invention, the recommended exception handling strategy also includes determining whether there is a fault handling strategy. If there is, a fault contingency plan is displayed; otherwise, a handling strategy editing interface is provided.

[0062] In this embodiment, receiving alarm events and alarm signals includes: acquiring fault-type and abnormal-type alarm events according to a configurable time frequency using an interface for interacting with the intelligent alarm system; and acquiring alarm signals according to a configurable time frequency using an interface for interacting with the OCS system.

[0063] In the multi-knowledge graph combined scheduling plan recommendation method of the present invention, a knowledge graph management platform is used to establish a matching rule library for alarm event types and alarm signal types, realize the interface for interaction between this system and the OCS system and the intelligent alarm system, and obtain alarm signals and alarm events respectively according to the configurable time beat.

[0064] In some embodiments, the scheduling plan recommendation method combining multiple knowledge graphs further includes:

[0065] By using the plant, bay, equipment information and occurrence time information associated with alarm events and alarm signals, the alarm signals related to the alarm events are analyzed and obtained.

[0066] The fault contingency plan knowledge graph provides services that, based on given alarm events and alarm signals, use a pre-established matching rule base to determine whether a given alarm event has missing alarm signals.

[0067] In some embodiments, the fault contingency plan knowledge graph service further includes: extracting corresponding handling strategy information from the abnormal event handling strategy knowledge base based on the abnormal event type, equipment type and power grid operation status using knowledge reasoning.

[0068] In some embodiments, the multi-knowledge graph combined scheduling plan recommendation method further includes providing an interface to refresh real-time alarm information in a table format. Each alarm event, in addition to containing all the information provided by the intelligent alarm system, also includes a "Signal Missing" column and a "Plan" column. If an alarm event has a missing signal, the "Signal Missing" column will display a "Details" button to view the missing alarm signal for that alarm event; for fault-related alarm events, the "Plan" button allows viewing fault-related plan information; for general alarm information, the "Plan" button allows viewing abnormal plan information.

[0069] The interface supports categorizing and retrieving alarm events based on criteria such as alarm event type, plant / station, equipment type, and whether a signal is missing. An example interface prototype is shown below. Figure 3 As shown.

[0070] See Figure 3 As shown, the alarm event filter form is located at the top of the interface, used to filter alarm information of interest as needed. The "Alarm Events" table below the filter form displays alarm events that meet the filter criteria. If an alarm event has missing signals, a "Details" button will appear in the "Signal Missing" column. Clicking this button will display which alarm signals are missing in a pop-up window. If a fault alarm event has a recommended fault response plan, or an abnormal alarm event has a recommended handling strategy, a "Details" button will appear in the "Plan / Strategy" column. Clicking this button will display the recommended fault handling plan or handling strategy in a pop-up dialog box.

[0071] See Figure 3 As shown, the "Associated Alarm Signals" section under the alarm event displays the alarm signals associated with the currently selected power outage event, and the content updates automatically with the selected alarm event. The "Alarm Signals to be Sent" section at the bottom of the page displays the alarm signal types that should be sent for the event type belonging to the currently selected alarm event. The data comes from a pre-established matching rule library of alarm event types and alarm signal types on the knowledge graph management platform. Checked signal types indicate that they have already been sent, while unchecked types represent missing signal types.

[0072] In the multi-knowledge graph combined scheduling plan recommendation method of the present invention, a knowledge graph management platform is used to establish a matching rule library for alarm event types and alarm signal types, realize the interface between the system and the OMS system, import fault plans, historical maintenance records, historical operation ticket information, scheduling log information, and dispatcher processing operations from the OMS system, and store them in the relational database.

[0073] In this embodiment, the knowledge graph management platform is used to extract fault plans, historical operation ticket information, and scheduling log information from the relational database, and after information extraction, knowledge fusion, and knowledge processing, form a searchable fault plan knowledge base, which is then stored in the graph database.

[0074] In some embodiments, the knowledge graph management platform includes an alarm knowledge base based on expert experience, a power grid model knowledge graph, and a fault contingency plan knowledge graph. The multi-knowledge graph combined scheduling plan recommendation method is based on the alarm knowledge base based on expert experience, combined with the correlation analysis capability of the knowledge graph, and combined with the fault contingency plan knowledge graph to build a scheduling plan recommendation system.

[0075] In some embodiments, the knowledge graph management platform is also used to provide periodic services, automatically generating dispatch logs using anomaly alarm event information and dispatcher processing operation information. The fault contingency plan knowledge graph provides services that can retrieve fault-related fault contingency plan information, historical maintenance information, historical operation ticket information, and dispatch log information from the fault contingency plan knowledge base based on information such as faulty equipment and fault type.

[0076] For example, see Figure 3 As shown, clicking the "Contingency Plan" button for a fault-related alarm event allows you to view related fault contingency plans, historical maintenance information, historical operation information, and dispatch log information. The knowledge graph management platform provides periodic services, automatically generating dispatch logs using fault-related alarm event information, operation ticket information, and dispatcher processing information.

[0077] For example, a recommended fault response interface prototype is as follows: Figure 4 As shown, clicking the "Plan / Strategy" details button for a fault alarm event will bring up this dialog box. The dialog box contains four tabs, which display the system's recommended fault plans, historical maintenance records, fault handling operation ticket information, and related scheduling logs. The template format for the fault plan can be customized as needed, and the content of the plan is extracted from the knowledge base by calling services provided by the scheduling knowledge graph platform.

[0078] like Figure 4As shown, clicking the "Maintenance Status" tab will display historical maintenance records related to the fault, with each record presented as a maintenance order. Clicking the "Operation Ticket" tab will display the operation ticket information associated with the fault.

[0079] For example, the prototype of the operation ticket interface is as follows: Figure 5 As shown, Figure 5 The upper half of the page displays all operation ticket records related to the faulty equipment. Clicking on a record in the table will display the detailed information of the corresponding operation ticket in the lower half of the table.

[0080] In some embodiments, alarm events, dispatcher processing operations, automatic control program operations, and power grid operation information are imported and stored in a relational database using the aforementioned interfaces for interaction with the OCS system and intelligent alarm system. Based on the type of abnormal event, equipment type, and current power grid operation status, knowledge reasoning is used to extract corresponding handling strategy information from the abnormal event handling strategy knowledge base. This includes: obtaining fault-related fault contingency plan information, historical maintenance information, historical operation ticket information, and dispatch log information from the fault contingency plan knowledge base based on information including faulty equipment and fault type.

[0081] In some embodiments, information is imported from a third-party system into a relational database, and information extraction, knowledge fusion, and knowledge processing are performed before being stored in a graph database. This includes: the knowledge graph management platform extracting alarm events, dispatcher processing operations, automatic control program operations, and power grid operation modes from the relational database, performing information extraction, knowledge fusion, and knowledge processing on them to form a searchable knowledge base for power grid abnormal event handling strategies, and storing it in the graph database.

[0082] In this embodiment, the knowledge graph management platform extracts alarm events, dispatcher processing operations, automatic control program operations, and power grid operation modes from the relational database, performs information extraction, knowledge fusion, and knowledge processing on them, and forms a searchable knowledge base of power grid abnormal event handling strategies, which is then stored in the graph database.

[0083] Among them, the fault contingency plan knowledge graph provides services that can extract relevant handling strategy information from the abnormal event handling strategy knowledge base based on the type of abnormal event, equipment type, and current status of power grid operation using knowledge reasoning.

[0084] For example, clicking the "Contingency Plan" button for an abnormal alarm event will display the system's recommended handling strategies.

[0085] In this embodiment, the knowledge graph management platform provides periodic services and automatically generates scheduling logs using abnormal alarm event information and scheduler processing operation information.

[0086] Taking voltage exceeding limits as an example, the system constructs a system based on the relationship between voltage and reactive power, such as... Figure 6 The diagram shows nine zones.

[0087] When the voltage exceeds the limit, the system will use the following strategy to provide an adjustment strategy based on the relationship between voltage and reactive power:

[0088] Region 1: U is closer to the upper limit, Q is closer to the lower limit.

[0089] Adjustment measures: Remove the capacitor

[0090] Backup solution: Tap down (voltage priority mode)

[0091] Region 2: U exceeds the upper limit, Q is normal but slightly smaller.

[0092] Adjustment measures: Remove the capacitor

[0093] Backup solution: Tap down (voltage priority mode)

[0094] Region 3: U exceeds the upper limit, Q is normal.

[0095] Adjustment measures: Lower the tap or disconnect the capacitor (capacitor priority).

[0096] Alternative solutions: Remove the capacitor or adjust the tap changer (capacitor priority).

[0097] Region 4: U exceeds the upper limit, Q is normal but slightly larger.

[0098] Adjustment strategy: Lower the tap position

[0099] Alternative solution: Disconnect the capacitor (voltage priority mode)

[0100] Zone 5: U exceeds the upper limit, Q exceeds the upper limit.

[0101] Adjustment strategy: Lower the tap position

[0102] Alternative options: Deactivate capacitors (voltage priority mode) or activate capacitors (reactive power priority mode).

[0103] Region 6: U is normal to slightly large, Q is below the lower limit.

[0104] Adjustment measures: Remove the capacitor

[0105] Region 7: U is normal to slightly large, Q exceeds the upper limit.

[0106] Adjustment strategy: Lower the tap position

[0107] Alternative solution: Connect capacitors (reactive power priority mode)

[0108] Region 8: U is normal, Q is below the lower limit.

[0109] Adjustment measures: Remove the capacitor

[0110] Region 10: U is normal, Q exceeds the upper limit.

[0111] Adjustment measures: Investing capacitors

[0112] Region 11: U is normal to slightly small, Q is below the lower limit.

[0113] Adjustment strategy: Adjust the tap upwards

[0114] Alternative solution: Disconnect capacitors (reactive power priority mode)

[0115] Region 12: U is normal to slightly small, Q exceeds the upper limit.

[0116] Adjustment measures: Investing capacitors

[0117] Region 13: The lower U is, the lower Q is.

[0118] Adjustment strategy: Adjust the tap upwards

[0119] Alternative options: Deactivate capacitors (reactive power priority mode) or activate capacitors (voltage priority mode).

[0120] Region 14: U is below the lower limit, Q is normal but slightly small.

[0121] Adjustment strategy: Adjust the tap upwards

[0122] Alternative solution: Connect capacitors (voltage priority mode)

[0123] Region 15: U exceeds the lower limit, Q is normal.

[0124] Adjustment measures: Adjust the tap changer or connect a capacitor (capacitor priority).

[0125] Backup plan: Activate capacitors or adjust taps (capacitors preferred).

[0126] Region 16: U is below the lower limit, Q is normal but slightly larger.

[0127] Adjustment measures: Investing capacitors

[0128] Backup solution: Adjust the tap changer (voltage priority mode)

[0129] Region 17: U is closer to the lower limit, Q is closer to the upper limit.

[0130] Adjustment strategy: Install capacitors.

[0131] In some embodiments, if there is no corresponding contingency plan for a fault alarm event, the system provides an interface to import offline contingency plans into the system. It also provides an editing interface for contingency plans to assist relevant personnel in creating them. The created contingency plans are stored in a relational database and extracted and transferred to a graph database by the knowledge graph management platform.

[0132] In this embodiment, the handling process for abnormal alarm events is similar to that for faults, only the information and interface differ. The prototype interface for editing contingency plans is similar to that for viewing fault contingency plans, except that the editing interface supports entering fault contingency plan information through drop-down lists, date components, and edit boxes. The entered fault contingency plan information will be stored in a relational database and extracted and processed by the knowledge graph management platform to form a fault contingency plan knowledge base. The prototype interface is shown below. Figure 7 As shown.

[0133] In the multi-knowledge graph combined scheduling plan recommendation method of this invention, fault plan information is extracted based on a knowledge graph management platform. This includes using natural language information extraction technology to extract information such as plan name, plan number, and overview from unstructured fault plans and constructing triples. During the construction of the fault plan knowledge graph, information such as basic equipment information, parameter database, scheduling logs, emergency plans, maintenance orders, operation information, displacement information, and power grid models (CIM model XML) in the scheduling domain are collected. Object, attribute, and relationship information are extracted from these sources to construct the fault plan knowledge graph.

[0134] When parsing a query, if the user inputs historical search results as natural language text, the natural language text needs to be converted into a language that the machine can understand. Natural language understanding technology is then used to identify the user's intent and extract key information from the user's input.

[0135] Historical search based on knowledge graphs offers a more intelligent solution to these problems compared to traditional search engines that rely on keyword-based retrieval. Traditional search engines, centered on keyword search, compare keywords to find matching information from a vast amount of online data. Users can input one or more keywords to search, but this method often yields irrelevant results and is too mechanical, not reflecting human thought processes.

[0136] In the embodiments of this application, the scheduling plan module requires data such as equipment information, parameter library, scheduling log, emergency plan, maintenance order, operation information, and change information.

[0137] It should be noted that in this embodiment, the interface with the third-party system supports Web Service, FTP, JMS, microservices and other interface methods. One of these methods will be selected depending on the situation of the third-party system.

[0138] In this embodiment, the internal service is developed using Spring Boot and the MyBatis framework to provide RESTful services; the front-end interface is built using Vue and the Element UI framework, with the interface implementation decoupled from the back-end service and capable of being deployed independently.

[0139] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may, for example, be executed synchronously or asynchronously in multiple modules.

[0140] In one embodiment of this application, a scheduling plan recommendation device combining multiple knowledge graphs is provided. This device includes a knowledge graph management platform, a scheduling plan module, an alarm access module, and a plan recommendation module. The knowledge graph management platform is used to establish a matching rule base for alarm event types and alarm signal types. The scheduling plan module is used to import information from third-party systems into a relational database, perform information extraction, knowledge fusion, and knowledge processing, and store the information in a graph database. The alarm access module is used to receive alarm events and alarm signals. The plan recommendation module is used to call the knowledge graph service to determine if there is a missing signal. If a missing signal exists, the alarm event is marked. If no missing signal exists, it is determined whether it is a fault alarm. If it is a fault alarm, a fault plan is recommended; otherwise, an anomaly handling strategy is recommended.

[0141] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above program modules when performing related operations. When the application is invoked, the above processing can be assigned to different program modules as needed, that is, the internal structure of the terminal is divided into different program modules to complete all or part of the processing described above.

[0142] Furthermore, the apparatus provided in the above embodiments and the method embodiments in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0143] Furthermore, in an exemplary embodiment of the present invention, a computer device capable of implementing the above-described method for recommending scheduling plans by combining multiple knowledge graphs is also provided. Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0144] The following reference Figure 8 To describe a computer device according to an embodiment of the present invention. Figure 8 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0145] like Figure 8 As shown, the computer device is represented in the form of a general-purpose computing device. The components of the computer device may include, but are not limited to: at least one processor 401, at least one memory 402, a bus 403 connecting different system components (including memory 402 and processor 401), and a display 404.

[0146] The memory stores program code that can be executed by the processor 401, causing the processor 401 to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention.

[0147] In embodiments of this application, the computer device is configured to perform the following method: based on the knowledge graph management platform, establish a matching rule base for alarm event types and alarm signal types; import information from a third-party system into a relational database, and perform information extraction, knowledge fusion, knowledge processing, and storage in a graph database; receive alarm events and alarm signals, and call the knowledge graph service to determine whether there is a missing signal; if there is a missing signal, mark the alarm event; if there is no missing signal, determine whether it is a fault alarm; if it is a fault alarm, recommend a fault contingency plan, otherwise recommend an anomaly handling strategy.

[0148] In this embodiment, memory 402 may include a readable medium in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0149] The memory 402 may also include a program / utility having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0150] Bus 403 can represent one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus structures.

[0151] The computer device can also communicate with one or more external devices (such as keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the computer device, and / or any device that enables the computer device to communicate with one or more other computing devices (such as routers, modems, etc.). This communication can be performed through input / output (I / O) interfaces. Furthermore, the computer device can communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the computer device via bus 403. It should be understood that other hardware and / or software modules can be used in conjunction with the computer device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0152] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions of the embodiments of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, portable hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of the present invention.

[0153] In exemplary embodiments of the present invention, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0154] In exemplary embodiments of the present invention, a program product for implementing the above-described method according to embodiments of the present invention is described, which may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0155] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0156] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0157] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0158] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0159] This application provides a method and apparatus for recommending dispatch plans using a combination of multiple knowledge graphs. It establishes a matching rule base between alarm event types and alarm signal types; imports information from third-party systems into a relational database, performs information extraction, knowledge fusion, and knowledge processing, and stores the information in a graph database; receives alarm events and alarm signals; and invokes knowledge graph services to build intelligent alarm plan push, historical maintenance event association push, and historical dispatch log association push. Through this approach, while meeting the real-time requirements of power grid dispatch operations, it provides dispatchers with auxiliary decision-making support when handling power grid faults, enriches dispatchers' recovery decision-making methods, can push optimal fault handling solutions, and provides services externally in the form of APIs, thereby improving the efficiency of power grid fault handling and the robustness of the entire power grid business system.

[0160] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1.A multi-knowledge graph combined dispatch plan recommendation method applied to a knowledge graph management platform, characterized in that, The dispatching plan recommendation method comprises the following steps: Based on the knowledge graph management platform, a matching rule library of alarm event types and alarm signal types is established, wherein the knowledge graph management platform comprises an expert experience alarm knowledge base and a power grid model knowledge graph and a fault plan knowledge graph; Import information from a third-party system to a relational database, and perform information extraction, knowledge fusion, knowledge processing, and storage in a graph database; Receive alarm events and alarm signals, and based on the matching rule library and the expert experience alarm knowledge base, through correlation analysis of the power grid model knowledge graph and the fault plan knowledge graph, call the knowledge graph service to determine whether there is signal missing, and build a dispatching plan recommendation; Wherein, the receiving of the alarm events and the alarm signals comprises: using an interface interacting with an intelligent alarm system to obtain fault class and abnormal class alarm events according to a configurable time frequency; using an interface interacting with an OCS system to obtain alarm signals according to a configurable time frequency; Wherein, when calling the knowledge graph service to determine whether there is signal missing, if there is signal missing, the alarm event is marked; if there is no signal missing, it is determined whether it is a fault class alarm; if it is a fault class alarm, a fault plan is recommended, and if not, an abnormal handling strategy is recommended; when calling the knowledge graph service to determine whether there is signal missing, it also comprises: Using the plant, interval, device information associated with the alarm event and the alarm signal, and the occurrence time information to analyze the alarm signals related to the alarm event; The fault plan knowledge graph provides services, and according to the given alarm event and alarm signal, uses the pre-established matching rule library to determine whether the given alarm event has an alarm signal missing condition; Wherein, when determining whether it is a fault class alarm, if not, an abnormal handling strategy is recommended, which comprises: according to the abnormal event type, the device type and the power grid operation status, using knowledge reasoning to extract the corresponding disposal strategy information from the abnormal event disposal strategy knowledge base; According to the abnormal event type, the device type and the power grid operation status, using knowledge reasoning to extract the corresponding disposal strategy information from the abnormal event disposal strategy knowledge base, comprises: according to the fault device and the fault type, obtaining the fault related fault plan information, historical maintenance information, historical operation ticket information and dispatching log information from the fault plan knowledge base. 2.The method of Claim 1, wherein, Importing information from a third-party system to a relational database comprises: Accessing the OMS system, importing fault plans, historical maintenance records, historical operation ticket information, dispatching log information, and dispatcher handling operations, and storing them in the relational database; and Accessing the OCS system, importing alarm signals, power grid models, operation data, and dispatcher operations. 3.The method of Claim 2, wherein, The knowledge graph management platform in the dispatching plan recommendation method is also used to extract fault plans, historical operation ticket information, and dispatching log information from the relational database, perform information extraction, knowledge fusion, and knowledge processing, form a searchable fault plan knowledge base, and store it in the graph database. 4.The method of Claim 3, wherein, The knowledge graph management platform is also used for providing periodic services, utilizing abnormal class alarm event information and dispatcher processing operation information to automatically generate a dispatch log. 5.A scheduling plan recommendation device based on multi-knowledge graph combination, characterized in that, Comprise: A multi-knowledge graph construction module for establishing a matching rule library of alarm event types and alarm signal types based on a knowledge graph management platform; A dispatch plan module for importing information from a third-party system to a relational database, and performing information extraction, knowledge fusion, knowledge processing and storage in a graph database; An alarm access module for receiving alarm events and alarm signals, including: utilizing an interface for interacting with an intelligent alarm system to obtain fault class and abnormal class alarm events according to a configurable time frequency; utilizing an interface for interacting with an OCS system to obtain alarm signals according to a configurable time frequency; A plan recommendation module for calling a knowledge graph service to determine whether there is signal loss, and if there is signal loss, identifying the alarm event; if there is no signal loss, determining whether it is a fault class alarm; if it is a fault class alarm, recommending a fault plan, and if not, recommending an abnormal processing strategy; wherein, when calling the knowledge graph service to determine whether there is signal loss, if there is signal loss, the alarm event is identified; if there is no signal loss, it is determined whether it is a fault class alarm; if it is a fault class alarm, a fault plan is recommended, and if not, an abnormal processing strategy is recommended; when calling the knowledge graph service to determine whether there is signal loss, it also includes: utilizing plant station, interval, device information and occurrence time information associated with the alarm event and the alarm signal to analyze the alarm signals related to the alarm event; a fault plan knowledge graph provides services, according to the given alarm event and alarm signal, utilizing the pre-established matching rule library, to determine whether the given alarm event has an alarm signal loss; wherein, when determining whether it is a fault class alarm, if not, an abnormal processing strategy is recommended, and the abnormal processing strategy includes: according to the abnormal event type, the device type and the power grid operation status, utilizing knowledge reasoning to extract the corresponding disposal strategy information from the abnormal event disposal strategy knowledge base; according to the abnormal event type, the device type and the power grid operation status, utilizing knowledge reasoning to extract the corresponding disposal strategy information from the abnormal event disposal strategy knowledge base, including: according to the fault device and the fault type, obtaining the fault related fault plan information, the historical maintenance information, the historical operation ticket information and the dispatch log information from the fault plan knowledge base.

Images