Network fault handling method, device, equipment and storage medium of a power system

Abstract

The present disclosure provides a method, apparatus, device, and storage medium for network fault handling in a power system, relating to the technical field of power system control. The method includes: obtaining a network fault handling request for the power system, where the network fault handling request includes fault parameters; determining a fault diagnosis process that matches the fault parameters; obtaining the input parameters required for the fault diagnosis process according to the input parameter rules of the fault diagnosis process; and based on the input parameters, executing the fault diagnosis process to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process. According to the solution of the present disclosure, various different network faults can be automatically diagnosed according to actual network services, avoiding the need for manual fault diagnosis after a fault occurs, reducing the time for manual diagnosis of power equipment faults, and improving the diagnosis efficiency of network faults in the power system.

Description

Technical Field

[0001] The present disclosure relates to the technical field of power system control, and particularly to a method, apparatus, electronic device, and storage medium for handling network faults in a power system. Background Art

[0002] Most of the power equipment in the power system adopts a planned maintenance system, which has serious defects, such as frequent temporary maintenance, insufficient or excessive maintenance, and blind maintenance. How to reasonably arrange the maintenance of power equipment, save maintenance costs, reduce maintenance costs, and at the same time ensure that the system has high reliability is an important issue for system operators.

[0003] With the development of technology, the application of comprehensive intelligent systems such as sensing technology, microelectronics, computer software and hardware, digital signal processing technology, artificial neural networks, expert systems, and fuzzy set theory in condition monitoring and fault diagnosis has promoted the development of condition-based maintenance research based on equipment condition monitoring and advanced diagnosis technology.

[0004] There are many devices in the power system. When network faults occur in these devices, it will cause abnormal operation of the power system. In the prior art, when a network fault occurs in the power system, it is often necessary to manually check the cause of the abnormality, resulting in low efficiency of fault handling. Summary of the Invention

[0005] The present disclosure provides a method, apparatus, device, and storage medium for handling network faults in a power system to solve or alleviate one or more technical problems in the prior art.

[0006] In a first aspect, the present disclosure provides a method for handling network faults in a power system, including:

[0007] Obtaining a network fault handling request for the power system, where the network fault handling request includes fault parameters;

[0008] Determining a fault diagnosis process that matches the fault parameters;

[0009] Obtaining input parameters required for the fault diagnosis process according to the input parameter rules of the fault diagnosis process;

[0010] Executing the fault diagnosis process based on the input parameters to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process.

[0011] In a second aspect, the present disclosure provides a fault handling apparatus for a power device, including:

[0012] A first obtaining module, configured to obtain a network fault handling request for the power device, where the network fault handling request includes fault parameters;

[0013] A determination module, configured to determine a fault diagnosis process that matches the fault parameters;

[0014] A second acquisition module, configured to acquire the input parameters required for the fault diagnosis process according to the input parameter rules of the fault diagnosis process;

[0015] A first execution module, configured to execute the fault diagnosis process based on the input parameters to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process.

[0016] In a third aspect, an electronic device is provided, including:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any method in the embodiments of the present disclosure.

[0020] In a fourth aspect, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to execute any method in the embodiments of the present disclosure.

[0021] In a fifth aspect, a computer program product is provided, including a computer program, and the computer program implements any method in the embodiments of the present disclosure when executed by a processor.

[0022] The beneficial effects of the technical solution provided by the present disclosure at least include:

[0023] The present disclosure can automatically respond to the network fault handling request of the power system, match the corresponding fault diagnosis process, avoid the situation that manual fault diagnosis is required after the fault occurs, reduce the time for manual diagnosis of power equipment faults, and improve the diagnosis efficiency of power equipment faults.

[0024] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In the drawings, unless otherwise specified, the same reference numerals throughout the several views denote the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments provided by the present disclosure and should not be regarded as limiting the scope of the present disclosure.

[0026] Figure 1 It is a schematic flow diagram of processing network faults according to an embodiment of the present disclosure;

[0027] Figure 2 It is a schematic diagram of a configuration interface for configuring a port DOWN fault diagnosis process according to another embodiment of the present disclosure;

[0028] Figure 3 It is a schematic diagram of an interface for generating port DOWN input parameter rules and output parameter rules according to another embodiment of the present disclosure;

[0029] Figure 4 It is a schematic diagram of a configuration interface for configuring a BGP neighbor DOWN fault diagnosis process according to another embodiment of the present disclosure;

[0030] Figure 5 It is a schematic diagram of an interface for generating BGP neighbor DOWN input parameter rules and output parameter rules according to another embodiment of the present disclosure;

[0031] Figure 6a It is a schematic diagram of a configuration interface for port DOWN call rules and processing flows according to another embodiment of the present disclosure;

[0032] Figure 6b It is a schematic diagram of a fault diagnosis process search interface according to another embodiment of the present disclosure;

[0033] Figure 7 It is a schematic diagram of a configuration interface for BGP neighbor DOWN call rules and processing flows according to another embodiment of the present disclosure;

[0034] Figure 8a It is a schematic diagram of a configuration interface for port DOWN filtering policies according to another embodiment of the present disclosure;

[0035] Figure 8b It is a schematic diagram of a configuration interface for filtering policies according to another embodiment of the present disclosure;

[0036] Figure 9 It is a schematic diagram of a configuration interface for BGP neighbor DOWN filtering policies according to another embodiment of the present disclosure;

[0037] Figure 10 It is a schematic flow diagram of processing network faults in a power system according to another embodiment of the present disclosure;

[0038] Figure 11 It is a schematic flow diagram of processing network faults in a power system according to another embodiment of the present disclosure;

[0039] Figure 12 It is a schematic flow diagram of processing network faults in a power system according to another embodiment of the present disclosure;

[0040] Figure 13a It is a schematic diagram of the diagnosis result of port DOWN according to another embodiment of the present disclosure;

[0041] Figure 13b It is a schematic diagram of the diagnosis result of BGP neighbor DOWN according to another embodiment of the present disclosure;

[0042] Figure 14 It is a schematic structural diagram of a network fault processing device for a power system according to another embodiment of the present disclosure;

[0043] Figure 15 It is a block diagram of an electronic device for implementing the method of network fault processing for a power system according to an embodiment of the present disclosure. Detailed implementation manners

[0044] The present disclosure will be described in further detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings do not have to be drawn to scale unless otherwise specified.

[0045] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present disclosure can be implemented without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0046] In the related art, when a network fault occurs in a power system, manual troubleshooting is generally required. However, manual troubleshooting is inefficient and also causes a large cost for fault troubleshooting.

[0047] In view of this, the present disclosure proposes a method for network fault processing in a power system. As Figure 1 shown, it is a schematic flowchart of processing a network fault according to an embodiment of the present disclosure, including:

[0048] S101, obtaining a network fault processing request for a power system, where the network fault processing request includes fault parameters.

[0049] In some embodiments, the network fault processing requests for the power system may be one or more. Since the processing methods for each network fault processing request are the same, the present disclosure takes one network fault processing request as an example for illustration.

[0050] Among them, after a fault occurs in the power system, an alarm message will be generated. In the embodiments of the present disclosure, the network fault processing request may be the alarm message.

[0051] In other embodiments, the network fault handling request may also be a business work order, that is, a to-be-processed task generated based on the alarm information. In addition, the business work order may further include urgency information, so as to facilitate the prioritized handling of urgent tasks in the case of receiving multiple network fault handling requests.

[0052] Among them, in some embodiments, the fault parameters in the network fault handling request may include the device type where the fault occurs, the device ID (Identity document), the fault type, etc. During implementation, the required fault parameters can be set according to the actual business requirements.

[0053] S102. Determine the fault diagnosis process that matches the fault parameters.

[0054] In the embodiments of the present disclosure, multiple fault diagnosis processes can be pre-configured. When a network fault handling request for a power device is received, an appropriate fault diagnosis process can be matched based on the fault parameters, so as to achieve the purpose of analyzing the cause of the fault using an appropriate fault diagnosis process. Taking the fault parameters including the fault type as an example, corresponding fault diagnosis processes can be pre-configured for different fault types. After determining the fault type of the power device, an appropriate fault diagnosis process can be matched from multiple fault diagnosis processes to perform subsequent operations. Of course, in other embodiments, multiple parameters in the fault parameters can also be used to match the fault diagnosis process.

[0055] To facilitate the correct invocation and execution of the fault diagnosis process, the fault diagnosis process in the embodiments of the present disclosure has corresponding parameter rules, such as input parameter rules and output parameter rules. Among them, the input parameter rules are used to describe the requirements of the fault diagnosis process for the input parameters, and the output parameter rules are used to describe the requirements of the fault diagnosis process for the output fault diagnosis results.

[0056] On this basis, in S103, according to the input parameter rules of the fault diagnosis process, obtain the input parameters required for the fault diagnosis process.

[0057] The input parameter rules may include the required parameter names and the format requirements for the parameter values. The format requirements for the parameter names may include the case of the parameters, and the format requirements for the parameter values may include the data type.

[0058] When relevant parameters need to be input, the input parameters must follow the input parameter rules of the fault diagnosis process. Among them, the input parameters can be obtained from the network fault handling request information, the device where the fault occurs, or the power system according to the specific fault diagnosis process that is matched.

[0059] S104. Based on the input parameters, execute the fault diagnosis process to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process.

[0060] In summary, in the embodiments of the present disclosure, after a network fault occurs in the power system, an appropriate fault diagnosis process can be automatically matched for fault diagnosis, realizing a fully automatic, real-time and fast response to network fault handling requests and obtaining fault diagnosis results. Thereby, the situation where manual dispatching diagnosis of faults is required after the occurrence of faults is avoided, the time for manual diagnosis of power equipment faults is reduced, and the efficiency of diagnosing network faults in the power system is improved.

[0061] The embodiments of the present disclosure mainly relate to the configuration of the fault diagnosis process. In order to facilitate the flexible invocation of the fault diagnosis process, the invocation rules of the fault diagnosis process can also be flexibly configured in the embodiments of the present disclosure. In addition, in order to facilitate the automatic handling of faults, the configuration and use of the fault handling process are also designed in the embodiments of the present disclosure. In addition, a filtering strategy is also set in the embodiments of the present disclosure to flexibly adapt to the requirements of different scenarios, so as to improve the efficiency of fault diagnosis. The above important contents involved in the embodiments of the present disclosure are described in detail below.

[0062] I. Configuration of the Fault Diagnosis Process

[0063] In the embodiments of the present disclosure, the fault diagnosis process and the parameter requirements of the fault diagnosis process can be generated based on the following methods, including the following contents:

[0064] Step A1, in response to a user operation, construct a flow chart including multiple process nodes.

[0065] Among them, each fault diagnosis process corresponds to a flow chart. Each flow chart contains multiple process nodes, and each process node needs to execute corresponding fault diagnosis capabilities.

[0066] In implementation, in step A2, for each process node in the flow chart, in response to the selection operation of the target capability in the capability set, associate the target capability as the capability that the process node needs to execute, thereby obtaining the fault diagnosis capability of each process node.

[0067] The fault diagnosis capability can be a pre-developed functional module, and different functional modules constitute a capability set for users to freely select and flexibly configure into the corresponding flow chart.

[0068] The capability set includes a series of fault diagnosis capabilities. For these fault diagnosis capabilities, iteration can be performed according to actual needs. For example, new fault diagnosis capabilities can be added to the capability set, existing fault diagnosis capabilities can be deleted, and even existing fault diagnosis capabilities can be updated.

[0069] In some embodiments, the same process nodes may be included in different fault diagnosis processes, and even the fault diagnosis capabilities required for the same process node are the same. Thus, by constructing a set of capabilities, the same fault diagnosis capability can be flexibly associated with different fault diagnosis processes, achieving flexible configuration of the fault diagnosis process.

[0070] It should be noted that in the embodiments of the present disclosure, after configuring each process node that is sequentially executed in the flowchart, the corresponding fault diagnosis capabilities can be bound to each process node respectively. Of course, after selecting a process node in the flowchart, the corresponding fault diagnosis capability can be associated with this process node, and then the next process node can be configured, and the corresponding fault diagnosis capability can be associated with the next process node. In short, in the embodiments of the present disclosure, the execution order of step A1 and step A2 is not limited. During implementation, the flowchart and the fault diagnosis capabilities of each process node can be flexibly configured.

[0071] Step A3, based on the input parameter requirements of the target capabilities of each process node in the flowchart, generate input parameter rules. And, based on the output parameter requirements of the diagnosis report generation node in the flowchart, generate output parameter rules.

[0072] In the flowchart, the fault diagnosis capabilities of each process node all include an input parameter step. Therefore, it is necessary to first determine the input parameter rules. After the fault diagnosis capability is executed, the corresponding diagnosis result will be obtained. According to the output parameter rules, this diagnosis result is added to the diagnosis report. Among them, the generation of the diagnosis report is implemented by the corresponding diagnosis report generation node. After the diagnosis result is determined at the corresponding process node, the diagnosis report generation node sorts out these diagnosis results according to the output parameter rules to obtain the final diagnosis report.

[0073] In the embodiments of the present disclosure, the fault diagnosis process can be flexibly configured based on the user's operation, and the corresponding fault diagnosis capabilities can be flexibly associated with each process node. Each link is closely linked, and the determination of the rules and the execution of the capabilities are inseparable and cooperate with each other to automatically diagnose network faults, thereby improving the efficiency of the fault diagnosis process.

[0074] For ease of understanding, the following takes the port DOWN as an example to exemplarily illustrate how to configure the fault diagnosis process. As Figure 2 shown, the set of capabilities in the embodiments of the present disclosure may include first-level capabilities and second-level capabilities. For example, Figure 2In it, if the ability set in the left column includes device diagnosis and SDN (Software Defined Network) analysis as first-level abilities, under this first-level ability, there are multiple optional second-level abilities for implementing this first-level ability. Similarly, multiple third-level abilities can be included under the second-level ability, and so on. The present disclosure does not make specific limitations on the level of abilities. The reason for setting the second-level ability is that the same first-level ability can have different implementation methods to facilitate adaptation to different fault diagnosis requirements.

[0075] The user can select a second-level ability under the device diagnosis ability from the first-level abilities, such as the port DOWN ability, and then select a third-level ability from the port DOWN ability to construct a process node. As Figure 2 shown, the process nodes included in the process of the user constructing the port DOWN are: start node, associated alarm diagnosis node, local port check node, obtain circuit peer node, determination node, peer port check node, one-key diagnosis conclusion node (i.e., diagnosis report generation node), and end node. During implementation, different process nodes can adopt different display effects, for example, different process nodes can be reflected by different shading to facilitate the user's understanding of the flow chart.

[0076] In addition to selecting process nodes from the ability set, process nodes required can also be selected in the process node drawing function. For example, a determination node is used to determine whether there is control permission for the peer port. Only when there is such permission, the peer port check node will be triggered to detect the network fault of the peer port. As Figure 2 shown, different process nodes are connected by arrows to establish the execution order between the process nodes.

[0077] As Figure 3 shown, after the flow chart of the configured port DOWN is generated, the input parameter rule and output parameter rule are generated. In Figure 3 it, the input parameter rule requires the parameter name of the input parameter and its corresponding data type. The specific parameter value can be configured when the diagnostic process needs to be called subsequently. Figure 3 In the "service work order configuration" in it, there is a service type. The configured process or so-called ability here is configured according to the service work order. In the case of a service work order, the diagnostic process to be adopted is determined according to the service work order, and the diagnostic process to be adopted can be one or more. Click Figure 3 the "interface format" in it, and a Jason format will be exported, which is convenient for testing when called.

[0078] Continuing to take the BGP (Border Gateway Protocol) neighbor DOWN as an example, the configuration of the fault diagnosis process will be described. As Figure 4 andFigure 5 As shown. You can also select the corresponding process node from the capability set, and the resulting flow chart is as follows Figure 4 As shown, it includes: a start node, a PING test node, a determination node, a port status diagnosis node, a one-key diagnosis conclusion node, and an end node. When the diagnosis process starts, a Ping test is first performed to check the link status, that is, whether the network is connected. The determination node is used to determine which process should be executed later.

[0079] Figure 5 In, with Figure 3 Similarly, after the BGP neighbor DOWN flowchart is configured, the input parameter rules and output parameter rules are generated. Figure 5 In the input parameter rule, the parameter name of the input parameter and its corresponding data type are also required. The specific parameter value can be configured when the diagnostic process needs to be called later.

[0080] 2. Calling rules of fault diagnosis process

[0081] In the embodiment of the present disclosure, in order to realize flexible calling of the fault diagnosis process, calling rules of the fault handling process are pre-configured.

[0082] like Figure 6a As shown, the corresponding Figure 2 and Figure 3 Schematic diagram of the configuration interface of the calling rule of port DOWN. Figure 6a In the configuration, the calling rules of the fault diagnosis process can be configured through interface interaction.

[0083] exist Figure 6a In the Pre-processing Settings, you can select the fault diagnosis process to be configured. Here, you can use the Select control next to Pre-processing Settings to enter Figure 6b In this interface, you can search for configured fault diagnosis processes. Figure 6b In the search, multiple search conditions are provided, including "resource name", "resource code", "network", "creator", and "valid". "Valid" is used to indicate whether the existing fault diagnosis process is valid. Through these screening conditions, the required fault diagnosis process can be accurately screened out. If "Port DOWN" is selected in the screened fault diagnosis process, the corresponding Figure 6a The name of the selected fault diagnosis process will be displayed in the "Preprocessing Rules" section of the interface.

[0084] exist Figure 6a There are two options for "Preprocessing Type", one is automatic and the other is manual. If automatic is selected, the fault diagnosis process of port DOWN will be automatically executed. If manual is selected, it can only be executed after user authorization.

[0085] In Figure 6a "Preprocessing delay time" is used to set how long to delay before starting to execute the fault diagnosis process when it is determined to execute the fault diagnosis process.

[0086] In Figure 6a "Number of preprocessing calls" can be selected to execute in a loop or once. In the case of selecting loop execution, in Figure 6a the time interval between two loop executions can also be set through "preprocessing call interval".

[0087] In Figure 6a "Parameter association" shows the input parameters of the selected port DOWN fault diagnosis process, but the parameter values of these input parameters need to be configured by the user in Figure 6a As Figure 6a shown, in the column of "associated alarm parameters", the user can set "device identifier" and "sub - object name" to obtain the input parameters required for the fault diagnosis process. Here, when the fault parameters of the fault handling request match the "associated alarm parameters", it is determined that the corresponding fault diagnosis process needs to be executed. In other embodiments, the input parameters of the fault diagnosis process can also be obtained from the Figure 6a "associated alarm parameters".

[0088] As Figure 7 shown, it is a schematic diagram of the configuration interface corresponding to the call rules of BGP neighbor DOWN in Figure 4 and Figure 5 In Figure 7 the call rules of the fault diagnosis process can be configured through interface interaction.

[0089] In Figure 7 through "preprocessing settings", the fault diagnosis process to be configured can be selected. Here, through the "select" control next to "preprocessing settings", it will also enter the Figure 6b interface. In this interface, the configured fault diagnosis processes can be searched. Through the above - mentioned multiple filtering conditions, the required fault diagnosis process can be accurately filtered out. Select "BGP neighbor DOWN" from the filtered - out fault diagnosis processes, then correspondingly, in Figure 7 the "preprocessing rule name" in the interface will display the name of the selected fault diagnosis process, that is, "H3BGPDown".

[0090] In Figure 7 "Preprocessing type" also provides two options, one is automatic and the other is manual. In the case of selecting automatic, the fault diagnosis process of BGP neighbor DOWN will be automatically executed. In the case of selecting manual, it needs to be authorized by the user before execution.

[0091] In Figure 7 the "preprocessing delay time" is used to set how long to delay before starting to execute the fault diagnosis process when it is determined to execute the fault diagnosis process.

[0092] In Figure 7 the "preprocessing call times" can be selected to execute in a loop or once. In the case of selecting loop execution, in Figure 7 it is also possible to set the time interval between two loop executions through the "preprocessing call interval".

[0093] In Figure 7 the "parameter association" shows the input parameters of the selected BGP neighbor DOWN fault diagnosis process, but the parameter values of these input parameters need to be configured by the user in Figure 7 As shown in Figure 7 , under the column of "associated alarm parameters", the user can set the "device identifier" and "sub-object name" to facilitate obtaining the input parameters required for the fault diagnosis process. Here, when the fault parameters of the fault handling request match the "associated alarm parameters", it is determined that the corresponding fault diagnosis process needs to be executed. In other embodiments, it is also possible to obtain the input parameters of the fault diagnosis process from the Figure 7 "associated alarm parameters".

[0094] In summary, through the Figure 7 call rule configuration, the fault diagnosis process will be executed according to the call rules, and can be implemented as:

[0095] Step B1, when the call rule requires delaying a specified duration to execute the fault handling process, delay the specified duration from the receipt of the network fault handling request to execute the fault handling process. In Figure 7 , for example, the "preprocessing delay time" is set to 0 minutes, that is, preprocessing is immediately performed after receiving the fault handling request.

[0096] Step B2, when the call rule requires manual triggering, in response to the execution command triggered by the user operation in the human-machine interface, execute the fault handling process. It can be implemented through the "preprocessing type", that is, when selecting manual, user authorization is required to continue executing the corresponding process. In Figure 7 , for example, the "preprocessing type" can also be set to automatic, that is, the processing process is automatically executed according to the configuration rules and no longer requires manual participation.

[0097] Step B3, when the call rule requires loop execution of the fault handling process, execute the fault handling process in a loop according to the pre-configured loop interval until the end condition is met. The end conditions include meeting any of the following conditions: executing the target number of times, the fault is resolved. In Figure 7In [the above], it is embodied that the loop or single execution can be selected through the "number of preprocessing calls". In the case of selecting loop execution, the time interval between two loop executions can also be set through the "preprocessing call interval". For example, if the "number of preprocessing calls" is set to once and the "preprocessing call interval" is set to 0 minutes, only one preprocessing call will be made and there will be no more loop calls.

[0098] In the embodiments of the present disclosure, by adding call rules, the fault diagnosis process can be flexibly called, so that the same fault diagnosis process can adapt to different application requirements.

[0099] III. Fault handling process

[0100] As described above, the embodiments of the present disclosure can not only flexibly configure the fault diagnosis process and call rules, but also flexibly configure the fault handling process to facilitate automatic handling of network faults according to the fault diagnosis results. For example Figure 6a includes corresponding Figure 2 and Figure 3 the configuration interface diagram of the fault handling process for the port DOWN in [the above].

[0101] In Figure 6a for the "Add" control next to the "Disposal rule setting", multiple disposal rules can be added as needed. All the disposal rules configured for the port DOWN diagnosis process are included in its corresponding fault handling process. After obtaining the diagnosis result using the fault diagnosis capability, the corresponding fault is processed based on the corresponding disposal rule in the fault handling process.

[0102] For each disposal rule, as Figure 6a shown, the "Restriction conditions" for the corresponding disposal rule can also be configured for the corresponding disposal rule, that is, the trigger conditions for the disposal rule are configured. When the trigger conditions are met, the corresponding disposal rule is executed. It can be understood that the trigger conditions are configured based on the out-parameter rules. For example, the restriction condition code here corresponds to Figure 3 the code of the output parameter. Figure 6a shows that when the value of the code in the diagnosis result meets "0000", the corresponding disposal rule is executed.

[0103] Figure 6a the "Select" control after the "Disposal rule setting" in [the above] is used to select the corresponding disposal rule from the pre-configured set of disposal rules. After selecting the disposal rule, Figure 6a next to the "Disposal rule name" in [the above] will display the selected disposal rule name for easy verification.

[0104] Figure 6a the "Disposal call type" in [the above] is used to configure automatic or manual, that is, whether to trigger the disposal rule automatically or manually.

[0105] Figure 6a The specific parameter values required for the handling rule are configured in the "Parameter Association" item under "Handling Rule Setting".

[0106] Similarly, for Figure 7 the processing flow configuration for the BGP neighbor DOWN diagnosis result shown is similar to Figure 6a and will not be elaborated here.

[0107] Based on the configured fault handling flow, in this example of the present disclosure, after obtaining the fault diagnosis result, the following steps can also be implemented:

[0108] Step C1, perform a matching operation between the rule set in the fault handling flow and the fault diagnosis result. For example Figure 6a in, the rule set can be expanded through "Add" next to "Handling Rule Setting", and a specific handling rule can be selected from the rule set through "Select". Each handling rule has a corresponding fault diagnosis result. Therefore, when a handling rule is selected, the fault diagnosis result matching the handling rule is also automatically determined.

[0109] Step C2, in the case of matching any rule in the rule set, execute the fault handling method associated with any rule in the fault handling flow. For example, in Figure 6a if the selected handling rule name is H3checkport, correspondingly, the H3checkport fault handling method in the fault handling flow will be executed.

[0110] Considering from the perspective of improving the fault handling efficiency, the feedback of the rule set and the fault diagnosis result are corresponding. After a fault is determined, the network fault is automatically handled according to the handling in the processing flow, which can accelerate the fault handling efficiency.

[0111] IV. Filtering Policy

[0112] In the embodiments of the present disclosure, sometimes in the power system, the use of equipment may be planned to be suspended due to reasons such as maintenance. Therefore, in order to flexibly meet the business requirements of the power system, a filtering policy can also be configured in the embodiments of the present disclosure. This filtering policy is used to indicate which fault handling requests can be simply processed.

[0113] For example Figure 8a as shown, it is a schematic diagram of the configuration interface for the filtering policy corresponding to Figure 2 and Figure 3 the port DOWN. Figure 8aIn this case, each network fault handling request corresponds to a group name respectively, and each group name is associated with a filtering policy respectively. Therefore, the filtering policy can be matched based on the network fault handling request. The filtering policy refers to the conditions and circumstances under which the network fault handling request is filtered out. For example Figure 8a In Figure 8a , for a fault handling request with the "group name" being "link flash interruption", if the alarm level of this fault handling request meets the condition of being greater than or equal to 1, then this fault handling request can be analyzed and processed without going through the corresponding fault diagnosis process.

[0114] Figure 8b It means that the fault handling request can be filtered out in advance according to the filtering policy by adding conditions. The added conditions can be, for example, alarm status, alarm category code, alarm category name, alarm type code, alarm type name, device identifier, device name, device IP, sub-object name, etc. These fault-related information can be selected as the diagnosis policy in the added conditions, and the fault-related information can be combined.

[0115] For example, when the alarm status is selected, the fault handling request needs to meet not only the filtering requirements of the alarm level but also the requirements of the alarm status before it will be filtered out. Of course, the multiple selected conditions can also be in an alternative relationship. For example, meeting the alarm level or meeting the alarm status can also filter out the fault handling request.

[0116] For example Figure 9 As shown in Figure 9 , it is a schematic diagram of the configuration interface corresponding to the filtering policy for BGP neighbor DOWN in Figure 4 and Figure 5 . Figure 4 and Figure 5 Figure 5 . Figure 9 In Figure 9 , similar to Figure 8a , each network fault handling request corresponds to a group name respectively, and each group name is associated with a filtering policy respectively. The filtering policy can be matched based on the network fault handling request. At the same time, similar to Figure 8b , Figure 8a it can also include configuring to filter out device faults caused by human initiative in advance according to the filtering policy by adding conditions. These fault-related information can be selected as the diagnosis policy in the added conditions, and the fault-related information can be combined. Figure 8b similar Figure 9 to Figure 8b .

[0117] After the filtering policy is configured, before determining the fault diagnosis process that matches the fault parameters in the embodiments of the present disclosure, the implementation manner of using the filtering policy can be as follows:

[0118] Step D1: Determine the group name corresponding to the network fault handling request.

[0119] Step D2: Perform a matching operation on the network fault handling request and the filtering policy associated with the group name.

[0120] Step D3, when matching the filtering policy, generate a fault diagnosis result for an alarm caused by a scheduled task.

[0121] Among them, the scheduled tasks such as scheduled power outages and scheduled maintenance can be configured according to actual needs, and all are applicable to the embodiments of the present disclosure.

[0122] In addition, a scheduled task may also generate a fault handling request. During a scheduled power outage, the powered-off device will issue an alarm. The embodiments of the present disclosure can exclude the situation of a fault caused by a scheduled task, so as not to continue to execute the automated fault diagnosis process for this situation. This avoids automated diagnosis of predictable faults, saves fault diagnosis time, improves resource utilization to a certain extent, and also speeds up the fault diagnosis efficiency.

[0123] After introducing the above various configurations and corresponding execution processes, the following takes the corresponding Figure 2 port DOWN as an example to illustrate the network fault handling method of the power system provided by the embodiments of the present disclosure. As Figure 10 shown, the following steps may be included:

[0124] S1001, when the fault type of the network fault handling request is a port disconnection, query the associated alarm message of the network fault handling request.

[0125] Among them, the associated alarm message can be provided by an API (Application Programming Interface).

[0126] S1002, when the associated alarm information is queried, perform a fault diagnosis on the port that generates the associated alarm message to obtain an associated alarm port diagnosis result.

[0127] In the embodiments of the present disclosure, for the convenience of distinction and understanding, the port that generates the network fault handling request is called the local port, and the port that has a communication relationship with the local port is called the peer port.

[0128] S1003, check the port status of the local port that generates the network fault handling request to obtain a local port diagnosis result.

[0129] S1004, when the local port is associated with a peer port and has management authority over the peer port, check the port status of the peer port to obtain a peer port diagnosis result.

[0130] S1005, when the local port is associated with a peer port and does not have management authority over the peer port, if the status and performance of the local port are normal, generate a peer port diagnosis result indicating that there may be a problem with the peer port.

[0131] S1006. According to the output parameter rules, organize the diagnostic results of the associated alarm port, the local port, and the peer port to obtain the fault diagnosis result.

[0132] In the embodiments of the present disclosure, in the case of a port disconnection, by using the associated alarm message, not only can the port status of the local port be diagnosed to obtain the local port diagnostic result, but also the diagnostic result of the associated alarm port can be obtained according to the associated alarm message. And when the local port has the management authority over the peer port, the port status of the peer port can be checked together to obtain the diagnostic result of the peer port. Even when the local port does not have the management authority over the peer port, the source of the fault can be preliminarily analyzed to obtain a diagnostic conclusion, which strengthens the comprehensiveness of the diagnostic result and improves the fault handling efficiency.

[0133] To facilitate accurate detection of the port status, in the embodiments of the present disclosure, for any target port among the local port and the peer port, check the port status of the target port to obtain the port diagnostic result, as Figure 11 shown, including the following steps:

[0134] S1101. Determine the device type of the local device that generates the network fault handling request.

[0135] In some embodiments, the device types of the ports are divided into physical ports, bundled ports, sub-interfaces, etc.

[0136] S1102. Screen out the subset of inspection instructions that match the device type from the instruction set.

[0137] Among them, for the above device types, the corresponding subsets of inspection instructions are respectively, for example: for manufacturer 1, the subset of inspection instructions supported by the devices of manufacturer 1 is adopted, which can accurately diagnose the network faults of manufacturer 1. For manufacturer 2, the subset of inspection instructions supported by the devices of manufacturer 2 is adopted, which can accurately diagnose the network faults of manufacturer 2.

[0138] S1103. Based on the subset of inspection instructions, perform the following operations:

[0139] S1104. Check whether the reason for the target port to be closed is a preset reason, and the preset reasons include manually closing the port or closing the port due to a work order.

[0140] Among them, manually closing the port means that the target port is manually closed due to human factors, and closing the port due to a work order means that the target port is automatically closed due to the requirements of the work order after a fault occurs.

[0141] S1105. When the reason for the target port to be closed is a preset reason, generate a port diagnostic result for the port disconnection due to the preset reason.

[0142] S1106, when the closing reason of the target port is not the preset reason, check the optical module status of the target port.

[0143] Among them, the optical module consists of optoelectronic devices, functional circuits, optical interfaces, etc. The optoelectronic devices include two parts: transmitting and receiving. Simply put, the role of the optical module is that the transmitting end converts the electrical signal into an optical signal, and after transmission through the optical fiber, the receiving end converts the optical signal back into an electrical signal. Since the optical module can reflect the fault situation of the device, if the optical module fails, it is no longer possible to correctly determine whether the device has actually had a problem through the optical module.

[0144] S1107, when it is determined that there is a problem with the optical module of the target port, generate a port diagnosis result requesting replacement of the optical module.

[0145] S1108, when it is determined that the optical module of the target port is normal, check the link performance of the target port to obtain a port diagnosis result regarding the link performance inspection result.

[0146] Regarding the link performance, taking Ethernet as an example, the link performance of Ethernet includes parameters such as throughput, latency, packet loss rate, etc. The standards it follows are the national standard GBT 21671-2018 "Acceptance and Evaluation Specification for LAN Systems Based on Ethernet Technology" and RFC 2544, and RFC 2544 also includes back-to-back tests. The quality of the link performance can indirectly affect the normal operation of the target port.

[0147] In the embodiments of the present disclosure, the device types of the local device are classified, so as to be able to more efficiently and feasibly determine the inspection instructions for each device type, and then use the diagnosis results after inspection to respond to the fault request. By using the classified unified judgment instead of the one-by-one judgment method, the fault handling efficiency is improved. Analyze and judge the possible reasons for the target port failure from the perspectives of preset reasons, optical modules, link performance, etc., comprehensively and specifically consider the reasons for the target port failure, and provide conditions for giving corresponding solutions in advance based on the determined fault reasons, improving the efficiency of fault handling.

[0148] After introducing the port DOWN fault diagnosis, the following takes the fault diagnosis of the corresponding Figure 4 and Figure 5 BGP neighbor DOWN as an example for further illustration, as Figure 12 shown:

[0149] S1201, when the fault type of the network fault handling request is BGP neighbor disconnection, check the link status between the local device that generates the network fault handling request and the neighbor device of the local device, and check the port status of the local port that generates the network fault handling request.

[0150] Among them, the check of the link state is implemented through the Ping (Packet Internet Groper) connectivity test, that is, the local device performs a Ping test on the BGP neighbor IP (Internet Protocol). In addition, the processing logic for checking the port state of the local port that generates a network fault handling request is as follows: According to the BGP neighbor IP, view the static routing table, obtain the local port, check the local port state, and give a diagnosis conclusion of port disconnection or normal operation of the port based on the local port state.

[0151] S1202, in the case where the link state is link down and the port state of the local port is port disconnection, generate a fault diagnosis result of an alarm caused by the physical port disconnection of the local port.

[0152] S1203, in the case where the link state is link down and the port state of the local port is port online, generate a fault diagnosis result of an alarm caused by the link protocol disconnection.

[0153] S1204, in the case where the link state is link normal, generate a fault diagnosis result that the link is normal but the target configuration needs to be detected.

[0154] In summary, in the case of a BGP neighbor disconnection, the fault diagnosis results may include physical port disconnection, link protocol disconnection, and problems with the peer-related configuration. In the embodiments of the present disclosure, the link state and the port state are respectively checked based on the fault type of BGP neighbor disconnection, making the fault analysis process more detailed, considering more diverse possible fault factors, and improving the fault handling efficiency.

[0155] For the convenience of understanding the complete fault handling process in the present disclosure, as Figure 13a shown, it is a schematic diagram of the diagnosis result obtained after the execution of the fault handling process for port DOWN in the embodiments of the present disclosure. Among them, according to the requirements, the selected fault handling process is as follows: associated alarm diagnosis, local port check, obtaining circuit peer information, peer port check, and obtaining a one-key diagnosis conclusion. Corresponding to the fault handling process:

[0156] The associated alarm diagnosis result of the associated alarm diagnosis node is: there is a relevant alarm, and the diagnosis result details, that is, the alarm information is: "Alarm related to GigabitEthernet4 / 0: Port 4 is down", and the time consumption is 0 seconds;

[0157] The local port check result is: manually closed or closed by a work order, and the specific check information is: "Circuit code: GigabitEthernet4 / 0;

[0158] Inflow of GigabitEthernet4 / 0: 0 Mbps / s, Outflow: 0 Mbps / z, Inflow utilization: 0, Outflow utilization inflow erc: 0;

[0159] The physical state of GigabitEthernet4 / 0 at the local end is DOWN, the protocol state is DOWN, slot number 4, port number 0, optical module model, received optical power in dBm, threshold [,] dBm, transmitted optical power in dBm, threshold [,] dBm, please check the transmission device, taking 1 second;

[0160] The result of obtaining the peer information of the circuit is: There is peer information, taking 0 seconds;

[0161] The result of the peer port check is: Manually closed or closed by work order, and the specific check information is: "Circuit code: Gigabitthernet4 / 0;

[0162] Inflow of GigabitEthernet4 / 0: 0 Mbps / s, Outflow: 0 Mbps / s, Inflow utilization: 0, Outflow utilization 0, Inflow crc: 0;

[0163] The physical state of GigabitEthernet4 / 0 at the local end is DOWN, the protocol state is DOWN, slot number 4, port number 0, optical module model, received optical power in dBm, threshold [,] dBm, transmitted optical power in dBm, threshold [,] dBm, please check the transmission device:", taking 1 second;

[0164] The one - key diagnosis conclusion is: Manually closed or closed by work order, and the diagnosis process tracking takes 0 seconds.

[0165] And Figure 13a Similarly, Figure 13b This is a schematic diagram of the diagnosis result obtained after the execution of the fault handling process for the BGP neighbor DOWN in the embodiments of the present disclosure. Among them, according to requirements, the selected fault handling processes are: Ping test, port status diagnosis, and obtaining the one - key diagnosis conclusion. Corresponding to the fault handling process, the Ping test result is: Unreachable; the port status diagnosis result is: UP; the obtained one - key diagnosis conclusion is: Caused by the link protocol down. And Figure 13a Similarly, the detailed diagnosis results of each process node can also be displayed.

[0166] Based on the same technical concept, the embodiments of the present disclosure also provide a network fault handling device for a power system, as Figure 14 shown, including:

[0167] The first acquisition module 1401 is used to acquire a network fault handling request for the power system, and the network fault handling request includes fault parameters;

[0168] The first determination module 1402 is configured to determine a fault diagnosis process that matches the fault parameters;

[0169] The second acquisition module 1403 is configured to acquire the input parameters required for the fault diagnosis process according to the input parameter rules of the fault diagnosis process;

[0170] The first execution module 1404 is configured to execute the fault diagnosis process based on the input parameters to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process.

[0171] In some embodiments, the network fault handling device of the present disclosure further includes:

[0172] The process configuration module is configured to generate a fault diagnosis process and parameter requirements of the fault diagnosis process based on the following method:

[0173] In response to a user operation, construct a flowchart including a plurality of process nodes;

[0174] For each process node in the flowchart, in response to a selection operation on a target capability in the capability set, associate the target capability with the capability to be executed by the process node;

[0175] Generate input parameter rules based on the input parameter requirements of the target capabilities of each process node in the flowchart; and generate output parameter rules based on the output parameter requirements of the diagnosis report generation node in the flowchart.

[0176] In some embodiments, the first execution module 1404 is configured to:

[0177] In the case where the fault type of the network fault handling request is port disconnection, query the associated alarm message of the network fault handling request;

[0178] In the case where the associated alarm information is queried, perform a fault diagnosis on the port that generates the associated alarm message to obtain an associated alarm port diagnosis result;

[0179] Check the port status of the local port that generates the network fault handling request to obtain a local port diagnosis result;

[0180] In the case where the local port is associated with a peer port and has management authority over the peer port, check the port status of the peer port to obtain a peer port diagnosis result;

[0181] In the case where the local port is associated with a peer port and does not have management authority over the peer port, if the status and performance of the local port are normal, generate a peer port diagnosis result indicating that there may be a problem with the peer port;

[0182] According to the output parameter rules, organize the associated alarm port diagnosis results, the local port diagnosis results, and the peer port diagnosis results to obtain the fault diagnosis results.

[0183] In some embodiments, for any target port among the local port and the peer port, the first execution module 1404 includes:

[0184] A determination sub-module, configured to determine the device type of the local device that generates the network fault handling request;

[0185] A screening sub-module, configured to screen out a subset of inspection instructions that match the device type from the instruction set;

[0186] An execution sub-module, configured to perform the following operations based on the subset of inspection instructions:

[0187] Check whether the reason for closing the target port is a preset reason, where the preset reasons include manually closing the port or closing the port due to a work order;

[0188] In the case where the reason for closing the target port is a preset reason, generate a port diagnosis result for the port going offline due to the preset reason;

[0189] In the case where the reason for closing the target port is not a preset reason, check the optical module status of the target port;

[0190] In the case where it is determined that there is a problem with the optical module of the target port, generate a port diagnosis result requesting to replace the optical module;

[0191] In the case where it is determined that the optical module of the target port is normal, check the link performance of the target port to obtain a port diagnosis result regarding the link performance inspection result.

[0192] In some embodiments, the first execution module 1404 is further configured to:

[0193] In the case where the fault type of the network fault handling request is that the BGP neighbor goes offline, check the link status between the local device that generates the network fault handling request and the neighbor device of the local device, and check the port status of the local port that generates the network fault handling request;

[0194] In the case where the link status is that the link is down and the port status of the local port is that the port is offline, generate a fault diagnosis result for the alarm caused by the physical port of the local port going offline;

[0195] In the case where the link status is that the link is down and the port status of the local port is that the port is online, generate a fault diagnosis result for the alarm caused by the link protocol going offline;

[0196] In the case where the link status is that the link is normal, generate a fault diagnosis result that the link is normal but the target configuration needs to be detected.

[0197] In some embodiments, a fault handling process is pre-configured, and the apparatus further includes:

[0198] A first matching module, configured to perform a matching operation between a rule set in the fault handling process and a fault diagnosis result;

[0199] A second execution module, configured to execute a fault handling method associated with any rule in the fault handling process when any rule in the rule set is matched.

[0200] In some embodiments, a filtering policy is pre-configured due to a planned task, and the apparatus further includes:

[0201] A third determination module, configured to determine a group name corresponding to a network fault handling request before determining a fault diagnosis process that matches the fault parameters;

[0202] A second matching module, configured to perform a matching operation between the network fault handling request and a filtering policy associated with the group name;

[0203] A second generation module, configured to generate a fault diagnosis result for an alarm caused by a planned task when it matches the filtering policy.

[0204] In some embodiments, a calling rule for a fault handling process is pre-configured, and the first execution module 1404 is configured to:

[0205] When the calling rule requires delaying the execution of the fault handling process by a specified duration, start delaying the execution of the fault handling process by the specified duration from the time when the network fault handling request is received;

[0206] When the calling rule requires manual triggering, execute the fault handling process in response to an execution command triggered by a user operation in the human-computer interaction interface;

[0207] When the calling rule requires loop execution of the fault handling process, loop execute the fault handling process at a pre-configured loop interval until an end condition is met, and the end condition includes meeting any of the following conditions: executing a target number of times, or the fault is resolved.

[0208] For the specific functions and example descriptions of the modules and sub-modules of the apparatus according to the embodiments of the present disclosure, reference may be made to the relevant descriptions of the corresponding steps in the above method embodiments, which will not be elaborated herein.

[0209] In the technical solution of the present disclosure, the acquisition, storage, and application of user personal information involved all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0210] Figure 15 It is a structural block diagram of an electronic device according to an embodiment of the present disclosure. AsFigure 15 As shown, the electronic device includes: a memory 1501 and a processor 1502. The memory 1501 stores a computer program that can run on the processor 1502. The number of the memory 1501 and the processor 1502 can be one or more. The memory 1501 can store one or more computer programs. When the one or more computer programs are executed by the electronic device, the electronic device executes the method provided in the above method embodiment. The electronic device may further include: a communication interface 1503, configured to communicate with external devices and perform data interaction and transmission.

[0211] If the memory 1501, the processor 1502, and the communication interface 1503 are implemented independently, the memory 1501, the processor 1502, and the communication interface 1503 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 15 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0212] Optionally, in a specific implementation, if the memory 1501, the processor 1502, and the communication interface 1503 are integrated on a chip, the memory 1501, the processor 1502, and the communication interface 1503 can communicate with each other through an internal interface.

[0213] It should be understood that the above-mentioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor supporting the Advanced RISC Machines (ARM) architecture.

[0214] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may further include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0215] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present disclosure are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wirelessly (such as infrared, Bluetooth, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a Digital Versatile Disc (DVD)), or a semiconductor medium (such as a Solid State Disk (SSD)), etc. It should be noted that the computer-readable storage medium mentioned in the present disclosure can be a non-volatile storage medium, in other words, it can be a non-transitory storage medium.

[0216] Those of ordinary skill in the art can understand that all or part of the steps for implementing the above embodiments can be completed by hardware, or can be completed by a program instructing relevant hardware. The program can be stored in a computer-readable storage medium, and the storage medium mentioned above can be a read-only memory, a magnetic disk, an optical disc, etc.

[0217] In the description of the embodiments of the present disclosure, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples.

[0218] In the description of the embodiments of the present disclosure, unless otherwise specified, " / " means "or". For example, A / B may represent A or B. "And / or" herein is merely a description of the relationship between associated objects, indicating that there can be three relationships. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone.

[0219] In the description of the embodiments of the present disclosure, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present disclosure, unless otherwise specified, "a plurality of" means two or more.

[0220] The above are only exemplary embodiments of the present disclosure and are not intended to limit the present disclosure. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present disclosure shall be included within the protection scope of the present disclosure.

Claims

1. A method for processing network faults in a power system, characterized in that, Including: Obtain a network fault handling request of a power system, where the network fault handling request includes fault parameters; Determine a fault diagnosis process that matches the fault parameters; According to the input parameter rules of the fault diagnosis process, obtain the input parameters required for the fault diagnosis process; Based on the input parameters, execute the fault diagnosis process to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process; It also includes: Generate the fault diagnosis process and the parameter requirements of the fault diagnosis process based on the following method: In response to a user operation, construct a flow chart including multiple process nodes; For each process node in the flow chart, in response to a selection operation on a target ability in the ability set, associate the target ability as the ability required to be executed by the process node; Generate the input parameter rules based on the input parameter requirements of the target abilities of each process node in the flow chart; and, Generate the output parameter rules based on the output parameter requirements of the diagnosis report generation node in the flow chart; Based on the input parameters, execute the fault diagnosis process to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process, including: When the fault type of the network fault handling request is port disconnection, query the associated alarm message of the network fault handling request; When the associated alarm message is queried, perform a fault diagnosis on the port that generates the associated alarm message to obtain an associated alarm port diagnosis result; Check the port status of the local port that generates the network fault handling request to obtain a local port diagnosis result; When the local port is associated with a peer port and has management authority over the peer port, check the port status of the peer port to obtain a peer port diagnosis result; When the local port is associated with a peer port and does not have management authority over the peer port, if the status and performance of the local port are normal, generate a peer port diagnosis result that the peer port is suspected to have problems; According to the output parameter rules, organize the associated alarm port diagnosis result, the local port diagnosis result, and the peer port diagnosis result to obtain the fault diagnosis result.

2. The method according to claim 1, characterized in that, For any target port among the local port and the peer port, check the port status of the target port to obtain a port diagnosis result, including: Determine the device type of the local device that generates the network fault handling request; Screen out a subset of inspection instructions that match the device type from the instruction set; Based on the subset of inspection instructions, perform the following operations: Check whether the shutdown reason of the target port is a preset reason, where the preset reasons include manually shutting down the port or shutting down the port due to a work order; When the shutdown reason of the target port is the preset reason, generate a port diagnosis result that the port is disconnected due to the preset reason; When the shutdown reason of the target port is not the preset reason, check the optical module status of the target port; When it is determined that there is a problem with the optical module of the target port, generate a port diagnosis result requesting to replace the optical module; When it is determined that the optical module of the target port is normal, check the link performance of the target port to obtain a port diagnosis result regarding the link performance check result.

3. The method according to claim 1, wherein Based on the input parameters, execute the fault diagnosis process to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process, and further includes: When the fault type of the network fault handling request is that the BGP neighbor goes offline, check the link status between the local device that generates the network fault handling request and the neighbor device of the local device, and check the port status of the local port that generates the network fault handling request; When the link status is that the link is down and the port status of the local port is that the port is offline, generate a fault diagnosis result for an alarm caused by the physical port of the local port going offline; When the link status is that the link is down and the port status of the local port is that the port is online, generate a fault diagnosis result for an alarm caused by the link protocol going offline; When the link status is normal, generate a fault diagnosis result that the link is normal but the target configuration needs to be detected.

4. The method according to claim 1, characterized in that There is a pre-configured fault handling process, and further includes: Perform a matching operation between the rule set in the fault handling process and the fault diagnosis result; When any rule in the rule set is matched, execute the fault handling method associated with the any rule in the fault handling process.

5. The method according to claim 1, wherein Because a filtering policy is pre-configured for planned tasks, before determining the fault diagnosis process that matches the fault parameters, it further includes: Determine the group name corresponding to the network fault handling request; Perform a matching operation between the network fault handling request and the filtering policy associated with the group name; When it matches the filtering policy, generate a fault diagnosis result for an alarm caused by a planned task.

6. The method according to claim 1, characterized in that, There is a pre-configured call rule for the fault handling process, and the execution of the fault diagnosis process includes: When the call rule requires delaying the execution of the fault handling process for a specified duration, start delaying the specified duration from the time when the network fault handling request is received and execute the fault handling process; When the call rule requires manual triggering, in response to an execution command triggered by a user operation in the human-computer interaction interface, execute the fault handling process; When the call rule requires looping to execute the fault handling process, loop to execute the fault handling process at a pre-configured loop interval until an end condition is met, and the end condition includes meeting any of the following conditions: executing a target number of times, the fault is resolved.

7. A fault handling device for a power device, characterized in that, Includes: A first acquisition module, configured to acquire a network fault handling request of a power system, where the network fault handling request includes fault parameters; A first determination module, configured to determine a fault diagnosis process that matches the fault parameters; A second acquisition module, configured to acquire the input parameters required for the fault diagnosis process according to the input parameter rules of the fault diagnosis process; A first execution module, configured to execute the fault diagnosis process based on the input parameters to obtain a fault diagnosis result that conforms to the output parameter rules of the fault diagnosis process; Further includes: A process configuration module, which is used to generate a fault diagnosis process and parameter requirements for the fault diagnosis process based on the following method: In response to a user operation, construct a flow chart containing multiple process nodes; For each process node in the flow chart, in response to a selection operation on a target capability in the capability set, associate the target capability with the capability that the process node needs to execute; Generate an input parameter rule based on the input parameter requirements of the target capabilities of each process node in the flow chart; and generate an output parameter rule based on the output parameter requirements of the diagnosis report generation node in the flow chart; The first execution module is used for: When the fault type of the network fault handling request is a port disconnection, query the associated alarm message of the network fault handling request; When an associated alarm message is queried, perform a fault diagnosis on the port that generates the associated alarm message to obtain a diagnosis result of the associated alarm port; Check the port status of the local port that generates the network fault handling request to obtain a diagnosis result of the local port; When the local port is associated with a peer port and has management authority over the peer port, check the port status of the peer port to obtain a diagnosis result of the peer port; When the local port is associated with a peer port and does not have management authority over the peer port, if the status and performance of the local port are normal, generate a diagnosis result of the peer port indicating that the peer port may have problems; According to the output parameter rule, organize the diagnosis results of the associated alarm port, the local port, and the peer port to obtain a fault diagnosis result.

8. An electronic device, comprising: At least one processor; And A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method according to any one of claims 1-6.

Images