Failure support program, failure support method, and failure support system

The fault support program addresses the challenge of identifying communication destinations in control processing systems with one-to-many relationships by classifying patterns and using relevance tables to estimate the intended communication path, enhancing fault diagnosis accuracy.

JP2025165646APending Publication Date: 2025-11-05FUJITSU LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2024069839
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-04-23
Publication Date
2025-11-05

AI Technical Summary

Technical Problem

Conventional technologies fail to accurately identify communication destinations when a second device has a one-to-many relationship with third devices, making it difficult to determine the intended communication path in control processing systems.

Method used

A fault support program that classifies communication patterns, generates relevance information based on communication logs, and estimates the intended communication destination by analyzing the relevance between communications using a relevance table.

Benefits of technology

Enables accurate identification of the communication destination even when multiple destinations are involved, improving fault diagnosis in control processing systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025165646000001_ABST
    Figure 2025165646000001_ABST
Patent Text Reader

Abstract

To accurately narrow down a communication destination with which a device of a generation source of a failure occurred was going to communicate.SOLUTION: A failure support device 1 uses first information in which a plurality of communication messages transmitted from a first device to a second device are recorded to classify communication patterns for identifying communication, and uses second information in which communication logs between the first device, the second device, and a third device are recorded to generate, for each of the classified communication patterns, association degree information indicating the degree of association between first communication performed between the first device and the second device and second communication performed between the second device and the third device. When a failure occurs in the second device, the failure support device 1 specifies, from among the plurality of classified communication patterns, the communication pattern corresponding to the communication message when the failure occurs, and refers to the association degree information corresponding to the specified communication pattern to estimate the third device of a communication destination that was scheduled to be controlled by the first device of a communication source.SELECTED DRAWING: Figure 2
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a disability support program and the like. [Background technology]

[0002] Conventionally, in an information processing system in which a first device controls a third device via a second device, a technique for outputting information related to a communication error that occurred in communication between the first device and the second device or in communication between the second device and the third device has been disclosed (see, for example, Patent Document 1). In this technique, a control unit of the second device acquires a communication log in which communication messages exchanged between the second device and the third device in response to a control message transmitted from the first device to the second device are recorded, reads control message correspondence information in which identification information of the control messages exchanged between the second device and the third device is stored in association with identification information of the control message transmitted from the first device to the second device, and identifies unsent control messages that were not transmitted based on the read control message correspondence information and the acquired communication log. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-181299 [Patent Document 2] Japanese Patent Application Publication No. 2019-121883 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the conventional technology, the second device and the third device that communicates with the second device have a one-to-one relationship, which poses a problem in that, when the second device and the third device have a one-to-many relationship, it is not possible to identify messages that were not sent by the second device.

[0005] In one aspect, the present invention aims to accurately narrow down the communication destination with which a device that has caused a failure is attempting to communicate, even when there are multiple communication destinations. [Means for solving the problem]

[0006] In one aspect, a fault support program provides fault support when a fault occurs in a control processing system in which a first device controls a third device via a second device using communication messages, and causes a computer to execute the following process: classifying communication patterns that identify communications using first information that records each of a plurality of communication messages sent from the first device to the second device; generating, for each classified communication pattern, relevance information that indicates the relevance between a first communication between the first device and the second device and a second communication between the second device and the third device using second information that records a communication log between the first device, the second device, and the third device; identifying, from the classified communication patterns, a first communication pattern that corresponds to the communication message that occurred when the fault occurred; and referencing the relevance information corresponding to the identified first communication pattern, estimating the third device that was the communication destination and that the first device, the source of the communication, intended to control. [Effects of the Invention]

[0007] According to one embodiment, even if there are multiple communication destinations, it is possible to accurately narrow down the communication destination with which the device at the source of the failure was attempting to communicate. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a disability support system according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a functional configuration of the disability support apparatus according to the embodiment. [Figure 3]FIG. 3 is a diagram illustrating an example of a communication log file according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of an application log file according to the embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of a pattern table according to the embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of the relevance table generation process according to the embodiment. [Figure 7A] FIG. 7A is a diagram (1) illustrating an example of an association degree table according to the embodiment. [Figure 7B] FIG. 7B is a diagram (2) illustrating an example of the relevance table according to the embodiment. [Figure 7C] FIG. 7C is a diagram (3) illustrating an example of the relevance table according to the embodiment. [Figure 8] FIG. 8 is a diagram showing the degree of association between communications. [Figure 9] FIG. 9 is a diagram for explaining how to estimate a communication destination when a failure occurs. [Figure 10] FIG. 10 is a diagram illustrating an example of a flowchart of a pattern table generation process according to the embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of a flowchart of the relevance table generation process according to the embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of a flowchart of the estimation process according to the embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of a computer that executes a disability assistance program. [Figure 14] FIG. 14 is a diagram showing a reference example of a disability support system. [Figure 15] FIG. 15 is a reference diagram showing the flow of communication in a Web system. [Figure 16] FIG. 16 is a diagram showing a reference example of a procedure for generating a relevance table. [Figure 17] FIG. 17 is a diagram showing a reference example of the relevance table. [Figure 18] FIG. 18 is a reference diagram showing the degree of association between communications. [Figure 19] FIG. 19 is a diagram for explaining how to estimate a communication destination when a failure occurs. [Figure 20] FIG. 20 is a diagram illustrating the problem of the disability support system of the reference example. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments of the disability assistance program, disability assistance method, and disability assistance system disclosed in the present application will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the embodiments.

[0010] (Example of a disability support system) First, a reference example of a failure support system 9A will be described, which provides failure support when a failure occurs in a control processing system in which a first device controls a third device via a second device using communication messages. Note that a Web system will be taken as an example of the control processing system, but the present invention is not limited to this.

[0011] Fig. 14 is a diagram showing a reference example of a disability support system. As shown in Fig. 14, a disability support system 9A includes a Web system 5A, a disability support device 1A, and a monitoring device 3A.

[0012] Web system 5A is a target system for which disability support is provided by disability support system 9A. Web system 5A has a browser 51, a FW (FireWall) 52, a Web server a (53), a Web server b (54), a linking server 55, and a data storage server 56. Numbers in parentheses are IP (Internet Protocol) addresses. Note that browser 51 is an example of a first device. Web server a (53) and Web server b (54) are examples of a second device. Linking server 55 and data storage server 56 are examples of a third device.

[0013] The browser 51 uses communication messages to control a third device (for example, a linking server 55 or a data storage server 56) via a second device (for example, a web server a (53) or a web server b (54)).

[0014] The FW 52 routes all communication messages within the Web system 5. The FW 52 records a communication log when a communication message passes through. Each communication log is a log of a first communication between a first device and a second device, or a log of a second communication between a second device and a third device. Each communication log includes, for example, the time the communication occurred, the IP address of the sender, the IP address of the destination, etc.

[0015] Web server a (53) and web server b (54) receive a communication message from browser 51, create a new communication message based on the received communication message, and send the created communication message to the destination server. When web server a (53) and web server b (54) receive a communication message, they record an application log. The application log includes the time the communication occurred, the HTTP method, the URI, and the response code. However, the application log does not record the destination to which the new communication message is sent. Therefore, although web server a (53) and web server b (54) each communicate with multiple servers, it is not possible to determine from the application log which server is the destination.

[0016] The linking server 55 and the data storage server 56 are servers controlled by the browser 51. Note that, although the servers controlled by the browser 51 are referred to as the linking server 55 and the data storage server 56, the linking server 55 and the data storage server 56 are merely examples, and the functions and names of the servers are not limited to these.

[0017] An example of the communication flow of the Web system 5A will now be described with reference to FIG. 15. FIG. 15 is a reference diagram showing the communication flow of the Web system. As shown in FIG. 15, the Web server a (53) includes, for example, a status checking function, a log providing function, and a backup automation function. The Web server b (54) includes, for example, a command execution function and a maintenance function. The browser 51 uses communication messages to check the status of the linking server 55 via the status checking function of the Web server a (53). The browser 51 also uses communication messages to acquire logs stored in the data storage server 56 via the log providing function of the Web server a (53). The Web server a (53) also uses communication messages to automatically perform backups of the data storage server 56 via the backup automation function, for example, at predetermined times or periodically. The browser 51 also uses communication messages to execute commands to the linking server 55 via the command execution function of the Web server b (54), and occasionally executes a command to upload a request body to the data storage server 56. The browser 51 also uses communication messages to back up and store logs for the linked server 55 via the maintenance function of the Web server b (54).

[0018] 14, the monitoring device 3A monitors whether the Web system 5A is operating normally. To this end, the monitoring device 3A periodically collects and stores communication logs of the FW 52. Furthermore, when the monitoring device 3A detects that a failure has occurred, it transmits the communication log at the time of the failure occurrence to the failure support device 1A.

[0019] The failure support device 1A provides failure support for the Web system 5A. The failure support device 1A includes a communication log file 21 and an association table 24A. The communication log file 21 is a file that stores communication logs for a certain period of time from the communication logs accumulated in the monitoring device 3A. The failure support device 1A acquires communication logs for a certain period of time from the monitoring device 3A and stores them in the communication log file 21. The association table 24A is information that stores the association between server communications. That is, the association table 24A is association information that indicates the association between a first communication performed between a first device (browser 51) and a second device (Web server a (53) or Web server b (54)) and a second communication performed between the second device (Web server a (53) or Web server b (54)) and a third device (linking server 55 or data storage server 56). The association may be, for example, the number of communications.

[0020] The disability support device 1A generates an association degree table 24A indicating the association degree between a first communication and a second communication from the communication logs stored in the communication log file 21. For example, the disability support device 1A divides the communication logs in the communication log file 21 at intervals of t seconds. t seconds may be, for example, 1 second or 2 seconds, as long as it is the number of seconds during which related communications are estimated. The disability support device 1A selects one division unit. Based on the time of occurrence of each communication log included in the selected division unit, the disability support device 1A counts the number of communications between the first communication and the second communication that occurred close to each other in time as the association degree, based on the source IP address and destination IP address. The disability support device 1A calculates the association degree for unselected division units. The disability support device 1A then stores the association degree information in the association degree table 24A.

[0021] (Example of how to generate a relevance table) Here, the procedure by which the disability support device 1A generates the relevance table 24A will be described with reference to Fig. 16. Fig. 16 is a diagram showing a reference example of the procedure for generating the relevance table. The right diagram of Fig. 16 shows the communication log file 21. The left diagram of Fig. 16 shows a reference example of a flowchart for generating the relevance table 24A.

[0022] As shown in the left diagram of Fig. 16, the failure support device 1A divides the multiple communication logs stored in the communication log file 21 at intervals of t seconds (S101). Here, t seconds is set to 1 second. Then, the multiple communication logs are divided into t1, t2, and t3.

[0023] Then, for each division unit, the disability support device 1A counts the number of communications between communications that occurred close in time for the divided communication logs as the relevance (S102). Here, in the division unit of t1, as shown by reference symbol t11, there is a communication from browser 51 having "xx.xxxx" as the source IP address to web server b (54) having "bb.bbbb" as the destination IP address. Around the same time as this communication, there is a communication from web server b (54) having "bb.bbbb" as the source IP address to link server 55 having "cc.cccc" as the destination IP address. When communication from browser 51 to web server b (54) occurs, the disability support device 1A estimates that communication from web server b (54) to link server 55 also occurs, and that the relevance is high. Then, the disability support device 1A adds 1 to the number of times between these communications in the relevance table 24A.

[0024] The reverse relationship also holds true between these communications. That is, when communication occurs between Web server b (54) and linked server 55, the disability support device 1A infers that communication between browser 51 and Web server b (54) has occurred, and that the degree of association is high. The disability support device 1A then adds 1 to the number of times these communications occur in the degree of association table 24A.

[0025] Then, the failure support device 1A counts the number of communications between communications for all division units in the same way as in the case of the division unit of t1, and generates the relevance table 24A.

[0026] 17 is a diagram showing a reference example of a relevance table 24A. The relevance table 24A shown in FIG. 17 is generated from the communication log file 21 shown in the right diagram of FIG.

[0027] As shown in FIG. 17, in the relevance table 24A, the vertical axis represents the starting communication, and the horizontal axis represents the communications that occur consecutively after the starting communication. The intersection of the communication represented by the vertical axis and the communication represented by the horizontal axis represents the relevance between the communications, i.e., the number of times the communication occurred (number of communications). Note that "A" represents the browser 51. "B" and "C" represent Web server a (53) and Web server b (54), respectively. "D" and "E" represent the linking server 55 and the data storage server 56, respectively.

[0028] For example, if the starting point of communication is A (browser 51) → C (Web server b (54)), there are 170 instances of communication from C (Web server b (54)) → D (linked server 55) occurring close to the time of communication from A → C. Similarly, if the starting point of communication is C → D, there are 170 instances of communication from A → C occurring close to the time of communication from C → D.

[0029] The relevance between communications that can be seen from the relevance table 24A shown in Figure 17 will be described with reference to Figure 18. Figure 18 is a reference diagram showing the relevance between communications. As shown in Figure 18, if the starting point of communication is A (browser 51) → C (Web server b (54)), there are 170 instances of communication from C (Web server b (54)) → D (linked server 55) around the time of the communication from A → C. Of these 170 instances, 150 were for command execution functions and 20 were for maintenance functions.

[0030] Also, there are two instances of communication between B (Web server a (53)) and E (data storage server 56) close to the time of the communication between A and C. This is because when C (Web server b (54)) executes the command execution function and maintenance function, B (Web server a (53)) executes the backup automation function twice at similar times. The communication between B (Web server a (53)) and E (data storage server 56) is unrelated to the communication that would occur if A were the starting point of the communication. Also, there are three instances of communication between C (Web server b (54)) and E (data storage server 56) close to the time of the communication between A and C.

[0031] Returning to FIG. 14, when the failure support device 1A detects that a failure has occurred in Web server a (53) or Web server b (54), it acquires from the monitoring device 3A the communication log immediately before the failure occurred. The communication log immediately before the failure occurs contains information about the communication that served as the starting point. Therefore, the failure support device 1A references the relevance table 24A to acquire the relevance between communications corresponding to the communication that served as the starting point when the failure occurred. Then, the failure support device 1A estimates that the communication destination of the communication corresponding to the communication that served as the starting point, whose relevance is equal to or greater than a threshold, is the communication destination server.

[0032] Here, the process of estimating the communication destination when a failure occurs in Web server b (54) will be described with reference to Fig. 19. Fig. 19 is a reference diagram for explaining the estimation of the communication destination when a failure occurs. Note that Fig. 19 explains the case where the relevance between communications shown in Fig. 18 is used.

[0033] When the failure support device 1A detects that a failure has occurred in Web server b (54), it acquires the communication log from the monitoring device 3A immediately before the failure occurred. The acquired communication log contains information on the communication from A (browser 51) to C (Web server b (54)), which indicates the communication that is the starting point, so the failure support device 1A detects that communication from A to C has occurred.

[0034] The failure support device 1A refers to the relevance table 24A and obtains the relevance between communications corresponding to the communication that originated when a failure occurred. FIG. 19 shows the relevance between communications originating from A → C. The failure support device 1A then estimates that the communication destination of the communication corresponding to the originating communication, whose relevance is equal to or greater than a threshold, is the communication destination server. Here, the threshold is assumed to be 10, for example. Since the relevance between the communication from A → C and the communication from B (Web server a (53)) → E (data storage server 56) is two times, and the relevance between the communication from A → C and the communication from C (Web server b (54)) → E (data storage server 56) is three times, the failure support device 1A excludes these communications. In other words, the failure support device 1A uses a threshold to exclude communications that are infrequently communicated, such as communications unrelated to the communication originating from A → C, or communications with a low relevance, such as a backup automation function. Then, the disability support device 1A estimates that D (linked server 55) is the communication destination of the communication C (Web server b (54)) → D (linked server 55) with a relevance of 170 times.

[0035] However, the command execution function of the Web server b (54) may receive a communication message from the browser 51 and perform infrequent communication. In such a case, if the disability support device 1A uses a threshold to exclude infrequent communications, there is a problem that it may overlook a necessary communication path. In other words, the disability support device 1A may overlook meaningful communications even if the number of communications is small.

[0036] FIG. 20 is a diagram illustrating a problem with the disability support system of the reference example. As shown in FIG. 20, the disability support device 1A estimates that the communication destination of a communication corresponding to a starting communication whose relevance is equal to or greater than a threshold is the communication destination server. Here, the threshold is assumed to be 10, for example. Then, the disability support device 1A excludes the communication from A → C because the relevance between the communication from A to C and the communication from B (Web server a (53)) → E (data storage server 56) is two times, and the relevance between the communication from A → C and the communication from C (Web server b (54)) → E (data storage server 56) is three times. However, the command execution function of Web server b (54) may occasionally receive a communication message from the browser 51 and execute a command to upload a request body to the data storage server 56. However, since the relevance between the communication from A → C and the communication from C (Web server b (54)) → E (data storage server 56) is three times, the relevance is less than the threshold, and the communication path from C → E is excluded from the communication destinations. That is, the disability support device 1A overlooks the communication destination with which the device (browser 51) where the failure occurred was attempting to communicate.

[0037] Therefore, in the embodiment, a failure support system 9 will be described that can accurately narrow down the communication destination with which the device at the source of the failure was attempting to communicate, even when there are multiple communication destinations. [Example]

[0038] (Configuration of disability support system) 1 is a diagram illustrating an example of the configuration of a disability support system according to an embodiment. As illustrated in FIG. 1, the disability support system 9 includes a Web system 5, a disability support device 1, and a monitoring device 3.

[0039] The Web system 5 is the same system as the Web system 5A shown in the reference example. In other words, the Web system 5 is a system for which the disability support system 9 provides disability support. The Web system 5 has a browser 51, a firewall 52, a Web server a (53), a Web server b (54), a linking server 55, and a data storage server 56. Numbers in parentheses are IP addresses. The browser 51 is an example of a first device. The Web server a (53) and the Web server b (54) are examples of a second device. The linking server 55 and the data storage server 56 are examples of a third device.

[0040] The browser 51 uses communication messages to control a third device (for example, a linking server 55 or a data storage server 56) via a second device (for example, a web server a (53) or a web server b (54)).

[0041] The FW 52 routes all communication messages within the Web system 5. The FW 52 records a communication log when a communication message passes through. Each communication log is a log of a first communication between a first device and a second device, or a log of a second communication between a second device and a third device. Each communication log includes, for example, the time the communication occurred, the IP address of the sender, the IP address of the destination, etc.

[0042] Web server a (53) and web server b (54) receive a communication message from browser 51, create a new communication message based on the received communication message, and send the created communication message to the destination server. When web server a (53) and web server b (54) receive a communication message, they record an application log. The application log includes the time the communication occurred, the HTTP method, the URI, the response code, and so on. However, the application log does not record the destination to which the new communication message is sent. Therefore, although web server a (53) and web server b (54) each communicate with multiple servers, it is not possible to determine from the application log which server is the destination.

[0043] The linking server 55 and the data storage server 56 are servers controlled by the browser 51. Note that, although the servers controlled by the browser 51 are referred to as the linking server 55 and the data storage server 56, the linking server 55 and the data storage server 56 are merely examples, and the functions and names of the servers are not limited to these.

[0044] The monitoring device 3 monitors whether the Web system 5 is operating normally. To this end, the monitoring device 3 periodically collects and stores communication logs of the FW 52. In addition, the monitoring device 3 periodically collects and stores application logs of the Web server a (53) and the Web server b (54). Furthermore, when the monitoring device 3 detects the occurrence of a failure, it transmits the communication log and application log at the time of the failure to the failure support device 1.

[0045] The failure support device 1 provides failure support for the Web system 5. Details of the failure support device 1 will be described later.

[0046] (Functional configuration of disability support device) 2 is a diagram illustrating an example of a functional configuration of a disability support device according to an embodiment. As illustrated in FIG. 2, the disability support device 1 includes a control unit 10 and a storage unit 20.

[0047] The control unit 10 has a log storage unit 11, a log analysis unit 12, and an estimation unit 13. The memory unit 20 has a communication log file 21, an application log file 22, a pattern table 23, and an association degree table 24. The application log file 22 is an example of first information. The communication log file 21 is an example of second information.

[0048] The communication log file 21 is a file that stores communication logs for a certain period of time among the communication logs accumulated in the monitoring device 3. An example of the communication log file 21 will now be described with reference to FIG.

[0049] 3 is a diagram illustrating an example of a communication log file according to an embodiment. As illustrated in FIG. 3, each communication log includes, for example, the time when communication occurred, the IP address of the sender, the IP address of the destination, etc.

[0050] As an example, the communication log indicated by symbol f1 stores the time "Jan 27:17:26:46," the source IP address "xx.xxxx" (browser 51), and the destination IP address "bb.bbbb" (Web server b (54)). The communication log indicated by symbol f2 stores the time "Jan 27:17:26:46," the source IP address "bb.bbbb" (Web server b (54)), and the destination IP address "cc.cccc" (linked server (55)).

[0051] 2, the application log file 22 is a file that stores application logs for a certain period of time among the application logs accumulated in the monitoring device 3. An example of the application log file 22 will now be described with reference to FIG.

[0052] Fig. 4 is a diagram showing an example of an application log file according to an embodiment. As shown in Fig. 4, each application log includes, for example, the time when communication occurred, the HTTP method, the URI, and the response code. The HTTP method indicates the type of request from the browser to the web server. Examples of HTTP methods include "GET," "POST," and "PUT." The URI indicates an identifier for identifying the file to be accessed. The response code indicates the content of the response to the request.

[0053] As an example, the application log indicated by symbol a1 stores the time "27 / Jan / 2023:17:26:45+0900", the HTTP method "GET", the URI " / managers / 33···c7b1", and the response code "200".

[0054] Returning to Fig. 2, the pattern table 23 is information that stores communication patterns classified from a plurality of application logs contained in the application log file 22. The patterns are classified according to the HTTP method, URI, and response code contained in the application log. The pattern table 23 is generated by the log analysis unit 12, which will be described later. An example of the pattern table will be described later.

[0055] The relevance table 24 is information that stores the relevance between server communications for each pattern. The relevance table 24 is relevance information that indicates the relevance between a first communication performed between a first device (browser 51) and a second device (Web server a (53) or Web server b (54)) and a second communication performed between the second device (Web server a (53) or Web server b (54)) and a third device (linked server 55 or data storage server 56). The relevance may be, for example, the number of communications. An example of the relevance table 24 will be described later.

[0056] The log storage unit 11 stores the communication log and the application log in each file. For example, the log storage unit 11 acquires communication logs for a certain period from the monitoring device 3 and stores them in the communication log file 21. The log storage unit 11 acquires application logs for a certain period from the monitoring device 3 and stores them in the application log file 22. The log storage unit 11 is implemented before the failure support system 9 is put into operation.

[0057] The log analysis unit 12 analyzes the communication log and the application log and includes a pattern table generation unit 121 and an association degree table generation unit 122.

[0058] The pattern table generation unit 121 generates a pattern table 23 from the application logs. For example, the pattern table generation unit 121 analyzes multiple application logs included in the application log file 22 and classifies patterns that identify communications. As an example, the pattern table generation unit 121 performs a brute force search on multiple application logs included in the application log file 22. If the HTTP method, URI, and response code are duplicated, the pattern table generation unit 121 classifies the HTTP method, URI, and response code as one pattern. Furthermore, if the HTTP method, URI, and response code are never duplicated after performing a brute force search on multiple application logs included in the application log file 22, the pattern table generation unit 121 determines that the URI has a variable portion and classifies the fixed portion of the URI, the HTTP method, and the response code as one pattern. The pattern table generation unit 121 then stores the HTTP method, URI, and response code classified as a pattern and an identifier that uniquely identifies the pattern in the pattern table 23. That is, the pattern table generation unit 121 assigns a communication pattern to each request indicated by the HTTP method, URI, and response code. An example of the pattern table 23 will now be described with reference to FIG.

[0059] FIG. 5 is a diagram illustrating an example of a pattern table according to an embodiment. As illustrated in FIG. 5, the pattern table 23 stores an HTTP method, a URI, a response code, and a communication pattern in association with each other. In the URI, as indicated by reference symbol p1, the ID following " / task / " is a variable portion. That is, when the HTTP method is "PUT," the URI is " / tasks / {ID}," and the response code is "200," "Pattern 2" is stored as the communication pattern. Also, as indicated by reference symbol p2, the ID following " / files / " is a variable portion. That is, when the HTTP method is "POST," the URI is " / files / {ID}," and the response code is "202," "Pattern 3" is stored as the communication pattern.

[0060] 2, the relevance table generation unit 122 generates, for each classified communication pattern, a relevance table 24 indicating the relevance between the first communication and the second communication, using the communication logs stored in the communication log file 21. The first communication is communication conducted between a first device (browser 51) and a second device (Web server a (53) or Web server b (54)). The second communication is communication conducted between the second device (Web server a (53) or Web server b (54)) and a third device (linking server 55 or data storage server 56).

[0061] For example, the relevance table generation unit 122 refers to the pattern table 23 and classifies each application log included in the application log file 22 into a communication pattern. The relevance table generation unit 122 performs the following process for each application log. The relevance table generation unit 122 selects, from the communication log file 21, communication logs of the first communication and the second communication for t seconds that are close to the time when the application log was generated. t seconds may be, for example, 1 second or 2 seconds, as long as it is a number of seconds that is estimated to be related communications. As an example, the relevance table generation unit 122 may acquire communication logs for t seconds from the time when the application log was generated. As another example, the relevance table generation unit 122 may acquire communication logs for t seconds centered around the time when the application log was generated.

[0062] Then, for the target application log, the relevance table generation unit 122 counts the number of communications between the first communication and the second communication from the communication logs of the selected first communication and the selected second communication as the relevance. That is, the relevance table generation unit 122 adds 1 to the number of communications between the communications in the corresponding position in the relevance table 24 that corresponds to the communication pattern into which the target application log is classified.

[0063] When a failure occurs in the second device, the estimation unit 13 estimates a third device that is a communication destination that the first device, which is the source of the communication, intended to control. For example, when the estimation unit 13 detects that a failure has occurred in Web server a (53) or Web server b (54), it acquires a communication log and an application log from the monitoring device 3 when the failure occurred. The estimation unit 13 identifies a communication pattern corresponding to the application log when the failure occurred from the pattern table 23. Then, the estimation unit 13 references the relevance table 24 corresponding to the identified communication pattern and acquires the relevance (number of communications) between the communication and the first communication obtained from the communication log when the failure occurred. Then, the estimation unit 13 estimates the communication destination of the second communication, whose relevance (number of communications) is equal to or greater than a threshold, as the communication destination server that the browser 51, which is the source of the communication, intended to control. Note that the threshold may be determined for each relevance table 24 corresponding to a communication pattern.

[0064] Here, the process of generating the relevance table 24 will be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of the process of generating the relevance table according to the embodiment. As shown in Fig. 6, the application log file 22 is shown on the left, and the communication log file 21 is shown on the right.

[0065] Under these circumstances, the relevance table generation unit 122 refers to the pattern table 23 and classifies each application log included in the application log file 22 into a communication pattern. Here, the application log indicated by reference symbol a11 is classified into pattern 1 because the HTTP method is "GET," the URI is " / managers / 33edc94d···1," and the response code is "200." The application log indicated by reference symbol a12 is classified into pattern 2 because the HTTP method is "PUT," the URI is " / tasks / ···1," and the response code is "200." The application log indicated by reference symbol a13 is classified into pattern 3 because the HTTP method is "POST," the URI is " / files / ···1," and the response code is "202."

[0066] Then, for each application log, the relevance table generation unit 122 selects, from the communication log file 21, the communication logs of the first communication and the second communication for t seconds that are close to the time when the application log was generated. Here, t seconds is assumed to be 2 seconds. Then, for the application log indicated by reference symbol a11, the relevance table generation unit 122 selects, for example, the communication logs for 2 seconds from the time when the application log was generated, "27 / Jan / 2023:17:26:45+0900." As an example, the communication log indicated by reference symbol f11 indicates the first communication from the browser 51 to the web server b (54). The communication log indicated by reference symbol f12 indicates the second communication from the web server b (54) to the link server 55.

[0067] For the application log indicated by reference symbol a12, the relevance table generation unit 122 selects, for example, two seconds of communication logs from the application log occurrence time "27 / Jan / 2023:17:26:49+0900." As an example, the communication log indicated by reference symbol f21 indicates a first communication from the browser 51 to the web server b (54). The communication log indicated by reference symbol f22 indicates a second communication from the web server b (54) to the link server 55.

[0068] For the application log indicated by reference symbol a13, the relevance table generation unit 122 selects, for example, two seconds of communication logs starting from the application log occurrence time "27 / Jan / 2023:17:27:9+0900." As an example, the communication log indicated by reference symbol f31 indicates a first communication from the browser 51 to the web server b (54). The communication log indicated by reference symbol f32 indicates a second communication from the web server b (54) to the data storage server 56. The communication log indicated by reference symbol f33 indicates a second communication from the web server b (54) to the link server 55. The communication log indicated by reference symbol f34 indicates a second communication from the web server a (53) to the data storage server 56.

[0069] Then, the relevance table generation unit 122 counts the number of communications between the selected first communication and the selected second communication for the target application log as the relevance. That is, the relevance table generation unit 122 adds 1 to the number of communications between the communications in the corresponding location in the relevance table 24 that corresponds to the communication pattern into which the target application log is classified.

[0070] Here, for the application log indicated by reference symbol a11, the relevance table generation unit 122 counts the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the link server 55 as the relevance. That is, the relevance table generation unit 122 adds 1 to the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the link server 55 in the relevance table 24 corresponding to communication pattern "1" into which the application log indicated by reference symbol a11 is classified.

[0071] Furthermore, for the application log indicated by reference symbol a12, the relevance table generation unit 122 counts the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the link server 55 as the relevance. That is, the relevance table generation unit 122 adds 1 to the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the link server 55 in the relevance table 24 corresponding to communication pattern "2" into which the application log indicated by reference symbol a12 is classified.

[0072] Furthermore, for the application log indicated by the symbol a13, the relevance table generation unit 122 counts the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the data storage server 56 as the relevance. In addition, the relevance table generation unit 122 counts the number of communications from the first communication from the browser 51 to the web server b (54) to the second communication from the web server b (54) to the linking server 55 as the relevance.

[0073] Then, the relevance table generation unit 122 increments by 1 the number of communications between the first communication from the browser 51 to the Web server b (54) and the second communication from the Web server b (54) to the data storage server 56 in the relevance table 24 corresponding to the communication pattern "3" into which the application log indicated by the symbol a13 is classified. In addition, the relevance table generation unit 122 increments by 1 the number of communications between the first communication from the browser 51 to the Web server b (54) and the second communication from the Web server b (54) to the linking server 55.

[0074] (Example of a relevance table) 7A to 7C are diagrams showing examples of relevance tables according to an embodiment. Note that A, B, C, D, and E written on the vertical and horizontal axes of the relevance tables shown in Fig. 7A to 7C correspond to browser 51, web server a (53), web server b (54), linking server 55, and data storage server 56, respectively.

[0075] The relevance table 24 shown in Fig. 7A is a relevance table corresponding to pattern 1. For the application log indicated by reference symbol a11 shown in Fig. 6, the number of communications from communication A → C to communication C → D is incremented by 1. That is, the part indicated by reference symbol c1 becomes "20."

[0076] The relevance table 24 shown in Fig. 7B is a relevance table corresponding to pattern 2. For the application log indicated by reference symbol a12 shown in Fig. 6, the number of communications from communication A → C to communication C → D is incremented by 1. That is, the part indicated by reference symbol c2 becomes "147".

[0077] The relevance table 24 shown in FIG. 7C is a relevance table corresponding to pattern 3. For the application log indicated by reference symbol a13 in FIG. 6, the number of communications between the A → C communications and the C → E communications is incremented by 1. That is, the part indicated by reference symbol c3 becomes "3." In addition, the number of communications between the A → C communications and the C → D communications is incremented by 1. That is, the part indicated by reference symbol c4 becomes "3."

[0078] The relevance between communications that can be seen from the relevance table 24 shown in Figures 7A to 7C will be described with reference to Figure 8. Figure 8 is a diagram showing the relevance between communications. Note that Figure 8 explains the relevance between communications when A (browser 51) → C (Web server b (54)) is the starting point of the communication.

[0079] As shown in Figure 8, in pattern 1, if the communication originates from A (browser 51) → C (Web server b (54)), there are 20 instances of communication from C (Web server b (54)) → D (linked server 55) close to the time of the communication from A → C. Also, there is one instance of communication from B (Web server a (53)) → E (data storage server 56) close to the time of the communication from A → C. This is because when C (Web server b (54)) executes the command execution function and maintenance function, B (Web server a (53)) executes the backup automation function once at a similar time. The communication from B (Web server a (53)) → E (data storage server 56) is unrelated to the communication when the communication originates from A → C.

[0080] In pattern 2, if the communication originates from A (browser 51) → C (Web server b (54)), there are 147 instances of communication from C (Web server b (54)) → D (linked server 55) close to the time of the communication from A → C. Also, there is one instance of communication from B (Web server a (53)) → E (data storage server 56) close to the time of the communication from A → C. This is because when C (Web server b (54)) executes the command execution function and maintenance function, B (Web server a (53)) executes the backup automation function once at a similar time. The communication from B (Web server a (53)) → E (data storage server 56) is unrelated to the communication when the communication originates from A → C.

[0081] In pattern 3, if the starting point of communication is A (browser 51) → C (Web server b (54)), there are three instances of communication from C (Web server b (54)) → D (linking server 55) around the time of communication from A → C. In addition, there are three instances of communication from C (Web server b (54)) → E (data storage server 56) around the time of communication from A → C.

[0082] The communication from B (Web server a (53)) to E (data storage server 56) that occurred in patterns 1 and 2 is unrelated to the communication that originated from A to C. Such communication can be excluded using a threshold value that is defined for each pattern.

[0083] (An example of estimation processing) Fig. 9 is a diagram for explaining how to estimate a communication destination when a failure occurs. Note that Fig. 9 explains a case where the relevance between communications shown in Fig. 8 is used.

[0084] When the estimation unit 13 detects that a failure has occurred in Web server b (54), it acquires the communication log and the application log of Web server b (54) at the time of the failure from the monitoring device 3. Here, it is assumed that the application log contains the time when the communication occurred, the HTTP method as "POST," the URI as " / files / ...," and the response code as "202." It is assumed that the communication log contains the time when the communication occurred, the source IP address as A (browser 51), and the destination IP address as C (Web server b (54)). In other words, the communication log is for the case where the communication from A to C is the first communication.

[0085] Then, the estimation unit 13 identifies the communication pattern corresponding to the application log when the failure occurred from the pattern table 23. Here, pattern 3 is identified.

[0086] Then, the estimation unit 13 refers to the relevance table 24 corresponding to the identified communication pattern, and acquires the relevance (number of communications) between the first communication and the communication obtained from the communication log when the failure occurred. As an example, the estimation unit 13 refers to the relevance table 24 corresponding to pattern 3 shown in FIG. 7C, and acquires the second communication when the starting point of the communication is A → C. Here, C (Web server b (54)) → D (linked server 55), which indicates the number of communications as a relevance of "3," and C (Web server b (54)) → E (data storage server 56), which indicates the number of communications as a relevance of "3," are acquired.

[0087] Then, the estimation unit 13 estimates the communication destination between the communications whose number of communications is equal to or greater than the threshold as a communication destination server that the source browser 51 intended to control. As an example, the threshold corresponding to pattern 3 is assumed to be "1." Then, since the number of communications between the communications C (Web server b (54)) → D (linking server 55) and C (Web server b (54)) → E (data storage server 56) is equal to or greater than the threshold and the degree of association is high, they are estimated as communication destination servers. In other words, the estimation unit 13 estimates D (linking server 55) and E (data storage server 56) as communication destination servers that the source browser 51 intended to control.

[0088] In the reference example shown in FIG. 19, the communication from C to E is excluded as a communication with a low frequency. In contrast, the fault support device 1 according to the embodiment does not exclude the communication of pattern 3 as a communication with a low frequency. That is, by using the relevance table 24 for each communication pattern, the fault support device 1 can accurately narrow down the communication destination with which the fault source device (A) was attempting to communicate, even if there are multiple communication destinations. That is, the fault support device 1 can narrow down the communication destination without overlooking it as a meaningful communication even if the communication frequency is low.

[0089] Here, a flowchart of the failure support process executed by the failure support device 1 according to the embodiment will be described with reference to FIGS.

[0090] (Flowchart of pattern table generation process) 10 is a diagram illustrating an example of a flowchart of a pattern table generation process according to an embodiment. As illustrated in FIG. 10, the failure support device 1 accumulates communication logs and application logs of a Web server for a certain period of time from the monitoring device 3 (step S11). For example, the failure support device 1 acquires communication logs for a certain period of time from the monitoring device 3 and stores them in a communication log file 21. The failure support device 1 acquires application logs for a certain period of time from the monitoring device 3 and stores them in an application log file 22.

[0091] The failure support device 1 defines each column of the HTTP method, URI, and response code for the accumulated application log (step S12).

[0092] Then, the disability support device 1 performs a brute force search on the application logs of the Web server to determine the variable part of the URI (step S13). For example, the disability support device 1 performs a brute force search on the application logs of the Web server to select an application log whose HTTP method, URI, and response code never overlap. Then, the disability support device 1 performs a brute force search on the URI of the selected application log to determine the overlapping fixed part and the non-overlapping variable part.

[0093] Then, the disability support device 1 determines whether or not the HTTP method, URI, and response code are duplicated for each application log of the web server (step S14). If it is determined that they are duplicated (step S14; Yes), the disability support device 1 determines that the URI is fixed (step S15).

[0094] Then, the failure support device 1 stores the HTTP method, URI, response code, and uniquely determined communication pattern of the application log whose URI is determined to be fixed in the pattern table 23 (step S16). Note that if the same HTTP method, URI, and response code already exist in the pattern table 23, the failure support device 1 does not store them. Then, the failure support device 1 ends the pattern table generation process.

[0095] On the other hand, if it is determined that there is no overlap (step S14; No), the disability support device 1 determines that the URI includes a variable portion (step S17).

[0096] Then, the disability support device 1 stores the HTTP method of the application log whose URI is determined to include a variable part, the fixed part excluding the variable part of the URI, the response code, and the uniquely determined communication pattern in the pattern table 23 (step S18). Note that if the same HTTP method, fixed part of the URI, and response code already exist in the pattern table 23, the disability support device 1 does not store them. Then, the disability support device 1 ends the pattern table generation process.

[0097] (Flowchart of relevance table generation process) 11 is a diagram illustrating an example of a flowchart of a process for generating a degree-of-relevance table according to an embodiment. As illustrated in FIG. 11, the failure support device 1 selects a web server (step S21). The failure support device 1 reads application logs one by one (step S22). For example, the failure support device 1 reads application logs one by one from the application log file 22.

[0098] The failure support device 1 identifies a communication pattern corresponding to the read application log by using the pattern table 23 (step S23). For example, the failure support device 1 identifies a communication pattern that matches the HTTP method, URI, and response code included in the read application log by using the pattern table 23.

[0099] Then, the disability support device 1 acquires t seconds worth of communication logs at times close to the occurrence time included in the read application log (step S24). Then, the disability support device 1 calculates the degree of association between communications from the acquired communication logs (step S25). For example, the disability support device 1 identifies the communication logs of the first communication and the second communication from the acquired communication logs. Then, the disability support device 1 adds 1 to the number of communications from the first communication to the second communication as the degree of association.

[0100] Then, the fault support device 1 stores the calculated relevance in the relevance table 24 corresponding to the classified communication pattern (step S26). For example, the fault support device 1 updates the number of communications at the intersection of the first communication and the second communication in the relevance table 24 corresponding to the classified communication pattern to the calculated number of communications.

[0101] Then, the disability support device 1 determines whether all the application logs have been read (step S27). If it is determined that all the application logs have not been read (step S27; No), the disability support device 1 proceeds to step S22 to read the next application log.

[0102] On the other hand, if it is determined that all the aprologs have been read (step S27; Yes), the disability support device 1 determines whether all the Web servers have been selected (step S28).If it is determined that all the Web servers have not been selected (step S28; No), the disability support device 1 proceeds to step S21 to select the next Web server.

[0103] On the other hand, if it is determined that all the Web servers have been selected (step S28; Yes), the failure support device 1 ends the relevance table generation process.

[0104] (Flowchart of estimation process) 12 is a diagram showing an example of a flowchart of an estimation process according to an embodiment. As shown in FIG. 12, the failure support device 1 determines whether a failure has occurred in any of the Web servers (step S31). If it is determined that a failure has not occurred in any of the Web servers (step S31; No), the failure support device 1 repeats the determination process until a failure occurs in any of the Web servers.

[0105] On the other hand, if it is determined that a failure has occurred in any of the Web servers (Step S31; Yes), the failure support device 1 acquires the application log and communication log at the time of the failure from the monitoring device 3 (Step S32).Then, the failure support device 1 defines each column of the HTTP method, URI, and response code for the application log of the Web server where the failure has occurred (Step S33).

[0106] The failure support device 1 uses the pattern table 23 to identify a communication pattern corresponding to the application log at the time of the failure occurrence (step S34). For example, the failure support device 1 uses the pattern table 23 to identify a communication pattern that matches the HTTP method, URI, and response code included in the application log at the time of the failure occurrence.

[0107] Then, the failure support device 1 acquires the degree of association (number of communications) between the communications in the communication log at the time of the failure occurrence, using the degree of association table 24 corresponding to the identified communication pattern (step S35). For example, the failure support device 1 refers to the degree of association table 24 corresponding to the identified communication pattern, and acquires the degree of association (number of communications) between the communications and the first communication obtained from the communication log at the time of the failure occurrence.

[0108] Then, the disability support device 1 estimates that the communication destination between the communications whose relevance (number of communications) is equal to or greater than the threshold is the communication destination server (step S36), and the disability support device 1 ends the estimation process.

[0109] [Effects of the Example] According to the above embodiment, the failure support device 1 provides failure support when a failure occurs in a Web system 5 in which a first device controls a third device via a second device using communication messages. The failure support device 1 classifies communication patterns that identify communications using first information that records each of multiple communication messages sent from the first device to the second device. For each classified communication pattern, the failure support device 1 generates an association table 24 that indicates the association between a first communication between the first device and the second device and a second communication between the second device and the third device using second information that records a communication log between the first device, the second device, and the third device. When a failure occurs in the second device, the failure support device 1 identifies a communication pattern corresponding to the communication message that occurred when the failure occurred from among the multiple classified communication patterns. The failure support device 1 references the association table 24 corresponding to the identified communication pattern and estimates the third device that the first device, the source of the communication, intended to control. As a result, even if there are multiple third communication destination devices, the fault support device 1 can accurately narrow down the third communication destination device that the first communication source device that sent the communication message to the second communication destination device that has experienced a fault intended to control.

[0110] Furthermore, according to the above embodiment, the process of generating relevance information in the disability support device 1 selects, for each communication message included in the first information, from the second information, a first communication and a second communication that occurred at a time close to the occurrence time of the communication message, and generates a relevance table 24 that indicates the number of communications from the selected first communication to the selected second communication and corresponds to the communication pattern into which the communication messages are classified. This allows the disability support device 1 to generate a relevance table 24 that corresponds to each communication pattern by using the first information and the second information.

[0111] Furthermore, according to the above embodiment, the estimation process in the failure support device 1 refers to the relevance table 24 corresponding to the identified communication pattern, and estimates a third device of the second communication corresponding to the first communication, which is a second communication corresponding to the first communication obtained from the communication log when the failure occurred and which shows a communication count equal to or greater than a threshold corresponding to the communication pattern, as the third device of the communication destination that the first device plans to control. As a result, the failure support device 1 can accurately narrow down communication destinations that are highly relevant to the communication when the failure occurred by using the threshold corresponding to the communication pattern in the relevance table 24 corresponding to the communication pattern.

[0112] Although the illustrated disability support device 1 has been described as being configured separately from the monitoring device 3, this is not limitative. The disability support device 1 may include the functions of the monitoring device 3, or may be configured as an integrated device with the monitoring device 3.

[0113] Furthermore, the components of the disability support device 1 shown in the figure do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of the disability support device 1 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Furthermore, the storage unit 20 may be connected via a network as an external device to the disability support device 1.

[0114] The various processes described in the above embodiments can be realized by executing a prepared program on a computer such as a personal computer or a workstation. Therefore, an example of a computer that executes a disability support program that realizes the same functions as the disability support device 1 shown in Fig. 2 will be described below. Here, a disability support program that realizes the same functions as the disability support device 1 will be described as an example. Fig. 13 is a diagram showing an example of a computer that executes a disability support program.

[0115] 13, computer 200 includes a CPU (Central Processing Unit) 203 that executes various types of arithmetic processing, an input device 215 that accepts data input from a user, and a display device 209. Computer 200 also includes a drive device 213 that reads programs and the like from a storage medium, and a communication I / F (Interface) 217 ​​that transmits and receives data to and from other computers via a network. Computer 200 also includes a memory 201 that temporarily stores various types of information, and an HDD (Hard Disk Drive) 205. Memory 201, CPU 203, HDD 205, display control unit 207, display device 209, drive device 213, input device 215, and communication I / F 217 are connected via a bus 219.

[0116] The drive device 213 is, for example, a device for the removable disk 211. The HDD 205 stores a failure support program 205a and failure support processing related information 205b. The communication I / F 217 manages the interface between the network and the inside of the device, and controls the input and output of data from other computers. For example, a modem, a LAN adapter, or the like can be used as the communication I / F 217.

[0117] The display device 209 is a display device that displays a cursor, an icon, a toolbox, and data such as documents, images, and function information. The display device 209 can be, for example, a liquid crystal display or an organic EL (Electroluminescence) display.

[0118] CPU 203 reads out fault support program 205a, expands it in memory 201, and executes it as a process. These processes correspond to the respective functional units of fault support device 1. Fault support processing related information 205b includes, for example, information stored in storage unit 20. And, for example, removable disk 211 stores each piece of information such as fault support program 205a.

[0119] It should be noted that the failure support program 205a does not necessarily have to be stored in the HDD 205 from the beginning. For example, the program may be stored in a "portable physical medium" such as a flexible disk (FD), CD-ROM, DVD disk, magneto-optical disk, or IC card that is inserted into the computer 200. The computer 200 may then read and execute the failure support program 205a from these.

[0120] Furthermore, the processing performed by the failure support device 1 described in the above embodiment can be applied to failure support for a system that operates a service that utilizes data. [Explanation of symbols]

[0121] 1. Disability assistance devices 10 Control Unit 11 Log storage section 12 Log analysis section 121 Pattern table generator 122 Association table generation unit 13 Estimation part 20 Memory section 21 Communication log file 22 App Log Files 23 Pattern Table 24 Relevance Table 3 Monitoring device 5. Web System 51 Browser 52FW 53 Web Server a 54 Web Server b 55 Collaboration Server 56 Data storage server 9. Disability Support Systems

Claims

1. A fault support program for providing fault support when a fault occurs in a control processing system in which a first device controls a third device via a second device using a communication message, the program comprising: classifying a communication pattern for identifying communications using first information that records each of a plurality of communication messages transmitted from the first device to the second device; generating, for each of the classified communication patterns, association degree information indicating an association degree between a first communication performed between the first device and the second device and a second communication performed between the second device and the third device, using second information that records a communication log between the first device, the second device, and the third device; When a failure occurs in the second device, a first communication pattern corresponding to a communication message when the failure occurs is identified from the plurality of classified communication patterns; The association degree information corresponding to the identified first communication pattern is referenced, and the third device, which is a communication destination that the first device, which is a communication source, planned to control, is estimated. A disability support program that causes a computer to execute a process.

2. The process of generating the relevance information includes selecting, for each of the communication messages included in the first information, the first communication and the second communication that occurred at a time close to the time of occurrence of the communication message from the second information, and generating the relevance information indicating the number of communications from the selected first communication to the selected second communication, the relevance information corresponding to a communication pattern into which the communication message is classified.

2. The disability support program according to claim 1.

3. The estimation process refers to the relevance information corresponding to the identified first communication pattern, and estimates the third device of the second communication corresponding to the first communication obtained from a communication log when a failure occurs, the second communication corresponding to the first communication showing a communication count equal to or greater than a threshold corresponding to the first communication pattern, as the third device of a communication destination planned to be controlled by the first device.

3. The disability support program according to claim 2.

4. 1. A fault support method for providing fault support when a fault occurs in a control processing system in which a first device controls a third device via a second device using a communication message, comprising: classifying a communication pattern for identifying communications using first information that records each of a plurality of communication messages transmitted from the first device to the second device; generating, for each of the classified communication patterns, association degree information indicating an association degree between a first communication performed between the first device and the second device and a second communication performed between the second device and the third device, using second information that records a communication log between the first device, the second device, and the third device; When a failure occurs in the second device, a first communication pattern corresponding to a communication message when the failure occurs is identified from the plurality of classified communication patterns; The association degree information corresponding to the identified first communication pattern is referenced, and the third device, which is a communication destination that the first device, which is a communication source, planned to control, is estimated. A disability support method characterized in that processing is executed by a computer.

5. a control processing system for a first device to control a third device via a second device using communication messages; a failure support device that provides failure support when a failure occurs in the control processing system, The disability assistance device includes: a classification unit that classifies a communication pattern that identifies a communication using first information that records each of a plurality of communication messages transmitted from the first device to the second device; a generation unit that generates, for each of the communication patterns classified by the classification unit, association degree information indicating an association degree between a first communication performed between the first device and the second device and a second communication performed between the second device and the third device, using second information that records a communication log between the first device, the second device, and the third device; an identification unit that, when a failure occurs in the second device, identifies a first communication pattern corresponding to a communication message when the failure occurs, from the plurality of classified communication patterns; an estimation unit that refers to the association degree information corresponding to the first communication pattern identified by the identification unit and estimates the third device that is a communication destination that the first device that is a communication source is scheduled to control; A disability support system comprising:

Citation Information

Patent Citations

  • Communication error information output program, communication error information output method, and communication error information output device

    JP2008181299A

  • Abnormal cause identification support system and abnormal cause identification support method

    JP2019121883A