Failure estimation device, failure estimation method, and program

Abstract

A failure estimation device according to an embodiment is provided with: a first generation unit that, in response to an update of a topology including a plurality of tree structures connected to each other, generates a plurality of first paths that connect nodes in each tree structure of the plurality of tree structures; a determination unit that, in response to the occurrence of a first event, determines a first rule having a first condition part and a first conclusion part that includes the node type of a failed node; a second generation unit that generates a plurality of second paths that each have a first start point node matching the node type of the first conclusion part, and a first end point node belonging to a second tree structure directly connected to the first tree structure to which the first start point node belongs; and an estimation unit that estimates the failed node by searching for a path that matches the first condition part from among the plurality of first paths and the plurality of second paths.

Description

Fault estimation device, fault estimation method, and program

[0001] The embodiments relate to a fault estimation device, a fault estimation method, and a program.

[0002] Fault estimation techniques are known that estimate the cause and location of faults that occur on a network. These techniques use events such as alarms generated by nodes that make up the network when a fault occurs to estimate the fault.

[0003] For example, a rule-based fault estimation technique has been proposed that focuses on the relative positional relationship between a node where a fault has occurred and surrounding nodes where an event has been generated in response to the fault.

[0004] Fumika ASAI, Di Li, Norio YAMAMOTO, Haruhisa NOZUE, Kenichi TAYAMA, “Study and applicability evaluation of autonomous estimation for network failure”, IEICE Technical Report, vol. 122, no. 442, ICM2022 - 59, pp. 95 - 100, 2023

[0005] However, when applying rules that include the relative positional relationships between nodes, it is necessary to understand the routes between the nodes throughout the entire network as a pre-processing step. The time required for such pre-processing increases as the network scale increases. Therefore, if the network topology is updated frequently, the pre-processing time takes up a large proportion of the overall processing time, which may prevent the fault estimation process from being executed in a timely manner.

[0006] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a means for enabling timely execution of a fault estimation process.

[0007] A fault estimation device according to one aspect includes a first generation unit, a determination unit, a second generation unit, and an estimation unit. In response to an update of a topology including a plurality of interconnected tree structures, the first generation unit generates, for each of the plurality of tree structures, a plurality of first paths connecting nodes in the tree structures. In response to an occurrence of a first event, the determination unit determines a first rule having a first condition part and a first conclusion part including a node type of a fault node. The second generation unit generates a plurality of second paths having a first origin node matching the node type of the first conclusion part and a first end node belonging to a second tree structure directly connected to the first tree structure to which the first origin node belongs. The estimation unit estimates the fault node by searching the plurality of first paths and the plurality of second paths for a path matching the first condition part.

[0008] According to the embodiment, it is possible to provide a means for enabling the timely execution of the fault estimation process.

[0009] FIG. 1 is a block diagram showing an example of a fault estimation system and a network according to an embodiment. FIG. 2 is a block diagram showing an example of the hardware configuration of a communication device constituting a network according to an embodiment. FIG. 3 is a tree diagram showing an example of a tree structure configured by hardware in a communication device according to an embodiment. FIG. 4 is a block diagram showing an example of the hardware configuration of a fault estimation device according to an embodiment. FIG. 5 is a block diagram showing an example of the functional configuration of a fault estimation device according to an embodiment. FIG. 6 is a diagram showing an example of the data structure of a topology DB stored in the fault estimation device according to an embodiment. FIG. 7 is a diagram showing an example of the data structure of a rule DB stored in the fault estimation device according to an embodiment. FIG. 8 is a block diagram showing an example of a configuration related to the fault estimation function of the fault estimation device according to an embodiment. FIG. 9 is a flowchart showing an example of pre-processing in the fault estimation device according to an embodiment. FIG. 10 is a flowchart showing an example of intra-PD route generation processing in the fault estimation device according to an embodiment. FIG. 11 is a flowchart showing an example of each-time processing in the fault estimation device according to an embodiment. FIG. 12 is a flowchart showing an example of PL route generation processing in the fault estimation device according to an embodiment. FIG. 13 is a schematic diagram showing an example of a group of events generated when a fault occurs in the fault estimation device according to an embodiment.

[0010] Hereinafter, embodiments will be described with reference to the drawings. In the following description, components having the same functions and configurations will be denoted by the same reference numerals.

[0011] 1. Configuration 1.1 Fault Estimation System FIG. 1 is a block diagram showing an example of a fault estimation system and a network according to an embodiment.

[0012] The failure estimation system 1 is a system that estimates, for example, a failure that occurs in a network NW. The failure estimation system 1 includes a monitoring device 2 and a failure estimation device 3.

[0013] The network NW is an example of a topology to be monitored by the fault estimation system 1. The network NW is composed of multiple communication devices PD having connection relationships. The communication devices PD are physical elements such as switches that make up the network. The communication devices PD are also called physical devices. The example of FIG. 1 shows a case where the network NW is composed of eight communication devices PD1, PD2, PD3, PD4, PD5, PD6, PD7, and PD8.

[0014] The monitoring device 2 is, for example, a computer such as a server. The monitoring device 2 monitors the state of the network NW. When a failure occurs in the network NW, the monitoring device 2 collects events generated in the network NW. The events include, for example, the type of alarm (event type) issued from the communication device PD and information indicating the communication device PD (event-generating device) that issued the alarm. The monitoring device 2 inputs the collected group of events to the failure estimation device 3.

[0015] The failure estimation device 3 is, for example, a computer such as a server, etc. Based on the input event group, the failure estimation device 3 estimates what kind of failure has occurred in which communication device PD within the network NW.

[0016] 1.2 Communication Devices Next, the hardware configuration of the communication devices that make up the network according to this embodiment will be described.

[0017] 2 is a block diagram showing an example of the hardware configuration of communication devices constituting a network according to an embodiment. In FIG. 2, an example of the hardware configuration of communication devices PD1 and PD2 is shown. All communication devices PD other than communication devices PD1 and PD2 have the same hardware configuration as communication devices PD1 and PD2.

[0018] The communication device PD1 includes onboard devices EQP1 and EQP2. The communication device PD2 includes onboard devices EQP3 and EQP4. Each of the onboard devices EQP1, EQP2, EQP3, and EQP4 includes an SFP (small form-factor pluggable) such as a package, a card, or an optical module.

[0019] Communication ports PP1 and PP2 are connected to onboard equipment EQP1. Communication ports PP3 and PP4 are connected to onboard equipment EQP2. Communication ports PP5 and PP6 are connected to onboard equipment EQP3. Communication ports PP7 and PP8 are connected to onboard equipment EQP4. Each of the communication ports PP1 to PP8 functions as an input / output interface for signals in communication with other communication equipment PD. The example of Figure 2 shows a case where communication port PP1 of communication equipment PD1 and communication port PP5 of communication equipment PD2 are connected by a physical connection PL.

[0020] 3 is a tree diagram showing an example of a tree structure of hardware of a communication device according to an embodiment, which corresponds to the communication devices PD1 and PD2 shown in FIG.

[0021] As shown in FIG. 3 , communication equipment PD1 corresponds to a tree structure G1 including nodes PD1, EQP1, EQP2, PP1, PP2, PP3, and PP4. Specifically, node PD1 is the root of tree structure G1. Nodes EQP1 and EQP2 are connected to node PD1 as child nodes. Nodes PP1 and PP2 are connected to node EQP1 as child nodes. Node PP3 and PP4 are connected to node EQP2 as child nodes. Node PD1 corresponds to communication equipment PD1. Nodes EQP1 and EQP2 correspond to onboard equipment EQP1 and EQP2, respectively. Nodes PP1, PP2, PP3, and PP4 correspond to communication ports PP1, PP2, PP3, and PP4, respectively.

[0022] Similarly, communication equipment PD2 corresponds to tree structure G2 including nodes PD2, EQP3, EQP4, PP5, PP6, PP7, and PP8. Specifically, node PD2 corresponds to the root of tree structure G2. Nodes EQP3 and EQP4 are connected to node PD2 as child nodes. Nodes PP5 and PP6 are connected to node EQP3 as child nodes. Node PP7 and PP8 are connected to node EQP4 as child nodes. Node PD2 corresponds to communication equipment PD2. Nodes EQP3 and EQP4 correspond to onboard equipment EQP3 and EQP4, respectively. Nodes PP5, PP6, PP7, and PP8 correspond to communication ports PP5, PP6, PP7, and PP8, respectively.

[0023] Nodes PP1 and PP5 are directly connected to each other. This direct connection corresponds to a physical connection PL. In this way, the network NW corresponds to a topology including multiple tree structures connected to each other. Note that when a connection is made via another communication device PD, such as between communication devices PD1 and PD8 in FIG. 1, this indirect connection is distinguished from the above-mentioned direct connection.

[0024] In the following description, a path connecting nodes within a communication device PD is also referred to as an "intra-PD path." Also, a path directly connecting nodes belonging to different communication devices PD is also referred to as a "PL-routing path." In particular, a PL-routing path directly connecting nodes PP belonging to different communication devices PD is also referred to as an "inter-PP path."

[0025] In the network NW, a failure node and an event that are related to each other are associated one-to-one with a route formed by a tree structure such as that shown in Fig. 3. For example, if communication equipment PD1 generates an event due to a failure of onboard equipment EQP1, the event is associated with the intra-PD route connecting node EQP1 and node PD1 (EQP1<PD1). Also, for example, if communication equipment PD2 generates an event due to a failure of onboard equipment EQP1, the event is associated with the PL-routed route (EQP1>PP1:PP5<EQP3<PD2) that combines the intra-PD route connecting node EQP1 and node PP1, the inter-PP route connecting nodes PP1 and PP5, and the intra-PD route connecting node PP5 and node PD2.

[0026] Here, the symbol "<" indicates that the left node is a child node of the right node. The symbol ">" indicates that the left node is a parent node of the right node. The symbol ":" is used when there is no parent-child relationship between the left node and the right node. Hereinafter, a representation format of a path in which multiple nodes are connected with the symbols "<", ">", and ":" is also referred to as a "path representation". The leftmost node and the rightmost node in a path represented by a path representation are also referred to as the starting node and the ending node, respectively.

[0027] 1.3 Hardware Configuration of the Fault Estimation Device Next, the hardware configuration of the fault estimation device according to the embodiment will be described.

[0028] 4 is a block diagram showing an example of a hardware configuration of the fault estimation device 3 according to the embodiment. As shown in FIG. 4, the fault estimation device 3 includes a control circuit 11, a communication module 12, a user interface 13, a storage 14, a drive 15, and a storage medium 16.

[0029] The control circuit 11 is a circuit that controls the overall components of the fault estimation device 3. The control circuit 11 includes a CPU (Central Processing Unit), a RAM (Random Access Memory), a ROM (Read Only Memory), etc. The ROM of the control circuit 11 stores programs and the like used in various processes in the fault estimation device 3. The CPU of the control circuit 11 controls the entire fault estimation device 3 in accordance with the programs stored in the ROM of the control circuit 11. The RAM of the control circuit 11 is used as a work area for the CPU of the control circuit 11.

[0030] The communication module 12 is, for example, a circuit used for communicating data with the monitoring device 2 .

[0031] The user interface 13 is an interface that manages communication between a user and the control circuit 11. The user interface 13 includes input devices and output devices. The input devices include, for example, a keyboard, a touch panel, and operation buttons. The output devices include, for example, an LCD (Liquid Crystal Display) or an EL (Electroluminescence) display. The user interface 13 converts input from the user into an electrical signal and then transmits it to the control circuit 11. The user interface 13 outputs the execution result based on the user input to the user.

[0032] The storage 14 includes, for example, a hard disk drive (HDD) or a solid state drive (SSD). The storage 14 stores information used in various processes in the failure estimation device 3.

[0033] The drive 15 is a device for reading software stored in the storage medium 16. The drive 15 includes, for example, a CD (Compact Disk) drive and a DVD (Digital Versatile Disk) drive.

[0034] The storage medium 16 is a medium that stores software electrically, magnetically, optically, mechanically, or chemically. The storage medium 16 may store programs for executing various processes in the fault estimation device 3.

[0035] 1.4 Functional Configuration of the Fault Estimation Device Next, the functional configuration of the fault estimation device according to the embodiment will be described.

[0036] 1.4.1 Overview of Functional Configuration Fig. 5 is a block diagram showing an example of the functional configuration of a fault estimation device according to an embodiment. A fault case DB 21, a topology DB 22, and a rule DB 25 are stored in the storage 14 of the fault estimation device 3. The CPU of the control circuit 11 of the fault estimation device 3 loads a program stored in the ROM of the control circuit 11 or the storage medium 16 into the RAM of the control circuit 11. The CPU of the control circuit 11 then interprets and executes the program loaded into the RAM of the control circuit 11. As a result, the fault estimation device 3 functions as a computer equipped with a topology update function 23, a rule generation function 24, and a fault cause estimation function 26.

[0037] The failure case DB 21 is a database in which information relating to failures that have occurred in the network NW and events that were generated by the communication device PD at the time of the failure is stored in association with all past cases.

[0038] The topology DB 22 is a database of information that defines the connection relationships of the multiple communication devices SW that make up the network NW.

[0039] Fig. 6 is a diagram showing an example of the data structure of a topology DB stored in a fault estimation device according to an embodiment. The example shown in Fig. 6 corresponds to the network NW shown in Fig. 1. As shown in Fig. 6, the topology DB 22 stores, for each of the communication devices PD1 to PD8 constituting the network NW, a set of node name, node type, and information relating to the tree structure within the communication device PD (intra-PD tree). The topology DB 22 also stores information relating to the connection paths between communication ports PP (inter-PP paths).

[0040] The node name is an identifier that uniquely identifies a node within the network NW.

[0041] The node type is an identifier for identifying a node according to the difference in the function or role of the hardware corresponding to the node. The node type includes, for example, PD indicating that the node corresponds to the communication equipment PD, EQP indicating that the node corresponds to the onboard equipment EQP, and PP indicating that the node corresponds to the communication port PP.

[0042] The intra-PD tree is information that indicates, in a path expression, an intra-PD path between a node and a node corresponding to the root of the communication device PD to which the node belongs.

[0043] As described above, the inter-PP route is information that indicates, in a route expression, an inter-PP route between two nodes PP that belong to different communication devices PD.

[0044] In the example of FIG. 6 , the node type of node PD1 is “PD” and the tree in PD is (root). The node type of node EQP1 is “EQP” and the tree in PD is (PD1 > EQP1). The node type of node PP1 is “PP” and the tree in PD is (PD1 > EQP1 > PP1). The node type of node PP2 is “PP” and the tree in PD is (PD1 > EQP1 > PP2). The node type of node EQP2 is “EQP” and the tree in PD is (PD1 > EQP2). The node type of node PP3 is “PP” and the tree in PD is (PD1 > EQP2 > PP3). The node type of node PP4 is “PP” and the tree in PD is (PD1 > EQP2 > PP4). The node PD2 is indicated as having a node type of "PD" and an intra-PD tree of (root).

[0045] 6, it is shown that node PP1 belonging to communication equipment PD1 is connected to node PP5 belonging to communication equipment PD2. It is shown that node PP2 belonging to communication equipment PD1 is connected to node PP9 belonging to communication equipment PD3. It is shown that node PP3 belonging to communication equipment PD1 is connected to node PP18 belonging to communication equipment PD5.

[0046] Referring again to FIG. 5, the functional configuration of the fault estimation device 3 will be described.

[0047] The topology update function 23 executes a topology update process when the topology of the network NW is updated due to replacement of the communication device PD, etc. The topology update process is a process of updating the information stored in the topology DB 22 to the latest state based on the topology of the network NW after the update.

[0048] The rule generation function 24 generates rules used to estimate faults based on the fault case information acquired from the fault case DB 21 and the topology information acquired from the topology DB 22. The rule generation function 24 registers the generated rules in the rule DB 25.

[0049] A rule is, for example, information that associates a fault with a plurality of conditions that are highly relevant to the fault. A rule is expressed, for example, in an IF-THEN format. A rule is composed of an IF part (condition part) that represents a premise or condition, and a THEN part (conclusion part) that represents a conclusion or action when the condition part is true. That is, the condition part of a rule contains at least one condition including a path condition from the fault node to the event occurrence node and an event type of an event that occurred at the event occurrence node. The conclusion part of a rule contains a fault name corresponding to the at least one condition and a node type of the fault node (failure node type).

[0050] 7 is a diagram showing an example of the data structure of a rule DB stored in the fault estimation device according to the embodiment. In FIG. 7, one rule α of the multiple rules stored in the rule DB 25 is shown as an example.

[0051] In the example of FIG. 7, rule α includes two conditions IF_1 and IF_2.

[0052] The condition IF_1 is "an event of event type A occurs in a node connected from the node where the failure occurred by an intra-PD path expression (EQP<PD)."

[0053] The condition IF_2 is "an event of event type B occurs at a node connected from the node where the failure occurred by a route expression via PL (EQP>PP:PP<EQP<PD)."

[0054] When the two conditions IF_1 and IF_2 described above are both satisfied, rule α indicates that the conclusion, "A fault with the fault name card fault has occurred in a node whose fault node type is EQP," is true. Furthermore, by calculating the rate at which the two conditions IF_1 and IF_2 described above are satisfied, it is also possible to calculate the certainty of the possibility that "A fault with the fault name card fault has occurred in a node whose fault node type is EQP."

[0055] Referring again to FIG. 5, the functional configuration of the fault estimation device 3 will be described.

[0056] The failure cause estimation function 26 uses rules registered in the rule DB 25 to estimate the cause of a failure that has occurred in the network NW (i.e., the name of the failure and the faulty device) from the group of events input from the monitoring device 2. The failure cause estimation function 26 outputs the estimation result to the maintenance operator OP.

[0057] The maintenance person OP checks the estimation result and determines whether the estimation result is correct. If the estimation result is correct, the estimation result is registered as it is in the failure case DB 21 as a confirmation result. If the estimation result is incorrect, information corrected to the correct content is registered in the failure case DB 21 as a confirmation result.

[0058] 1.4.2 Failure Cause Estimation Function Next, the failure cause estimation function of the failure estimation device according to the embodiment will be described in detail.

[0059] 8 is a block diagram showing an example of the configuration of the failure factor estimation function of the failure estimation device according to the embodiment. As shown in FIG. 8, the failure factor estimation function 26 stores a PD-based connection DB 33, an intra-PD route DB 34, and a PL via route DB 36. The failure factor estimation function 26 also includes an intra-PD route generation unit 31, a rule determination unit 32, a PL via route generation unit 35, and a certainty factor calculation unit 37.

[0060] When the topology DB 22 is updated, the intra-PD path generation unit 31 executes an intra-PD path generation process based on the updated topology DB 22. The intra-PD path generation process is a process for updating the intra-PD paths of all communication devices PD that constitute the post-topology update network NW prior to fault estimation. For this reason, the topology update process by the topology update function 23 and the intra-PD path generation process are also called "pre-processing."

[0061] The intra-PD path generating unit 31 registers the generated intra-PD paths in the intra-PD path DB 34. The intra-PD path DB 34 stores an end node connection flag in association with each intra-PD path. The end node connection flag is information indicating whether the end node of the corresponding intra-PD path has a PP connection with a node in another communication device PD. If the end node connection flag is "true", it indicates that the end node of the corresponding intra-PD path has a PP connection with a node in another communication device PD. If the end node connection flag is "false", it indicates that the end node of the corresponding intra-PD path does not have a PP connection with a node in another communication device PD.

[0062] Furthermore, the intra-PD path generating unit 31 further generates PD-unit connection information during the intra-PD path generation process. The PD-unit connection information is information that indicates which communication devices PD are connected to each other, on a node PD basis. Specifically, for example, in the connection example shown in FIG. 3 , the PD-unit connection information indicates that nodes PD1 and PD2 are connected. The intra-PD path generating unit 31 registers the generated PD-unit connection information in the PD-unit connection DB 33.

[0063] When an event group is input from the monitoring device 2, the rule determination unit 32 executes a rule determination process. The rule determination process is a process of determining a rule to be applied to the input event group from the rule DB 25. For example, the rule determination unit 32 extracts from the rule DB 25, among the rules stored in the rule DB 25, one or more rules that have at least one event type present in the input event group in the rule condition section. The rule determination unit 32 outputs the extracted rule to the PL route generation unit 35 and the certainty factor calculation unit 37.

[0064] When the rule determination unit 32 extracts a rule, the PL via route generation unit 35 executes a PL via route generation process based on the rule, the PD-based connection DB 33, and the intra-PD route DB 34. The PL via route generation process is a process for generating a PL via route to be used in the certainty factor calculation process in the certainty factor calculation unit 37. The PL via route generation process is executed every time a rule is determined by the rule determination unit 32 (i.e., every time a group of events related to the occurrence of a failure is input from the monitoring device 2). For this reason, the rule determination process by the rule determination unit 32, the PL via route generation process by the PL via route generation unit 35, and the certainty factor calculation process by the certainty factor calculation unit 37, which will be described later, are also referred to as "on-demand processing."

[0065] The PL via route generating unit 35 registers the generated PL via route in the PL via route DB 36. The PL via route DB 36 stores a route creation flag in association with each pair of PL via routes associated with a starting node.

[0066] The route creation flag is information indicating whether all PL via routes starting from the corresponding node have been created. If the route creation flag is "true", it indicates that creation of all PL via routes starting from the corresponding node has been completed. If the route creation flag is "false", it indicates that creation of PL via routes starting from the corresponding node has not been completed.

[0067] When a rule is determined by the rule determination unit 32, the certainty calculation unit 37 searches the intra-PD route DB 34 and the PL via route DB 36 for a route that matches the condition part of the rule for a node that matches the conclusion part of the rule. Based on the search result, the certainty calculation unit 37 calculates a certainty that is an index indicating the likelihood that the node is a faulty node. Based on the result of the certainty calculation process, the certainty calculation unit 37 estimates that the node with the highest certainty is the faulty node. The certainty calculation unit 37 outputs the calculated certainty together with the node type and fault name of the node estimated to be the faulty node as an estimation result to the maintenance operator OP.

[0068] 2. Operation Next, the operation of the fault estimation device according to the embodiment will be described.

[0069] 2.1 Pre-processing First, the pre-processing in the fault estimation device according to the embodiment will be described.

[0070] 2.1.1 Overview FIG. 9 is a flowchart showing an example of pre-processing in the fault estimation device according to the embodiment.

[0071] When the topology of the network NW is updated by the maintenance person OP (start), the topology update function 23 registers the new topology relating to the updated network in the topology DB 22 (S1).

[0072] The intra-PD path generating unit 31 and the PL via path generating unit 35 execute a path DB initialization process (S2). Specifically, the intra-PD path generating unit 31 and the PL via path generating unit 35 respectively initialize the PD unit connection DB 33, the PD intra-path DB 34, and the PL via path DB 36. As a result, the PD unit connection DB 33, the PD intra-path DB 34, and the PL via path DB 36 are in an uncreated state.

[0073] The intra-PD route generation unit 31 executes an intra-PD route generation process based on the topology DB 22 registered in the process of S1 (S3). As a result of the intra-PD route generation process, the intra-PD route generation unit 31 generates PD-unit connection information and intra-PD routes. The generated PD-unit connection information and intra-PD routes are registered in the PD-unit connection DB 33 and the intra-PD route DB 34, respectively.

[0074] When the process of S2 is completed, the pre-processing is completed (end).

[0075] 2.1.2 Intra-PD Path Generation Processing Fig. 10 is a flowchart illustrating an example of an intra-PD path generation processing in the failure estimation device according to the embodiment. The flowchart illustrated in Fig. 10 corresponds to details of the processing in S3 in Fig. 9.

[0076] When the topology DB 22 is updated (started), the intra-PD path generating unit 31 starts loop processing A1 (S10). When starting loop processing A1 in S10, the intra-PD path generating unit 31 sets a variable i to an initial value of 1 and selects the i-th communication device PD from the m communication devices PD included in the updated network NW. The variable i is an integer between 1 and m. The integer m is the number of communication devices PD included in the updated network NW.

[0077] When the i-th communication device PD is selected, the intra-PD path generating unit 31 starts loop processing A2 (S20). When starting loop processing A2 in S20, the intra-PD path generating unit 31 sets a variable j to an initial value of 1 and selects the j-th node from the N nodes belonging to the i-th communication device PD as the end node of the intra-PD path to be generated. The variable j is an integer between 1 and N, inclusive. The integer N is the number of nodes belonging to the i-th communication device PD.

[0078] When the j-th node is selected, the intra-PD path generating unit 31 determines whether or not the j-th node in the i-th communication device PD has a PP connection with a node in another communication device PD (S21).

[0079] When the jth node in the i-th communication device PD establishes a PP connection with a node in another communication device PD (S21; yes), the intra-PD route generation unit 31 registers PD-based connection information in the PD-based connection DB 33, with the communication device PD to which the destination node belongs as the connection destination (S22).

[0080] After the process of S22, the intra-PD path generating unit 31 starts loop process A3 (S30). When starting the process of S30, the intra-PD path generating unit 31 sets a variable k to an initial value of 1 and selects the kth node from among the N nodes belonging to the i-th communication device PD as the start node of the intra-PD path to be generated. The variable k is an integer between 1 and N.

[0081] When the kth node is selected, the PD intra-route generation unit 31 generates an intra-PD route connecting the kth node (starting node) belonging to the ith communication device PD to the jth node (ending node), and registers it in the PD intra-route DB 34 (S31).

[0082] The intra-PD route generating unit 31 updates the end node connection flag associated with the intra-PD route registered in the process of S31 to "true" (S32).

[0083] The intra-PD path generating unit 31 repeats the above-described processes of S31 and S32 while incrementing the variable k by 1 until the variable k reaches the end value N. Then, when the variable k exceeds the end value N, the loop process A3 of S30 ends.

[0084] If the j-th node in the i-th communication device PD does not have a PP connection with a node in another communication device PD (S21; no), the intra-PD path generating unit 31 starts loop processing A4 (S40). At the start of the processing of S40, the intra-PD path generating unit 31 sets a variable k to an initial value of 1 and selects the k-th node from the N nodes belonging to the i-th communication device PD as the start node of the intra-PD path to be generated.

[0085] When the kth node is selected, the PD intra-route generation unit 31 generates an intra-PD route connecting the kth node (starting node) belonging to the ith communication device PD to the jth node (ending node), and registers it in the PD intra-route DB 34 (S41).

[0086] The intra-PD route generating unit 31 updates the end node connection flag associated with the intra-PD route registered in the process of S41 to "false" (S42).

[0087] The intra-PD path generating unit 31 repeats the above-described processes of S41 and S42 while incrementing the variable k by 1 until the variable k reaches the end value N. Then, when the variable k exceeds the end value N, the loop process A4 of S40 ends.

[0088] The intra-PD path generating unit 31 repeats the above-described determination process of (S21; yes), the process of S22, and the loop process A3 of S30, or the determination process of (S21; no), and the loop process A4 of S40, while incrementing the variable j by 1 until the variable j reaches the end value N. Then, when the variable j exceeds the end value N, the loop process A2 of S20 ends.

[0089] The intra-PD path generating unit 31 repeats the above-described loop process A2 of S20 while incrementing the variable i by 1 until the variable i reaches the end value m. Then, when the variable i exceeds the end value m, the loop process A1 of S10 ends.

[0090] When the loop process A1 in S10 ends, the intra-PD path generation process ends (END).

[0091] 2.2 On-demand processing First, the on-demand processing in the failure estimation device according to the embodiment will be described.

[0092] 2.2.1 Overview FIG. 11 is a flowchart showing an example of the on-demand processing in the failure estimation device according to the embodiment.

[0093] When a group of events is input from the monitoring device 2 in response to the occurrence of a fault in the network NW (start), the rule determination unit 32 determines a rule to be applied to fault estimation from the rule DB 25 (S4).

[0094] The PL via route generation unit 35 executes PL via route generation processing based on the rule determined to be applied in the processing of S4 and the PD unit connection DB 33 and the intra-PD route DB 34 generated in the pre-processing (S5). As a result of the PL via route generation processing, the PL via route generation unit 35 generates a PL via route. The generated PL via route is registered in the PL via route DB 36.

[0095] The certainty factor calculation unit 37 executes a certainty factor calculation process based on the PD intra-path DB 34 generated in advance in the process of S3, the rule determined in the process of S4, and the PL via-path DB 36 registered in the process of S5 (S6). The certainty factor calculation unit 37 outputs the fault node and fault name with the highest certainty factor to the maintenance operator OP together with the calculated certainty factor.

[0096] When the process of S6 is completed, the process ends (END).

[0097] 2.2.2 PL Route Generation Processing Fig. 12 is a flowchart illustrating an example of PL route generation processing in the failure estimation device according to the embodiment. The flowchart shown in Fig. 12 corresponds to details of the processing in S5 in Fig. 11.

[0098] When the rule to be applied is determined by the rule determination process (start), the PL route generation unit 35 extracts all communication devices PD in which an event specified in the rule occurs as "event occurrence PD" (S51).

[0099] The PL route generation unit 35 extracts, based on the PD-by-PD connection DB 33 registered in the processing of S22, the communication device PD connected to the event-occurring PD extracted in the processing of S51 as an "adjacent PD" (S52).

[0100] The PL via route generation unit 35 extracts the event occurrence PD extracted in the process of S51 and the set of adjacent PDs extracted in the process of S52 as "target PDs" of the PL via route (S53).

[0101] After the processing of S53, the PL via route generation unit 35 starts loop processing B1 (S60). When starting loop processing B1 of S60, the PL via route generation unit 35 sets a variable i' to an initial value of 1 and selects the i'th target PD from the m' target PDs extracted in the processing of S53. The variable i' is an integer greater than or equal to 1 and less than or equal to m'. The integer m' is the number of target PDs extracted in the processing of S53 and is less than or equal to the integer m.

[0102] When the i'th target PD is selected, the PL via route generation unit 35 extracts nodes that correspond to the failure node type specified in the rule from the nodes belonging to the i'th target PD as "target nodes" of the PL via route (S61).

[0103] After the processing of S61, the PL via path generation unit 35 starts loop processing B2 (S70). When starting loop processing B2 of S70, the PL via path generation unit 35 sets a variable j' to an initial value of 1 and selects the j'th target node from the N' number of target nodes belonging to the i'th target PD. The variable j' is an integer between 1 and N'. The integer N' is the number of target nodes belonging to the i'th target PD and is equal to or less than the integer N.

[0104] When the j'th target node is selected, the PL route generating unit 35 sets the j'th target node as the starting point S of the route (S71).

[0105] The PL via route generation unit 35 refers to the PL via route DB 36 and determines whether or not the creation of all PL via routes starting from the target node set as the starting point S in the processing of S71 has been completed. That is, the PL via route generation unit 35 determines whether or not the route creation flag corresponding to the starting point S is “true” (S72).

[0106] If the route creation flag corresponding to the starting point S is "true" (S72; yes), the process of S73, loop process B3 of S80, and process of S74, which will be described below, are skipped. On the other hand, if the route creation flag corresponding to the starting point S is "false" (S72; no), the process of S73, loop process B3 of S80, and process of S74, which will be described below, are executed without skipping.

[0107] Specifically, if the route creation flag corresponding to the starting point S is "false" (S72; no), the PL via route generation unit 35 refers to the intra-PD route DB 34 and extracts (r x p) intra-PD routes whose starting node is the starting point S and whose corresponding end node connection flag is "true" as intra-PD routes R1 (S73). The integer p is the number of nodes of node type PP belonging to the i'th target PD. The real number r is the proportion of nodes of node type PP belonging to the i'th target PD that are connected to other communication devices PD via PP (0 < r ≦ 1). Note that (r x p) is an integer.

[0108] After the process of S73, the PL via route generation unit 35 starts loop process B3 (S80). When starting loop process B3 of S80, the PL via route generation unit 35 sets a variable k' to an initial value of 1 and selects the k'th intra-PD route R1 from the (r x p) intra-PD routes R1. The variable k' is an integer between 1 and (r x p).

[0109] When the k'th intra-PD route R1 is selected, the PL via route generation unit 35 extracts the node that will be the other end T2 from the PP-to-PP route (T1:T2) whose end node is T1 of the k'th intra-PD route R1 based on the topology DB 22 (S81).

[0110] The PL via route generation unit 35 refers to the PD intra-route DB 34 and extracts N intra-PD routes whose starting node is the node at the other end T2 extracted in the processing of S81 as intra-PD routes R2 (S82).

[0111] After the process of S82, the PL via route generation unit 35 starts loop process B4 (S90). When starting loop process B4 of S90, the PL via route generation unit 35 sets a variable h to an initial value of 1 and selects the h-th intra-PD route R2 from the N intra-PD routes R2. The variable h is an integer between 1 and N.

[0112] When the hth intra-PD route R2 is selected, the PL via route generation unit 35 registers the route combining the intra-PD route R1, the inter-PP route (T1:T2), and the hth intra-PD route R2 as a PL via route in the PL via route DB 36 (S91).

[0113] The PL route generating unit 35 repeats the process of S91 described above while incrementing the variable h by 1 until the variable h reaches the end value N. Then, when the variable h exceeds the end value N, the loop process B4 of S90 ends.

[0114] The PL route generation unit 35 repeats the above-described processing of S81, processing of S82, and loop processing B4 of S90 while incrementing the variable k' by 1 until the variable k' reaches the end value (r × p). Then, when the variable k' exceeds the end value (r × p), the loop processing B3 of S80 ends.

[0115] After the loop process B3 in S80, the PL via route generating unit 35 updates the route creation flag corresponding to the starting point S to "true" (S74).

[0116] The PL route generation unit 35 repeats the above-mentioned process of S71 and the determination process of (S72; yes), or the process of S71, the determination process of (S72; no), the process of S73, the loop process B3 of S80, and the process of S74 while incrementing the variable j' by 1 until the variable j' reaches the end value N'. Then, when the variable j' exceeds the end value N', the loop process B2 of S70 ends.

[0117] The PL route generation unit 35 repeats the above-described process of S61 and the loop process B2 of S70 while incrementing the variable i' by 1 until the variable i' reaches the end value m'. Then, when the variable i' exceeds the end value m', the loop process B1 of S60 ends.

[0118] When the loop process B1 of S60 ends, the PL route generation process ends (END).

[0119] The above-described PL via route generation process may be executed multiple times between two intra-PD route generation processes. In this case, the PL via route stored in the PL via route DB 36 is added without being initialized for each PL via route generation process. Therefore, when a PL via route whose route creation flag is set to "true" in a previously executed PL via route generation process is to be generated again in a later executed PL via route generation process, the PL via route generation process is omitted by the determination process of (S72; yes).

[0120] 2.2.3 Certainty Factor Calculation Process Next, the certainty factor calculation process in the fault estimation device according to the embodiment will be described.

[0121] 7 is applied in the case-by-case processing. In this case, prior to the certainty factor calculation processing, the PL via path generation unit 35 generates a PL via path (EQP>PP: PP<EQP<PD) in which the failure node type EQP of rule α is the target node, and registers it in the PL via path DB 36. Note that all intra-PD paths including the intra-PD path (EQP<PD) of condition IF_1 are generated in the pre-processing before the application of rule α is determined.

[0122] The certainty factor calculation unit 37 first selects a node EQP that corresponds to the fault node type of the rule α from the network NW.

[0123] Next, the certainty factor calculation unit 37 refers to the intra-PD route DB 34 and counts the number X1 of intra-PD routes that match the route (EQP<PD) that has the selected node EQP as the starting node. Also, the certainty factor calculation unit 37 refers to the PL via route DB 36 and counts the number X2 of PL via routes that match the route (EQP>PP: PP<EQP<PD) that has the selected node EQP as the starting node.

[0124] Next, the certainty calculation unit 37 further counts X3, the number of intra-PD routes in which an event matching the event type A of the condition IF_1 occurs at the end node, out of the X1 intra-PD routes. The certainty calculation unit 37 also counts X4, the number of intra-PL routes in which an event matching the event type B of the condition IF_2 occurs at the end node, out of the X2 routes via the PL.

[0125] Then, the certainty calculation unit 37 calculates the ratio (X3+X4) / (X1+X2) as the certainty that a card failure has occurred at the selected node EQP.

[0126] Below, examples 1 and 2 are shown as application examples of the above-described certainty factor calculation process. Examples 1 and 2 correspond to cases where the above-described certainty factor calculation process is applied to communication devices PD1 and PD5 shown in FIG. 13, respectively.

[0127] FIG. 13 is a schematic diagram showing an example of a group of events generated when a failure occurs in the failure estimation device according to the embodiment. The example of FIG. 13 shows a case where events occur in communication devices PD1, PD4, PD5, PD6, PD7, and PD8. The event type of the event occurring in communication device PD5 is A, and the node type of the node from which the event occurred is PD. The event type of the events occurring in each of communication devices PD1, PD4, PD6, PD7, and PD8 is B, and the node type of the node from which the event occurred is PD. Each of communication devices PD1 to PD8 includes one node PD, one node EQP, and six PPs. (Example 1) When applying the above-described certainty calculation process to communication device PD1, node EQP within communication device PD1 is selected.

[0128] In communication device PD1, the number X1 of intra-PD routes that meets the condition IF_1, route EQP<PD, is "1." However, the event type of the event occurring at node PD within communication device PD1 is B, which is different from the event type A of condition IF_1. Therefore, the number X3 is "0."

[0129] Furthermore, for communication device PD1 and communication devices PD2, PD3, and PD5 connected to communication device PD1, the number X2 of PL-routing paths that meet the condition IF_2, EQP > PP: PP < EQP < PD, is "3." However, no event has occurred at node PD in communication device PD2 or node PD in communication device PD3. Furthermore, the event type of the event occurring at node PD in communication device PD5 is A, which is different from the event type B of condition IF_2. Therefore, the number X4 is "0."

[0130] As a result, the certainty factor that a card failure has occurred at node EQP of communication device PD1 is (X3 + X4) / (X1 + X2) = (0 + 0) / (1 + 3) = 0. (Example 2) When the above-described certainty factor calculation process is applied to communication device PD5, node EQP within communication device PD5 is selected.

[0131] In communication device PD5, the number X1 of intra-PD routes that meets the condition IF_1, route EQP<PD, is "1." The event type of the event occurring at node PD within communication device PD5 is A, which meets the event type A of condition IF_1. Therefore, the number X3 is "1."

[0132] Furthermore, for communication device PD5 and communication devices PD1, PD4, PD6, PD7, and PD8 connected to communication device PD5, the number X2 of PL-routed routes that meet the condition IF_2, EQP > PP: PP < EQP < PD, is "5." The event types of events occurring at nodes PD of communication devices PD1, PD4, PD6, PD7, and PD8 are all B, which meets the event type B of condition IF_2. Therefore, the number X4 is "5."

[0133] As a result, the certainty that a card failure has occurred at node EQP of communication equipment PD5 is (X3+X4) / (X1+X2)=(1+5) / (1+5)=1.

[0134] 3. Effects of the Embodiment According to the embodiment, the intra-PD route generation unit 31 generates, for each of the plurality of tree structures G, a plurality of intra-PD routes connecting nodes in the tree structure G in response to an update of the network NW, which is a topology including a plurality of interconnected tree structures G. The rule determination unit 32 determines, in response to the occurrence of an event group, a rule having a condition part and a conclusion part including the node type of the failure node. The PL via route generation unit 35 generates a plurality of PL via routes having a start node matching the node type of the conclusion part and having an end node belonging to another tree structure G directly connected to the tree structure G to which the start node belongs. The certainty calculation unit 37 estimates the failure node by searching the plurality of intra-PD routes and the plurality of PL via routes for a route matching the condition part. This makes it possible to update the intra-PD route DB 34 in response to an update of the topology and to update the PL via route DB 36 in response to the occurrence of an event group. This allows a higher proportion of time to be allocated to failure estimation itself than when all routes are updated in response to an update of the topology.

[0135] Supplementally, the computational complexity of generating all intra-PD routes in the topology is m × N ２ The computational complexity of generating all PL routing paths in the topology can be estimated as r×p×m×N ２ The total computational cost (m × N ２ + r x p x m x N ２ ) are performed at once, there is a risk that the proportion of time that can be devoted to the fault estimation itself will decrease.

[0136] According to the embodiment, the intra-PD path generating unit 31 selectively generates all intra-PD paths in response to topology updates. As a result, the amount of calculation required for pre-processing is reduced to m×N ２Furthermore, in response to the occurrence of an event group, the PL route generation unit 35 selectively generates, from among all PL route routes, a PL route that has as its starting node a node that is suspected of having a fault due to the occurrence of the event group. As a result, the amount of calculation required for processing each time can be estimated as m'×r×p×N×N'. Therefore, the amount of calculation required for processing before the first fault estimation can be estimated as (m×N ２ +m'×r×p×N×N'). Here, m' is extremely small (for example, about 0.24%) compared to m in an environment with a large topology. Therefore, the impact of the path generation process on the failure estimation process can be suppressed.

[0137] Furthermore, the PL via route generation unit 35 initializes the PL via route DB 36 in response to an update of the topology. In other words, the PL via route generation unit 35 maintains the PL via route DB 36 until the topology is updated. This makes it possible to omit the generation of duplicate PL via routes when a group of events is input multiple times before the topology is updated. This makes it possible to further reduce the amount of calculation required for each process compared to the estimated value described above.

[0138] 4. Modifications, etc. Various modifications can be applied to the above-described embodiment.

[0139] In the above-described embodiment, the case where the program for executing the pre-processing and the processing each time is executed by the fault estimation device 3 has been described, but this is not limiting. For example, the program for executing the pre-processing and the processing each time may be executed by computational resources on the cloud.

[0140] The present invention is not limited to the above-described embodiments, and various modifications can be made in the implementation stage without departing from the spirit of the invention. Furthermore, the embodiments may be implemented in appropriate combinations, in which case the combined effects can be obtained. Furthermore, the above-described embodiments include various inventions, and various inventions can be extracted by combining selected elements from the disclosed elements. For example, if the problem can be solved and the desired effect can be obtained even if some elements are deleted from all elements shown in the embodiments, the configuration from which these elements are deleted can be extracted as an invention.

[0141] REFERENCE SIGNS LIST 1... Fault estimation system 2... Monitoring device 3... Fault estimation device 11... Control circuit 12... Communication module 13... User interface 14... Storage 15... Drive 16... Storage medium 21... Fault case DB 22... Topology DB 23... Topology update function 24... Rule generation function 25... Rule DB 26... Fault cause estimation function 31... Intra-PD route generation unit 32... Rule determination unit 33... PD unit connection DB 34... Intra-PD route DB 35... PL via route generation unit 36... PL via route DB 37... Certainty factor calculation unit

Claims

1. A fault estimation device comprising: a first generation unit that generates, for each of a plurality of tree structures in response to an update of a topology including a plurality of tree structures connected to each other, a plurality of first paths connecting nodes in the tree structures; a decision unit that determines a first rule in response to an occurrence of a first event, the first rule having a first condition part and a first conclusion part including a node type of a fault node; a second generation unit that generates a plurality of second paths having a first starting node matching the node type of the first conclusion part and having a first end node belonging to a second tree structure directly connected to a first tree structure to which the first starting node belongs; and an estimation unit that estimates the fault node by searching for a path matching the first condition part from the plurality of first paths and the plurality of second paths.

2. The fault estimation device according to claim 1, wherein the second generation unit initializes the plurality of second paths in response to the update of the topology.

3. The fault estimation device of claim 1, wherein the determination unit determines a second rule having a second condition part and a second conclusion part including a node type of a fault node in response to the occurrence of a second event, and the second generation unit generates a plurality of third paths having a second starting node matching the node type of the second conclusion part and a second end node belonging to a fourth tree structure directly connected to a third tree structure to which the second starting node belongs, when the node type of the second conclusion part is different from the node type of the first conclusion part.

4. The fault estimation device according to claim 3, wherein the second generation unit omits generation of the plurality of third paths when a node type of the second conclusion part matches a node type of the first conclusion part.

5. The fault estimation device according to claim 1, wherein the first condition section includes a route condition and an event type of an event that occurs at an end node of the route condition.

6. The fault estimation device according to claim 5, wherein a tree structure to which a start node of said path condition belongs is different from a tree structure to which an end node of said path condition belongs.

7. A fault estimation method comprising: generating, for each of a plurality of tree structures in response to an update of a topology including a plurality of tree structures connected to each other, a plurality of first paths connecting nodes in the tree structures; determining, in response to an occurrence of a first event, a first rule having a first condition part and a first conclusion part including a node type of a fault node; generating a plurality of second paths having a first starting node matching the node type of the first conclusion part and a first end node belonging to a second tree structure directly connected to the first tree structure to which the first starting node belongs; and estimating the fault node by searching for a path matching the first condition part from the plurality of first paths and the plurality of second paths.

8. A program for causing a computer to function as each unit of the fault estimation device according to any one of claims 1 to 6.

Images