JP5198154B2 - Fault monitoring system, device, monitoring apparatus, and fault monitoring method - Google Patents

Description

  The present invention relates to a fault monitoring system, a device, a monitoring apparatus, and a fault monitoring method, and more particularly to a technique for monitoring the occurrence of a fault in a plurality of devices that can communicate directly or indirectly through a network.

In recent years, consumer devices such as mobile phones and televisions have become multifunctional, and the scale of software installed therein tends to increase year by year. In general, as the size of software increases, the number of potential bugs increases and the possibility of defects occurring after product shipment increases. In order to avoid such a situation, research on software development methodologies such as model-based development and software product line is underway in order to develop large-scale software with high quality and high efficiency.
On the other hand, research on elemental technologies for promptly correcting software defects that occur after product shipment of consumer devices is also in progress. TVs and game consoles with a function for remotely updating software have been commercialized. A system for detecting a failure that has occurred on a device is generally known. For example, there are a failure monitoring system described in Patent Document 1 and a monitoring device for embedded devices described in Patent Document 2.
JP 9-91219 A JP 2004-187196 A

A general failure detection system detects a failure by transmitting failure information from a monitored device to a center server. In this method, the number of communications and the amount of communication data increase as the number of devices to be monitored increases, leading to congestion and an increase in server maintenance costs. Therefore, in Patent Document 1, the urgency of the failure information that has occurred is determined, the failure information having a high degree of urgency is immediately transmitted to the center server, and the failure information having a low degree of urgency is accumulated for a certain period and then transmitted together. About. Further, the above-mentioned Patent Document 2 describes means for reducing the number of communication times by monitoring target devices in cooperation with each other and circulating fault information.
However, with the method described in Patent Document 1, it is possible to reduce the number of communications, but there remains a problem in reducing the amount of communication data. In the method described in Patent Document 2, although the burden on the center server is reduced, the amount of communication data is not reduced, and there is a problem that the cost of a monitoring target device related to collection of failure information is increased.

  In general, as a method for reducing the amount of communication data, use of an error code or means for thinning out and transmitting failure information with low importance can be considered, but with this method, the quality of failure information is reduced. It is difficult to cope with an unexpected failure only by transmitting an error code, and there is a possibility that the failure information that is really necessary cannot be accessed by means of thinning out the failure information.

  A first problem to be solved by the present invention is an increase in the amount of communication data of failure information accompanying an increase in monitored devices. A second problem is a reduction in the quality of failure information due to a reduction in the amount of communication data.

  In order to solve the above-mentioned problems, the present invention creates fault information based on the results of tests performed at the software development stage. For example, fault information is created based on a state transition table used in a development methodology called model-based development. Based on the test result, if failure test has been performed, detailed failure information is created as an unexpected failure, and if it has not been performed, it is easy to promote the test execution as an expected failure If failure information is created and is being implemented, failure information is not created as a failure currently being addressed. By adopting this method, the above problem is solved.

  That is, the present invention includes a device to be monitored, a monitoring device that monitors occurrence of a failure in the device, and an external storage device that is a database that stores failure data of the device, and these devices are connected via a network. A fault monitoring system capable of transmitting and receiving data, a fault monitoring unit for monitoring faults occurring in program modules operating on the device, a state transition monitoring unit for monitoring status transitions of the program modules, When the failure monitoring unit detects the occurrence of a failure, it acquires state transition history information from the state transition monitoring unit, and further acquires test data performed on the program module from the external storage device, and the state transition history information And a failure information creation unit for creating failure information based on the test data, The fault information generated by the serial failure information creation unit, a fault monitoring system comprising a fault information transmission unit that transmits to the monitoring device via the network.

  ADVANTAGE OF THE INVENTION According to this invention, the data amount of the failure information transmitted to a center server from a monitoring object apparatus can be reduced, Therefore The increase in the network traffic accompanying the increase in the monitoring object apparatus can be suppressed. In addition, since the monitoring method is based on the results of tests performed at the software development stage, it is possible to improve the quality of fault information compared to existing methods and to keep the introduction cost of the present invention low. Is possible.

The best mode for carrying out the present invention will be described.
Embodiments of a failure monitoring system, a device, a monitoring apparatus, and a failure monitoring method of the present invention will be described with reference to the drawings.
FIG. 1 is a hardware configuration diagram. This represents a hardware configuration of a general system according to the present invention, and does not limit the hardware configuration. In addition, the present invention describes a system that uses a plurality of terminals via a network, but this drawing shows a single terminal and does not cover all terminals according to the present invention. Absent.

The arithmetic device 101 is a central arithmetic unit that analyzes program data loaded in the main storage device 102 and executes processing. For example, a Pentium (registered trademark) processor manufactured by Intel corresponds to the arithmetic unit 101.
The main storage device 102 is a volatile memory that loads program data recorded in the external storage device 104. For example, a semiconductor memory such as a DRAM corresponds to the main storage device 102.
The communication device 103 is a device for communicating with an external network. For example, a network interface card for connecting to the Internet corresponds to the communication device 103.
The external storage device 104 is a nonvolatile memory that stores program data and the like. For example, a hard disk device corresponds to the external storage device 104. The external storage device 104 may be a device via a network such as a database.

  FIG. 2 is a conceptual diagram of the module. This represents a conceptual configuration of a general module according to the present invention, and does not limit the configuration of the module. The illustrated module inclusion relationship (for example, the inclusion relationship between the monitored device 202 and the monitoring agent 206) is a general example and does not define the inclusion relationship. Further, it does not define whether the illustrated modules are linked via a network or whether they are linked on the same device.

  The network 201 is a communication network characterized in that data can be transmitted and received. For example, the Internet or Ethernet (registered trademark) corresponds to the network 201.

The monitored device 202 is a device monitored by the monitoring device 215 via the network 201. For example, a mobile phone or a home gateway corresponds to the monitored device 202.
The monitored program 203 is a program monitored by the monitoring agent 206. For example, an information home appliance control program that operates on a home gateway corresponds to the monitored program 203.

  The state transition notification unit 204 is a module that notifies the state transition monitoring unit 207 of information regarding the state transition that has occurred on the monitored program 203. The notification method may be a PUSH type (a method for notifying the state transition monitoring unit 207 from the state transition notification unit 204), or a PULL type (a method for inquiring the state transition notification unit 204 from the state transition monitoring unit 207). There may be. For example, the state transition notification unit 204 can be implemented by using an MBean defined by the Java (registered trademark) JMX (Java Management Extensions) specification. A specific example will be described later.

  The failure notification unit 205 is a module that notifies the failure monitoring unit 208 of information related to a failure that has occurred in the monitored program 203. The notification method may be a PUSH type (a method for notifying the failure monitoring unit 208 from the failure notification unit 205) or a PULL type (a method for making an inquiry from the failure monitoring unit 208 to the failure notification unit 205). . For example, the failure notification unit 205 can be implemented by using an MBean defined by the Java JMX specification. A specific example will be described later.

The monitoring agent 206 monitors the state transition of the monitored program 203 and the occurrence of a failure in the monitored program 203, and when a failure occurs in the monitored program 203, the state transition table test data from the database 212 via the network 201. 213, state transition path test data 214, and the like are acquired, the type of fault that has occurred is determined based on the test data, fault information is created based on the type of fault that has occurred, and if necessary, network 201 is a module that transmits the failure information to the monitoring device 215 via the 201, and receives the latest test data from the monitoring device 215 via the network 201, and the database 212 via the network 201 based on the test data. State transition table test data stored in The test data such as 13 and the state transition path test data 214 is a module having a function of updating the.
The monitoring agent 206 may exist on the same machine as the monitored program 203, or may exist on another machine via the network 201. Further, the test data such as the state transition table test data 213 and the state transition path test data 214 can use other test data. In this embodiment, the state transition table test data 213 and the state transition path test data 214 are used as specific examples of test data. Specific examples of these test data will be described later.

As described above, the state transition monitoring unit 207 is a module that monitors the state transition of the monitored program 203 in cooperation with the state transition notification unit 204.
As described above, the fault monitoring unit 208 is a module that monitors faults occurring on the monitored program 203 in cooperation with the fault notification unit 205.
When the failure monitoring unit 208 detects the occurrence of a failure, the failure information creation unit 209 acquires history information of the state transitioned in the past from the state transition monitoring unit 207, and the state transition corresponding to the information via the network 201 This module acquires the table test data 213 and the state transition path test data 214 from the database 212, creates failure information based on the data, and transmits the failure information to the failure information transmission unit 210 if necessary. A procedure for creating failure information and a specific example of failure information will be described later.

The failure information transmission unit 210 is a module that transmits the failure information created by the failure information creation unit 209 to the failure information reception unit 216 of the monitoring device 215 via the network 201.
The test data update unit 211 receives the test data transmitted from the test data transmission unit 217 of the monitoring device 215 via the network 201, and the state transition table test data 213 stored in the database 212 based on the test data. This is a module for updating the state transition path test data 214.

The database 212 is an external storage device 104 that stores state transition table test data 213 and state transition path test data 214.
The state transition table test data 213 is data related to the state transition table test performed at the development stage of the monitored program 203.
The state transition path test data 214 is data related to the state transition path test performed at the development stage of the monitored program 203.
The monitoring program 214 receives failure information from the monitoring agent 206 via the network 201, notifies the failure information to an administrator or the like. If the latest test data exists, the monitoring program 214 sends the test data via the network 201. The module is transmitted to the test data update unit 211.

The monitoring device 215 is a device that communicates with the monitoring agent 206 via the network 201 and monitors the monitored device 202.
The failure information reception unit 216 is a module that receives failure information from the failure information transmission unit 210 via the network 201 and notifies the failure information notification unit 218 of the failure information.
The test data transmission unit 217 is a module that transmits the latest test data performed by the person in charge of development of the monitored program 203 to the test data update unit 211 via the network 201.
The failure information notification unit 218 is a module that notifies the administrator or the like of the failure information received by the failure information reception unit 216 by original means (email transmission, dialog display, etc.).

FIG. 3 is a diagram showing a flowchart relating to creation of failure information.
Step 301 is a step in which the state transition monitoring unit 207 monitors the state transition of the monitored program 203. In this step, the state transition monitoring unit 207 holds a history of state transitions that have occurred on the monitored program 203. Specific state transition monitoring means will be described later.
Step 302 is a step in which the failure monitoring unit 208 monitors a failure that occurs in the monitored program 203. In this step, the failure monitoring unit 208 holds a log of failure information generated on the monitored program 203. Specific fault monitoring means will be described later.
Steps 301 and 302 may be processed before and after, or may be executed in parallel.
Step 303 is a step for checking whether or not a failure has occurred in step 302. If no failure has occurred, the process returns to step 301. If a failure has occurred, go to step 304.

Step 304 is a step in which the failure information creation unit 209 acquires state transition history information from the state transition monitoring unit 207. A specific example of the state transition history information will be described later.
Step 305 is a step of searching the database based on the state transition history information acquired in step 304 by the failure information creation unit 209. In this step, the failure information creation unit 209 searches the database for state transition table test data 213 and state transition path test data 214 corresponding to the state transition history information.

Step 306 is a step of verifying the state transition table test data 213 searched by the failure information creation unit 209 in step 305. The state transition history information acquired in step 304 is compared with the state transition table test data 213, and the current test state is verified.
Step 307 is a step of determining whether or not the current test state is in the process of troubleshooting in the verification process of step 306. If the trouble is being dealt with, it is not necessary to send the trouble information to the monitoring device 215, so the processing is terminated. If the trouble is not being dealt with, the process proceeds to step 308.

  Step 308 is a step of determining whether or not the current test state is an unexecuted state in the verification process of step 306. If not, go to step 315. If not implemented, that is, if implemented, the process proceeds to step 309.

  Step 309 is a step in which the failure information creation unit 209 verifies the state transition path test data 214 searched in step 305. The state transition history information acquired in step 304 is compared with the state transition path test data 214, and the current test state is verified.

  Step 310 is a step of determining whether or not the current test state is a countermeasure against a failure in the verification process of Step 309. If the trouble is being dealt with, it is not necessary to send the trouble information to the monitoring device 215, so the processing is terminated. If the trouble is not being dealt with, the process proceeds to step 311.

Step 311 is a step of determining whether or not the current test state is an executed state in the verification process of Step 309. If it has been implemented, the process proceeds to step 313. If not, the process proceeds to step 312.
Step 312 is a step of creating path fault information when the test state of the state transition path test data 214 has not been performed in Step 311. The path failure information is information relating to the state transition history at the time of failure occurrence. Since the state transition path test has not been performed at the location where the failure has occurred, the amount of information is reduced by creating only the minimum information for performing the state transition path test. Details of the path failure information will be described later.
Step 313 is a step of creating detailed fault information when the test state of the state transition path test data 214 has been performed in step 311. The detailed failure information is information necessary for identifying the cause of the failure, such as a memory dump or an error log. Since the state transition path test has been performed at the failure occurrence location, it is determined that an unexpected failure has occurred, and detailed failure information is created.

  Step 315 is a step of creating simple fault information when the test state of the state transition table test data 213 is not executed in step 308. The simple fault information is information related to cells (rows, columns) of the state transition table corresponding to the fault occurrence location. Since the state transition table test is not performed at the fault occurrence location, the amount of information is reduced by creating only the minimum information for performing the state transition table test. Details of the simple failure information will be described later.

  Steps 314 and 316 are steps of transmitting the failure information created in steps 312, 313, and 315 to the failure information receiving unit 216 of the monitoring device 215. By creating the failure information by the above procedure, only the minimum necessary failure information can be transmitted to the monitoring device 215.

  FIG. 4 is a sequence diagram showing state transition monitoring means and failure monitoring means when the JMX technology is used. JMX technology is a technology that enables the internal state of a program to be monitored from the outside by developing a module for program monitoring called MBean. JMX technology has been introduced as a standard technology from Java version 5 (Java SE 5). FIG. 4 shows the monitoring means of the monitored program 203 when this JMX technology is used. In the figure, to simplify the process flow, the description of JMX-related modules such as MBeanServer is omitted.

First, the monitoring agent 206 sends a state transition monitoring listener registration request 403 to the state transition monitoring MBean 401. If the listener is successfully registered, the state transition monitoring MBean 401 returns a registration success message 404 without causing an error.
Next, the monitoring agent 206 transmits a failure monitoring listener registration request 405 to the failure monitoring MBean 402. If the listener is successfully registered, the failure monitoring MBean 402 returns a registration success message 406 without causing an error.

  Next, the monitored program 203 transmits a state transition message 407 to the state transition monitoring MBean 401 when the internal state of the program changes. Upon receiving the state transition message 407, the state transition monitoring MBean 401 transmits a state transition notification message 408 to the monitoring agent 206 through the state transition monitoring listener. When the monitoring agent 206 receives the state transition notification message 408, the monitoring agent 206 performs processing 409 for updating the state transition history (log). In this way, the monitoring agent 206 holds state transition history information.

  When a failure occurs inside the program, the monitored program 203 transmits a failure occurrence message 410 to the failure monitoring MBean 402. Upon receiving the failure occurrence message 410, the failure monitoring MBean 402 transmits a failure occurrence notification message 411 to the monitoring agent 206 through the failure monitoring listener. When the monitoring agent 206 receives the failure occurrence notification message 411, the monitoring agent 206 performs processing 412 for confirming state transition history information, performs processing 413 for creating failure information, and finally performs processing 414 for transmitting failure information. . The fault creation procedure and the fault information transmission process are as shown in FIG. In this way, an external monitoring program can be created by using JMX technology or the like. However, this is an example of a failure monitoring method, and it is possible to write other programs or to monitor using dedicated hardware.

FIG. 5 is a diagram showing an example of a state transition table referred to in the present invention. This is data representing the state transition of a program that is generally used in a development method called model-based development.
Event A501, event B502, event C503, and event D504 represent the types of events that occur in relation to the program, and state A505, state B506, state C507, state D508, and state E509 represent states in which the program can transition. ing. Also, “x” in the figure indicates that there is no possibility that the event will occur in a certain state, and “/” in the figure does not process even if the event occurs in a certain state and ignores it. "Transition X (X is any alphabet from A to E)" in the figure means that if the event X occurs in a certain state, the transition to another state corresponding to the alphabet X Represents. For example, the table in FIG. 5 indicates that event B502 is not likely to occur when in state A505, indicates that event A501 occurs even when in state B506, and event C503 occurs when in state C507. Then, the program state transitions to state A505. Such a state transition table is generally used in a development method called model-based development.

  FIG. 6 is a table showing an example of numerical data corresponding to the state transition table shown in FIG. In the figure, e1 (601), e2 (602), e3 (603), e4 (604) correspond to event a501, event b502, event c503, and event d504, respectively, and s1 (605), s2 (606), s3 (607), s4 (608), and s5 (609) correspond to state A505, state B506, state C507, state D508, and state E509, respectively. The numbers in the table correspond to the notations shown in the table of FIG. Thus, the amount of information can be reduced by using numerical data corresponding to the state transition table instead of using the state transition table itself as character string data. This is a general example for reducing the amount of information.

FIG. 7 is a table showing an example of the state transition history information expressed using the format shown in FIG. The generation order 701 in the figure is a numerical value indicating the order in which the state transition occurs, and the cell number 702 is a numerical value corresponding to the numerical data shown in FIG. In this example, event B occurs in state E and transitions to state D, event C occurs in state D and transitions to state C, event A occurs in state C and transitions to state B In the state B, the event D is generated and transitions to the state A, and the event B is generated in the state A. In the state transition diagram of FIG. 5, it is described that the event B does not occur in the state A, but in this example, the event B occurs in the state A.
Here, the simple failure information described in the description of FIG. 3 uses numerical data of the cell number 702 corresponding to the state transition immediately before the failure occurs as the failure information. In the example of FIG. 7, the data corresponding to the simple failure information is “2”. However, this is an example of simple failure information for reducing the amount of information, and the content is not limited.

FIG. 8 is a table showing an example of the state transition table test data 213 expressed using the format shown in FIG. The state transition table test is a test for confirming whether each matrix of the state transition table operates normally, and is a test method generally performed in model-based development. For example, in FIG. 5, when an event A occurs in the state A, an operation such as whether or not the transition to the state B is correctly performed is tested.
The cell number 801 in the figure is a numerical value corresponding to the numerical data shown in FIG. 6, and the test state 802 is a numerical value representing the state transition table test execution state corresponding to the cell number 801. The numerical value of the test state 802 indicates that “0” has been executed, “1” indicates that it has not been executed, “2” indicates that it cannot be executed, and “3” indicates that measures are being taken. It represents that.
Here, “impossible to execute” means that the test cannot be performed because an event cannot occur in a certain state (corresponding to “x” in FIG. 5). It means being inside. By using such state transition table test data 213, it is possible to determine what type of failure information should be created and whether failure information should be transmitted to the monitoring device 215. An example of the determination procedure is as shown in FIG.

FIG. 9 is a table showing an example of the state transition path test data 214 expressed using the format shown in FIG. The state transition path test is a test for confirming whether a series of state transitions in the state transition table operates normally, and is a test method generally performed in model-based development. For example, in FIG. 5, when event A occurs in state A, the state transitions correctly to state B, and when event B occurs in state B, transitions to state E correctly. Tests a series of actions such as whether to ignore the event correctly when an error occurs.
A state transition path 901 in the figure is data representing a state transition history corresponding to the numerical data shown in FIG. 6, and a test state 902 is a numerical value representing an implementation status of the state transition path test corresponding to the state transition path 901. . The numerical value of the test state 902 indicates that “0” has been implemented, and “1” indicates that countermeasures are being performed (for example, acceptance has been made in advance). State transition paths that do not appear in the figure all indicate that the test state has not been executed. The reason for not describing unimplemented state transition paths in the drawing is that the data amount becomes enormous if all possible values of the state transition path 901 are covered. By using such state transition path test data 214, it is possible to determine what type of failure information should be created and whether failure information should be transmitted to the monitoring device 215. An example of the determination procedure is as shown in FIG.
Here, the path injury information described in the description of FIG. 3 uses numerical data of the state transition path 901 corresponding to a series of state transitions before the failure occurs as the failure information. In the example of FIG. 9, the data corresponding to the path failure information is “1, 6, 20, 9, 5” or the like. However, this is an example of path failure information for reducing the amount of information, and the content is not limited.

FIG. 10 is a sequence diagram showing a procedure for transmitting failure information described in the description of FIG.
First, the failure information creation unit 209 transmits the failure information transmission request 1001 to the failure information transmission unit 210. Next, the failure information transmitting unit 210 performs processing 1002 for transmitting the failure information to the failure information receiving unit 216 of the monitoring device 215. Next, the failure information reception unit 216 transmits the failure information notification request 1003 received from the failure information transmission unit 210 to the failure information notification unit 218. The failure information notification unit 218 performs the failure information analysis processing 1004, converts the failure information into a form that can be read by humans, and notifies the administrator of the monitored device 202 by means such as mail transmission. Do. Finally, the failure information notification unit 218 transmits a message 1006 indicating that the notification has been successful to the failure information reception unit 216, and the failure information reception unit 216 generates a message 1007 indicating that the failure information has been successfully received. The failure information transmission unit 210 transmits a message 1008 indicating that the failure information has been successfully transmitted to the failure information creation unit 209. Although the failure information is notified to the administrator of the monitored apparatus 202 by the above flow, this describes a general notification method and does not limit the notification method.

  FIG. 11 is a sequence diagram showing a test data update procedure. The administrator who has received the notification of the fault information can test the fault location, distribute the module in which the bug is corrected, and update the test state of the test data.

  First, the administrator 1101 performs processing 1102 for inputting the latest test data related to the monitored program 203 to the monitoring program 214. Next, the monitoring program 214 performs processing 1103 for transmitting a message for updating the latest test data to the monitoring agent 206. Next, the monitoring agent 206 transmits the received latest test data to the database 212 and performs processing 1104 for updating the test data. Finally, the database 212 transmits a message 1105 indicating that the test data has been successfully updated to the monitoring agent 206, and the monitoring agent 206 transmits a message 1106 indicating that the test data has been successfully received to the monitoring program 214. The monitoring program 214 transmits a message 1107 indicating that the test data has been successfully input to the administrator 1101. The test data is updated according to the above flow, but this describes a general update method and does not limit the update method. In particular, it is conceivable that the monitoring agent 206 automatically updates the test state, but here, as a general example, an update process by an administrator is shown.

It is a figure which shows the hardware constitutions of the general system which concerns on this invention. It is a figure which shows the notional structure of the module which concerns on this invention. It is a flowchart which shows an example of the production | generation procedure of failure information. It is a sequence diagram which shows an example of the state monitoring means at the time of utilizing JMX technology. It is a figure which shows an example of the state transition table used by model base development. It is a table | surface which shows an example of the numerical data corresponding to a state transition table. It is a table | surface which shows an example of state transition history data. It is a table | surface which shows an example of state transition table test data. It is a table | surface which shows an example of state transition path test data. It is a sequence diagram which shows an example of the transmission method of failure information. It is a sequence diagram which shows an example of the update method of test data.

Explanation of symbols

101 computing device 102 main storage device 103 communication device 104 external storage device 201 network 202 monitored device 203 monitored program 204 state transition notification unit 205 failure notification unit 206 monitoring agent 207 state transition monitoring , 208 Fault monitoring unit, 209 Fault information policy western part, 210 Fault information transmission part, 211 Test data update part, 212 Database, 213 State transition table test data, 214 State transition path test data, 215 Monitoring device, 216 Fault information reception , 217 Test data transmission unit, 218 Fault information notification unit.

Claims (10)

It consists of a device to be monitored, a monitoring device that monitors the occurrence of a failure in the device, and an external storage device that is a database that stores the failure data of the device, and these devices can send and receive data via a network Fault monitoring system,
A fault monitoring unit that monitors a fault that has occurred in a program module that operates on the device; a state transition monitoring unit that monitors a state transition of the program module; and the state when the fault monitoring unit detects the occurrence of a fault. Failure information for obtaining state transition history information from a transition monitoring unit, further obtaining test data for the program module from the external storage device, and creating failure information based on the state transition history information and the test data A failure monitoring system comprising: a creation unit; and a failure information transmission unit that transmits failure information created by the failure information creation unit to the monitoring device via a network.   The test data is state transition table test data corresponding to a result of a state transition table test performed on the program module, state transition path test data corresponding to a result of a state transition path test, or both. The fault monitoring system according to 1.   When the failure information creation unit determines whether the program module has already passed the state transition table test based on the state transition table test data and the state transition history information, The fault monitoring system according to claim 2, wherein detailed fault information such as a memory dump and a fault log is created, and simple fault information corresponding to the state transition table of the state transition table test data is created when the information does not pass.   The failure information creation unit determines whether the program module has already passed the state transition path test based on the state transition path test data and the state transition history information. The fault monitoring system according to claim 3, wherein detailed fault information is created, and path fault information corresponding to the state transition path of the state transition path test data is created if the detailed fault information is not passed. The failure information creation unit determines whether the program module has passed the state transition table test based on the state transition table test data and the state transition history information. If simple fault information is created and passed, it is determined whether the program module passes the state transition path test based on the state transition path test data and the state transition history information. 5. The fault monitoring system according to claim 4, wherein the path fault information is created if not, and the detailed fault information is created if the path is passed.   When the failure information creation unit transmits the failure information to the monitoring device, the test data corresponding to the state transition history information is stored in the external storage device as a countermeasure, and when the failure recurs, The failure information is not created when the test data corresponding to the state transition history information is being taken, and the failure information is not transmitted to the monitoring device. The fault monitoring system according to any one of the above.   A test data update unit that transmits the latest test data input to the monitoring device by the device administrator or the like and a countermeasure status of the test data to the external storage device and updates the test data stored in the external storage device; The fault monitoring system according to any one of claims 1 to 6. A device comprising a program module, capable of transmitting and receiving data via a network with a monitoring device and an external storage device which is a database for storing device failure data,
A failure monitoring unit that monitors a failure that has occurred in the program module, a state transition monitoring unit that monitors a state transition of the program module, and a state from the state transition monitoring unit when the failure monitoring unit detects the occurrence of a failure. Acquiring a transition history information, further acquiring test data performed on the program module from the external storage device, and generating a failure information based on the state transition history information and the test data; and A device comprising: a failure information transmission unit configured to transmit failure information created by a failure information creation unit to the monitoring apparatus via a network. It consists of a device to be monitored, a monitoring device that monitors the occurrence of a failure in the device, and an external storage device that is a database that stores the failure data of the device, and these devices can send and receive data via a network A method for monitoring faults in a fault monitoring system,
A fault monitoring step for monitoring a fault that has occurred in a program module operating on the device; a state transition monitoring step for monitoring a state transition of the program module; and the state when a fault occurrence is detected by the fault monitoring step. Failure information for acquiring state transition history information by a transition monitoring step, further acquiring test data for the program module from the external storage device, and creating failure information based on the state transition history information and the test data A failure monitoring method comprising: a creation step; and a failure information transmission step of transmitting failure information created in the failure information creation step to the monitoring device via a network. The test data is state transition table test data corresponding to a result of a state transition table test performed on the program module, state transition path test data corresponding to a result of a state transition path test, or both. 9. The fault monitoring method according to 9.

Images