JP5370905B2 - Fault diagnosis apparatus and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To quickly and easily reflect a change in a diagnostic model when the change has occurred in a software environment. <P>SOLUTION: A fault diagnostic device records a processing process of software of an image forming apparatus (S300), acquires a log in response to the occurrence of a fault (S302, S304), and creates (S320) and holds a sub cause and effect network (S330). A management center collects the sub cause and effect network of each image forming apparatus periodically (S331-S336), classifies the collected sub cause and effect networks by model, embeds them into existing diagnostic models by model and optimizes the diagnostic model, and presents them to the relevant devices (S360, S361, S370). The image forming apparatus performs diagnosis by applying a received aptitude diagnostic model (S380). <P>COPYRIGHT: (C)2010,JPO&amp;INPIT

Description

  The present invention relates to a failure diagnosis apparatus and a program for realizing failure diagnosis using an electronic computer (computer).

  In recent years, various machines such as office machines such as copiers and printers require high productivity, so that delay due to failure is not allowed, and it is required to quickly detect and solve the failure. . In addition, because there are many components that can be operated at high speed and high accuracy as a means of operation control in other industrial equipment such as automobiles, aviation, robots and semiconductor design equipment, In general, the frequency of failure occurrence is high. In particular, when the usage environment is inferior, even if it is used by a normal method, various abnormalities and failures that are difficult to detect occur, and a great deal of labor is required for the repair. As a countermeasure against these problems, a mechanism for automatically performing a failure diagnosis has been considered (see, for example, Patent Documents 1 to 3). For example, a mechanism for performing automatic diagnosis using a rule-based system (rule type system) is considered. As an example of the rule type system, there is a failure diagnosis system using a Bayesian network.

JP 2003-032253 A Japanese Patent Laid-Open No. 2001-075808 JP 2005-527008 A

  For example, the mechanism described in Patent Document 1 employs a technique for diagnosing faults in a communication network. Specifically, a causal network is configured in response to an alarm from the system, the malfunction of one or more modules that may have led to the fault is associated with the fault, and the fault condition is associated with each malfunction probability. A diagnosis of the alarm is presented in response to the updated probability, with the associated probability associated and updating at least one of the malfunctions based on the alarm and the causal network.

  In the mechanism described in Patent Document 2, a Bayesian network is used as an automatic troubleshooting mechanism for system troubleshooting, and the probability of cause and the probability of actions and question sets are evaluated, and the problem solving probability is the highest. The low cost action is proposed to the user sequentially.

  In the mechanism described in Patent Document 3, a stub start log is acquired at the start of a component and a stub end log is acquired at the end in order to realize runtime monitoring of a component-based software system that operates on one or a plurality of processing devices. By doing so, timing waiting time, shared resource usage, causal relationship, etc. are monitored based on this log.

  An object of the present invention is to provide a mechanism that can quickly or easily reflect a change state in a diagnosis model when a change in the software environment occurs.

The invention according to claim 1, when the recording means for recording the process history of the software for operating the electronic device, the disorder caused by the software processing on the electronic device occurs, the in the previous occurrence of the fault acquisition means for acquiring the software for processing history from the recording means, based on the processing history acquired by the acquisition means, classifying means for classifying the one or more causes modules disorders caused the software processing When a generation means for generating a sub-causal network that associates a probability with each of the classified due module by said classifying means, a sub causal network generated by the generation means, incorporated in the causal network of existing diagnostic model A failure diagnosis apparatus having update means for updating the existing diagnosis model .

According to a second aspect of the present invention, in the first aspect of the present invention, the acquisition unit further outputs , as the processing history of the software, a call stack of the function of the software module that has notified the occurrence of the failure. get the back trace log, generate a call function graph by the acquisition unit extracts the software module that contains the calling function and the call function from backtrace log acquired, graphed in units of call functions and software modules further comprising a calling function graph generator for the generation means may assign software module calls a function graph generated by the function graph generation unit to the nodes of the sub-causal network, the call function of the state of the node Assign each no The to generate the sub-causal network by linking based on the read order of the calling function.

According to a third aspect of the present invention, in the second aspect of the present invention, the updating unit is configured to combine a sub-causal network generated by the sub-causal network generation unit with a causal network of an existing diagnostic model. The causal network of the diagnostic model is searched for the node name and link of the sub causal network generated by the sub causal network generation unit, and when the node of the sub causal network exists in the existing diagnostic model, the addition of the state and the probability The value is updated, and when a node of the sub-causal network does not exist in the existing diagnostic model, a node, a link, and a probability table are added.

According to a fourth aspect of the present invention, in the first aspect, the acquisition unit acquires a process log of a software processing system as the processing history of the software , and the generation unit uses the acquisition unit. The sub-causal network is generated by using the process list in the acquired process log as a cause and generating the failure as a result.

According to a fourth aspect of the present invention, in the first aspect of the present invention, the sub-causal network holding unit that stores the sub-causal network generated by the generation unit, and the sub-causal network holding units of the plurality of electronic devices are further provided. A sub-causal network collection unit that collects the sub-causal network held in the network at a predetermined timing, and the updating unit includes the sub-causal network of each electronic device collected by the sub-causal network collection unit for each model. Classify and incorporate into existing diagnostic models by model.

The invention according to claim 6 is a program for preparing a diagnostic model for failure diagnosis using an electronic computer, and recording means for recording a processing history of software for operating an electronic device in the electronic computer when the when a disorder caused by the aforementioned software processing in the electronic device occurs, an acquisition procedure for acquiring the processing history of the software in the previous occurrence of the failure from the recording means, obtained by the obtaining means based on the processing history, and classification procedure to classify the one or more causes modules disorders caused the software processing, the sub-causal network that associates a probability with each of the classified due module by said classifying means a generating step of generating, a sub causal network generated by the generation means, existing diagnostic model Is a program for executing an update procedure for incorporating the causal network update the existing diagnostic model.

  According to the first aspect of the present invention, when the software environment changes, the change state can be reflected in the diagnostic model quickly or easily. As a result, the diagnostic performance for fault diagnosis of software faults is improved.

  According to the second aspect of the present invention, by using the backtrace log, the causal relationship inside the software resulting in the software failure that has occurred can be reflected quickly or easily in the diagnostic model. As a result, the diagnostic performance for fault diagnosis of software faults is improved.

  According to the third aspect of the present invention, not only the reflection of the failure occurrence in relation to the existing node but also the reflection of the failure occurrence can be achieved by adding a new node. As a result, for example, runtime errors not anticipated by developers during actual operation, or errors due to interference with newly installed software created by external vendors, can be reflected in the diagnostic model quickly and easily. It becomes possible to do.

  According to the invention described in claim 4, by using the process log as a record of the processing process of the software, the causal relationship with not only the specific software but also other plural software activated simultaneously is reflected in the diagnostic model. can do. That is, since a sub-causal network can be generated by using a process list in the process log as a cause and generating a failure as a result, the diagnosis model can be easily and quickly optimized.

  According to the fifth aspect of the present invention, sub-causal networks of a plurality of electronic devices can be collected and integrated into a diagnostic model, so that diagnosis covering fault information individually held by each electronic device is possible. A model can be generated, and diagnostic accuracy is further improved.

  According to the sixth aspect of the present invention, when a change in the software environment occurs, a mechanism for improving the diagnosis performance of the fault diagnosis of the software fault by reflecting the change state in the diagnosis model quickly or easily. Can be realized using an electronic computer.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

<< Configuration Example of Image Forming Apparatus >>
FIG. 1 is a diagram illustrating a configuration example of an image forming apparatus equipped with an embodiment of a failure diagnosis apparatus. Here, FIG. 1 is a functional block diagram focusing on the failure diagnosis function of the image forming apparatus 1.

  The image forming apparatus 1 includes, for example, an image reading unit (scanner unit) that reads an image of a document, and inputs from a personal computer or the like, a copying apparatus function that prints an image corresponding to the document image based on image data read by the image reading unit. A multi-function machine having a printer function for printing out based on the printed data (data representing an image) and a facsimile transmission / reception function capable of printing out a facsimile image, and is configured as a digital printing apparatus. .

  As shown in FIG. 1, the image forming apparatus 1 according to the present embodiment has a failure diagnosis device 3 (failure diagnosis unit) that diagnoses a failure (particularly a software failure) of the image forming apparatus 1 as a function unit related to a failure diagnosis function. And the state information (operation state signal) inside the device when the device is in operation, which is necessary for diagnosing the device such as paper passing time, drive current, device internal temperature and humidity, etc. is automatically used as observation data A sensor unit 4 to be acquired and a failure diagnosis input unit 5 for inputting information necessary for failure diagnosis are provided. The image forming apparatus 1 has various functions via an image forming unit 6 that forms and outputs an image, an image reading unit 7 that reads a document image, and a communication network 406 (network). A communication unit 8 for exchanging information is provided. The failure diagnosis apparatus 3 may be configured to perform processing in cooperation with a management apparatus (for example, a host computer) provided in the management center 401 as necessary.

  In diagnosing software faults, the sensor unit 4 detects abnormalities in the transport system (for example, the occurrence of a jam or a shift in transport timing) caused by the software fault or abnormalities in the image system (for example, line / band defects or white spots). Or the occurrence of a failure or the like, and is used as a preliminary means for outputting a notification of the occurrence of a failure. A failure detection method using the sensor unit 4 is adopted and associated with a mechanism for tracing a progress log of a program until the failure (failure) occurs.

  Here, a failure detected by the sensor unit 4 is defined as an error, which is a level that seriously affects the operation of the image forming apparatus 1, and a warning level that is not affected at this stage but is affected at all. As an example of an error, for example, when a writing error to a disk occurs, a message to that effect is output. As an example of a warning, for example, when a low amount of toner is detected, that effect is output. There is a case. Errors and warnings are issued from the application software such as scan and print running on the image forming apparatus 1 and the OS, and are realized by writing message output codes according to the detection status of the sensor in the application software. doing. Further, it is realized by a failure detection notification function described in advance in the OS kernel.

  The image forming unit 6 outputs an image read by the image reading unit 7 or an image instructed to print from various information devices via the communication unit 8 on a predetermined printing paper. The communication unit 8 is also used by the communication unit 8 to acquire the latest diagnostic model from a management device provided in the management center 401 via the communication unit 8.

  The failure diagnosis device 3 is obtained from a diagnosis information generation unit 3A and a diagnosis information generation unit 3A that generate information necessary for performing a failure diagnosis of a software failure that has occurred in the image forming apparatus 1 based on each acquired information. A failure diagnosis unit 3B that performs failure diagnosis based on the information is provided.

<Fault diagnosis device>
FIG. 2 is a block diagram illustrating an embodiment of the failure diagnosis apparatus 3. The failure diagnosis apparatus 3 performs software processing when an error or warning due to a software failure occurs in a diagnosis target apparatus (image forming apparatus 1 in the previous example) configured to perform various processes by software processing. The failure diagnosis is performed with reference to the history (log) of the system.

  For example, the diagnosis information generation unit 3A of the failure diagnosis apparatus 3 includes an operation state information acquisition unit 140 that acquires observation data acquired by the sensor unit 4 and various other information necessary for failure diagnosis, and a state of the failure that has occurred. A failure information acquisition unit 152 that acquires failure information obtained by user input according to the instructions on the screen presented by the failure diagnosis input unit 5, and an additional operation that acquires failure information in different operating conditions depending on the user operation An information acquisition unit 154 and a diagnostic information collection unit 160 (feature amount extraction unit) are provided.

  The operation state information acquisition unit 140 monitors the usage status of the image forming apparatus 1 and the component state information acquisition unit 142 that acquires component information indicating the operation state of each component acquired from the sensor unit 4 as observation data information. The history information acquisition management unit 143 manages the monitoring result of the usage status of the image forming apparatus 1 as history information by registering and holding the monitoring result in a nonvolatile storage medium.

  Furthermore, the operation state information acquisition unit 140 determines ambient environment conditions that affect the state of components such as temperature and humidity based on information detected by the operation temperature detection unit 84 and the operation humidity detection unit 86 constituting the sensor unit 4. Based on the information detected by the environmental information acquisition unit 144 acquired as environmental information and the consumable material detection unit (the paper information collection unit 88, the colorant remaining amount detection unit 89, etc.), It has a consumable material information acquisition unit 145 that acquires information on consumable materials used by the apparatus such as the color type, type, and remaining amount of the colorant, and a specification information acquisition unit 146 that acquires specification information of the image forming apparatus 1.

  The diagnostic information collecting unit 160 is based on the operation state signal indicating the operation state while the drive member of the transport system acquired by the component state information acquisition unit 142 is operating for a predetermined period, and the feature amount of the operation state signal Ask for. Further, the diagnostic information collection unit 160 acquires not only the component state information acquisition unit 142 but also information from the history information acquisition management unit 143, the environment information acquisition unit 144, the consumable material information acquisition unit 145, or the specification information acquisition unit 146. Then, the feature amount of the acquired information is also obtained. The diagnostic information collection unit 160 has a function of an operation state signal receiving unit that receives an operation state signal from the component state information acquisition unit 142 and other information from the history information acquisition management unit 143.

  The diagnostic information collection unit 160 generates an abnormality in the conveyance system (for example, occurrence of a jam or a deviation in conveyance timing) or an abnormality in the image system (for example, a line / band defect, white spot, black spot color point, etc.) due to a software failure. The observation data detected by the sensor unit 4 is monitored, and an error or warning is output when it is outside the normal range with respect to a predetermined threshold.

  Further, the diagnostic information generation unit 3A has a log recording unit 168 (processing process) such as a register for recording a log (processing process) of software processing as a characteristic functional element for diagnosing a fault caused by a software fault. An example of a recording unit).

The failure diagnosing unit 3B of the failure diagnosing device 3 determines to store a reference feature amount and a failure diagnosis condition (such as a failure diagnosis model) serving as a determination index at the time of failure diagnosis in a predetermined storage medium (preferably a nonvolatile semiconductor memory). Index storage unit 230 , failure probability inference unit 260 (which calculates the probability of failure cause based on information obtained from each acquisition unit (operation state information acquisition unit 140, failure information acquisition unit 152, additional operation information acquisition unit 154) A diagnosis execution unit), or a notification unit 270 for notifying the customer of a failure determination result and inspection contents. The failure probability inference unit 260 includes a failure determination unit 262 that performs failure candidate extraction, failure determination, and failure prediction, and an inference engine 264 that infers failure probabilities used in failure determination and failure prediction of the failure determination unit 262.

  Further, the failure diagnosis unit 3B includes a diagnosis condition control unit 460 (update control unit) that performs a failure diagnosis condition optimization process as a characteristic functional element for diagnosing a failure caused by a software failure. Yes. Regardless of whether a fault diagnosis condition such as a fault diagnosis model is generated and prepared by the image forming apparatus 1 itself or generated on the management center 401 side and sent to the image forming apparatus 1, the diagnostic condition control unit 460 generates a software fault. When a failure due to a failure occurs, a software log is acquired using an error or warning as a trigger, a sub-causal network is generated based on this software log, and the diagnostic model is updated by incorporating this sub-causal network into an existing diagnostic model. By doing so, it is preferable to improve the diagnostic performance of a failure caused by a software failure. Each functional unit constituting the diagnostic condition control unit 460 will be described in detail later.

  Although not shown, in addition to the storage medium, the determination index storage unit 230 includes a writing control unit for writing the reference feature quantity in the storage medium, and a read control for reading the stored reference feature quantity from the storage medium. Parts are provided. The storage medium has a function of a history storage unit that holds history information of various operation state signals acquired by the diagnostic information collection unit 160 in the image forming apparatus 1.

  As the reference feature amount, for example, a mechanism member (including a drive member such as a motor or a solenoid) constituting the drive mechanism unit or an electric member (drive signal generation unit 150 or drive circuit) that drives the mechanism member operates normally. In the normal state, the feature amount (for example, information for specifying the distribution state) acquired by the diagnostic information collection unit 160 is used. Alternatively, instead of the feature amount obtained by the diagnostic information collection unit 160, an operating current or a rated value of vibration of the stepping motor or the like in the image forming apparatus 1 may be used. In addition, when a failure is detected, a feature amount (for example, a distribution state is specified) acquired by the diagnostic information collection unit 160 when each component member fails as a reference feature amount for determining the failure location or failure state. Information). The reference feature amount relating to the failure state stored in the storage medium is used as a diagnosis model of the image forming apparatus 1. For example, each member of the apparatus is forcibly set to the failure state and detected by the diagnosis information collecting unit 160. The information acquired based on the maintenance information collected in the management center 401 or the like may be used.

  Note that each unit (diagnosis information generation unit 3A and failure diagnosis unit 3B) constituting the failure diagnosis apparatus 3 is not limited to a form in which they are mounted on one image forming apparatus 1, but a part of functional units constituting them or The configuration (so-called system configuration) may be adopted in which the entirety is mounted on an apparatus different from the image forming apparatus 1. For example, the diagnostic information collection unit 160 is removed from the failure diagnosis device 3 on the image forming apparatus 1 side, a diagnostic information acquisition unit is arranged on the management center 401 side, and information acquired by the sensor unit 4 is used as diagnostic information on the management center 401 side. The diagnostic model may be prepared by sending it to the collection unit 160 and specifying the feature amount on the management center 401 side. In this case, it is based on generating a common diagnostic model not only from the device but also from a plurality of pieces of information of the same type of device, and if necessary, the common diagnostic model is further based on information unique to the device. It may be modified and used as a diagnostic model for the device.

  The failure determination unit 262 compares the diagnosis model (including the reference feature amount acquired by the own device) stored in the storage medium with the actual feature amount that is the feature amount obtained by the diagnosis information collection unit 160 at the time of failure diagnosis. As a result, a diagnosis process relating to the failure such as whether or not a failure has occurred in the block to be diagnosed and the possibility of a failure occurring in the future is performed.

For example, the failure probability reasoning unit 260 is connected to a management center 401 (also referred to as a data center) that collects failure information and updates a diagnostic model for each image forming apparatus 1, and is stored in a database DB disposed in the management center 401. performed to register failure information and diagnostic model, the failure or accept the selection and provision of diagnostic model suitable for the image forming apparatus 1 of the diagnostic object diagnosing from various diagnostic models registered in the database DB .

  For example, the failure probability reasoning unit 260 uses the image quality using the state information of the components constituting the image forming apparatus 1, the history information of the apparatus, the surrounding environment information where the apparatus is installed, and the follow-up test result information obtained by user operation. The inference engine 264 infers the failure probability of the location that causes the defect, and the failure determination unit 262 extracts failure location candidates based on the failure probability calculated by the inference engine 264.

  The failure determination unit 262 has a function of a failure candidate extraction unit that narrows down failure candidates using the inference engine 264. The failure determination unit 262 narrows down failure candidates, failure determination results (the presence or absence of failure, failure location, failure content), failure The notification unit 270 is notified of the prediction result (presence / absence of possibility of failure, failure location, failure content), inspection content, acquired operation state signal, and the like.

  Here, when the automatic determination process is performed, if failure point candidates cannot be narrowed down, the inference engine 264 waits for input of the additional test result information obtained under different operating conditions obtained by the user operation. The failure probability is recalculated, and a more appropriate failure location is extracted based on the failure probability acquired under each operation condition.

  The notifying unit 270, for example, a customer (operator or owner of the image forming apparatus 1), a customer engineer who performs maintenance (maintenance, maintenance, management) of the image forming apparatus 1 based on the failure determination result received from the failure determining unit 262. Alternatively, a notification is sent to a customer engineer or customer such as the management center 401 that manages the image forming apparatus 1.

  For example, when directly informing the customer, the image forming apparatus 1 is informed of an alarm such as a display panel or a speaker. The customer sees or listens to it and informs the service center of the failure location and the content of the failure. In addition, when directly informing the customer engineer who maintains the image forming apparatus 1, a failure occurs using a public telephone line, a PDA (Personal Digital Assistant), a mobile phone, or a mobile terminal such as a PHS (Personal Handy-phone System). Contact us. Further, the failure location and failure content data may be sent to a terminal owned by the customer engineer.

  Further, when notifying the management center 401 or the like that manages the image forming apparatus 1, a public telephone line or a portable terminal may be used as in the case of directly informing a customer engineer. Moreover, you may make it contact using the internet. In these cases as well, failure location and failure content data may be sent to the terminal of the management center 401.

  By the way, as described above, the failure diagnosis device 3 is normally used before a failure occurs as its diagnosis architecture when performing failure diagnosis that automatically identifies a failure portion of a mechanical system (paper transport system) or an image defect system. Time data is acquired, and observation data (collectively referred to as actual data) such as the operating device status and environmental conditions is acquired, and the failure probability calculated by the inference engine using these information Diagnose with reference to also. The failure diagnosis referred to in this embodiment may include not only determination of the presence / absence of a failure, but also prediction diagnosis for predicting the occurrence of a future failure.

  Functional parts related to failure diagnosis, such as the inference engine and failure probability inference unit 260 and diagnosis condition control unit 460 that perform failure diagnosis, are not limited to the configuration built in the main body of the image forming apparatus 1, but the server side, for example, image formation You may provide in the management center 401 (it is also called a data center) connected with the apparatus 1 by the network. In this case, normal data and actual data are sent to the management center 401 via the network, and the management center 401 performs failure diagnosis, confirmation processing, and related information presentation.

  For example, without specifying the failure location and the failure content on the image forming apparatus 1 side, the management center 401 is notified of the content of the inspection of the failure diagnosis performed by the failure probability inference unit 260 and the operation state signal used there. On the management center 401 side, narrowing down of failure candidates or identification of failure locations and failure contents may be performed. Alternatively, only the inference engine may be placed in the management center 401, and the failure probability may be calculated in the management center 401.

  With respect to the diagnosis result, for example, a form that a customer engineer (CE; Customers Engineer) confirms at the management center 401 may be employed. In the form of diagnosis at the management center 401, the diagnosis result by the failure probability inference unit 260 is used as the image forming apparatus. 1, the image forming apparatus 1 side may take a form that is confirmed by a customer engineer or customer (customer / user).

  Here, in this embodiment, a Bayesian network is used as an inference engine for calculating a failure probability. Fault diagnosis using a Bayesian network is an optimization approach that estimates the distribution using a graph structure (called a Bayesian network or a causal network) by probabilistically capturing the dependency between nodes (variables).

  For example, when a failure diagnosis of the image forming apparatus 1 is performed based on this diagnosis system, a causal network using a replacement part unit as a failure cause node based on failure cases and know-how according to the type and optional configuration of the image forming apparatus 1 That builds a diagnostic model that sets the probability value in the conditional probability table based on trouble information in the market, and records a log of the sensor unit 4 and software processing when a failure occurs Collect observable evidence information such as the recording unit 168, select a diagnosis model corresponding to the corresponding device configuration, input the evidence information, and estimate the failure occurrence probability of each failure cause node to perform failure diagnosis Do.

  Similarly, for fault diagnosis for software faults, errors and warnings coded in advance by developers, messages output by OS (Operating Systems), etc. are used as evidence information, and causal networks are created from software component configurations and call relationships, and probability values are set. Build the set diagnostic model and perform software fault diagnosis.

<Fault diagnosis device: computer configuration>
FIG. 3 is a block diagram illustrating another configuration example of the failure diagnosis apparatus 3. Here, a more realistic hardware configuration is shown that is constructed from a microprocessor or the like that executes software for fault diagnosis using an electronic computer such as a personal computer.

  A program suitable for realizing failure diagnosis processing to which a Bayesian network method described later is applied by software using an electronic computer (computer) or a computer-readable storage medium storing the program is extracted as an invention.

  Needless to say, the failure diagnosis device 3 and the failure probability inference unit 260 are configured by a combination of dedicated hardware that functions as each function unit shown in FIG. By adopting a mechanism for executing processing by software, the processing procedure and the like can be easily changed without changing hardware.

  When a computer performs a fault diagnosis function using a series of Bayesian network processing by software, as in the case of general information processing using an electronic computer, a magnetic disk (including a flexible disk FD), an optical disk (Including CD-ROM (compact disc-read only memory), DVD (digital versatile disc)), magneto-optical disc (including MD (mini disc)), semiconductor media, package media (portable storage media) ) Or a program constituting the software is installed in the electronic computer via a wired or wireless communication network. The software is not limited to being provided as a batch program file, but may be provided as an individual software module according to the hardware configuration of a system configured by a computer. For example, it may be provided as add-in software incorporated in existing copying apparatus control software or printer control software (printer driver).

  In the case where the failure diagnosis apparatus 3 is incorporated in the image forming apparatus 1 having a copying function, the electronic computer shown in FIG. 3 includes, for example, a processing program for a copying application, a printer application, a facsimile (FAX) application, or other applications. For example, software similar to that in a conventional image forming apparatus (multifunction machine) is incorporated. A control program for transmitting and receiving data to and from the outside via the network 9 is also incorporated.

  For example, the computer system 900 constituting the failure diagnosis apparatus 3 includes a controller unit 901, a hard disk device (HDD), a flexible disk (FD) drive, a CD-ROM (Compact Disk ROM) drive, a semiconductor memory controller, and the like. And a recording / reading control unit 902 for reading and recording data from the storage medium.

  The controller unit 901 includes a CPU (Central Processing Unit) 912, a ROM (Read Only Memory) 913 which is a read-only storage unit, and a RAM (Random Access) which can be written and read at any time and is an example of a volatile storage unit. Memory) 915 and RAM (described as NVRAM) 916 which is an example of a nonvolatile storage unit. The NVRAM 916 stores failure probability information of each part weighted by, for example, usage time, frequency, number of copies / prints, and the like.

  The “volatile storage unit” means a storage unit in a form in which the stored contents are lost when the power of the failure diagnosis apparatus 3 is turned off. On the other hand, the “non-volatile storage unit” means a storage unit in a form that keeps stored contents even when the main power supply of the failure diagnosis apparatus 3 is turned off. Any memory device can be used as long as it can keep the stored contents, and the semiconductor memory device itself is not limited to a nonvolatile memory device, but by providing a backup power source, the volatile memory device is made to be “nonvolatile”. It may be configured. Further, the present invention is not limited to a semiconductor memory element, and may be configured using a medium such as a magnetic disk or an optical disk.

  The computer system 900 also includes an instruction input unit 903 having a keyboard, a mouse, and the like as a function unit that forms a customer interface, and a display output unit 904 that presents predetermined information such as a guidance screen and a processing result during operation to the customer. And an interface unit 909 (IF unit) that performs an interface function with each functional unit.

  When the failure diagnosis device 3 is incorporated in and integrated with the image forming apparatus 1 (particularly referred to as a multifunction device) having a copying function or a facsimile function, an image reading unit 905 (scanner unit) that reads an image to be processed, and printing An image processing unit 962 that generates output data, an image forming unit 906 that includes a print engine 964 that outputs processed images to a predetermined output medium (for example, printing paper), and a FAX unit 907 that processes facsimile data are also provided. Provided.

  Examples of the interface unit 909 include a system bus 991 that is a transfer path of processing data (including image data) and control data, a scanner IF unit 995 that functions as an interface with the image reading unit 905, an image forming unit 906, and the like. It has a printer IF unit 996 that functions as an interface with other printers, and a communication IF unit 999 that mediates transfer of communication data with the network 9 such as the Internet.

  The display device 904 includes, for example, a display control unit 942 and a display unit 944 made up of a CRT (Cathode Ray Tube) or LCD (Liquid Crystal Display). For example, the display control unit 942 displays guidance information, the entire image captured by the image reading unit 905, and the like on the display unit 944. It is also used as a display device for notifying customers of failure determination results and inspection details. By using the display unit 944 having the touch panel 932 on the display surface, the instruction input unit 903 for inputting predetermined information with a fingertip, a pen, or the like may be configured.

  Instead of performing all processing of each functional part of the failure diagnosis apparatus 3 by software, a processing circuit 908 that performs part of these functional parts by dedicated hardware may be provided. Although the mechanism performed by software can flexibly cope with parallel processing and continuous processing, the processing time becomes longer as the processing becomes complicated, so that a reduction in processing speed becomes a problem. On the other hand, an accelerator system that achieves high speed is constructed by performing the processing using a hardware processing circuit. In the accelerator system, even if the processing is complicated, a reduction in processing speed is prevented, and high throughput can be obtained.

  In the case of the failure diagnosis apparatus 3 of the present embodiment applied to the image forming apparatus 1, the processing circuit 908 includes observation data information such as paper passage time, drive current, vibration, operation sound, or light quantity, temperature, Data acquisition function unit 908a of the sensor system for acquiring environmental information such as humidity (corresponding to the operation state information acquisition unit 140 in FIG. 2), and a software data acquisition function unit 908b such as a register for recording a log of software processing ( This corresponds to the log recording unit 168 in FIG. The software data acquisition function unit 908b may be configured to be realized by the RAM 915. Although not shown, it goes without saying that some or all of the functional units constituting the diagnostic condition control unit 460 may be configured in hardware.

<Failure diagnosis processing: Software defect diagnosis model>
FIG. 4 is a Bayesian network model diagram illustrating a configuration example of a Bayesian network used in the failure diagnosis of the software failure in the failure probability inference unit 260. Here, FIG. 4 is a more specific configuration example of the Bayesian network, and shows a configuration example of a Bayesian network diagnosis model in the case of performing a failure diagnosis that identifies a fault location of a software defect system.

  As the failure diagnosis method of the present embodiment, each of the diagnosis target devices acquires an operation state signal indicating an operation state while operating under different operation conditions, and each of the acquired operation state signals is used as a device. The cause of the failure is modeled and analyzed, and the failure diagnosis is performed for each component member constituting the diagnosis target device. "Modeling and analyzing causes that cause device failures" means analyzing causes of failures such as the location of failure and details of failures by modeling the causes that cause device failures using probability. Means. Any modeling method may be used as long as it uses a probability. For example, an actual measurement value indicating the state of the device acquired from the device, or a feature amount extracted from the actual measurement value (collectively, both variables) There is a technique to model the dependency relationship between the two. A specific example is a Bayesian network model.

  A Bayesian network is a directed acyclic graph that represents a causal relationship between variables. When a parent is given, a conditional probability distribution is associated with the variable. Bayesian networks model problem areas using probability theory. Each node (variable) has a set of mutually exclusive states. In each node, a probability (conditional probability table) that a result is generated from a cause is set in advance. A major feature of Bayesian networks is that it is possible to infer probabilities from information that can be directly observed (or obtained), such as the presence or absence of a failure, and to calculate the probability of failure (whether it is a failure) or not. It is in.

  In the case of fault diagnosis for software faults, the same concept should be applied. A diagnostic model in which a causal network is created from software component configurations and call relationships and a probability value is set is constructed using error warnings and the like as evidence information.

  For example, in the figure, Nn (N1, N2,...) Indicates a failure cause node, Ee (E1, E2,...) Indicates an error evidence information node, and Ww (W1, W2,...) Indicates a warning evidence information node. Arrows indicate the causal relationship of each node, where the source of the arrow is the cause and the tip of the arrow is the result. That is, the nodes are connected so as to have a relationship of “cause” → “result”.

  For example, the relationship between the failure cause node N2 and the error evidence information node E1 is a relationship in which an “error state (such as a defect in the module 2)” appears based on the “cause N2”. The relationship between the failure cause nodes N3 and N6 and the warning evidence information node W1 is such that a “warning state (a state in which an error may occur in the module 1)” appears based on “cause N3” or “cause N6”. The relationship between the failure cause node N3 and the failure cause node N1 is such that “cause N3” (such as a defect in the module 1) occurs based on “cause N3”.

  In each node, a corresponding probability value (probability data) is set in advance from the conditional probability table. For example, a probability value is prepared for each node by preparing a conditional probability table that summarizes various conditions when a failure occurs and the probability that a failure will occur under that condition. Set in the form of reading the probability value of. The probability value itself may be an empirical value or may be measured data. The magnitude relationship is more important than the absolute value itself in the sense that the location (node: software module in this example) with the highest possibility of failure is estimated.

  The initial value of the probability value of each node is determined based on, for example, past data (experience values or actually measured data). As an example, a diagnostic model is constructed based on design information at the time of product shipment. Basically, since the diagnostic model is static, the probability is updated manually when the market trouble information changes thereafter. In addition, runtime errors that the developer does not expect during actual operation and errors due to interference with software created and installed by external vendors may occur. Update the software with countermeasures and reflect it in the diagnostic model. For example, a causal network (diagnostic model) is constructed based on failure cases and hardware / software design information. Evidence information that can be observed when a failure occurs is collected and applied to the causal network to estimate the cause of the failure. To do.

  In other words, when diagnosing failure or failure of an electronic device using a diagnostic model such as a Bayesian network, for example, replacement part units are determined as failure cause nodes based on failure cases and know-how according to the type and configuration of the electronic device. As a cause-and-effect network, a diagnostic model that sets conditional probability values based on trouble information in the market is constructed, and observable evidence information such as sensors and registers is collected when a failure occurs. A failure diagnosis is performed by selecting a diagnosis model corresponding to the corresponding device configuration, inputting evidence information, and estimating the failure occurrence probability of each failure cause node.

  Similarly, for fault diagnosis for software faults, errors and warnings coded in advance by developers, messages output by the operating system, etc. are used as evidence information, and causal networks are created from software component configurations and call relationships, and probability values are set. Build a diagnostic model and perform software fault diagnosis.

Under such circumstances, when the software environment changes, the diagnostic performance is affected by whether or not a diagnostic model corresponding to the environmental change is applied. Therefore, the diagnosis model that has been updated in response to changes in the software environment will be stepping on the procedure to be deployed to the equipment of the market. However, since such work takes a lot of time in some cases, failure diagnosis is performed with the old diagnosis model until the diagnosis model is updated, and there is a concern that deterioration of diagnosis performance or misdiagnosis may occur. Is done.

  For example, if there is a software change due to software update or addition of a new application, the developer needs to correct the software diagnostic model part corresponding to the changed part, and a new software defect case occurs In addition, developers need to analyze and apply them to diagnostic models. Developers trace the software update part and apply it to the diagnostic model, or collect new defect information that occurred in the market, analyze the cause, and then apply it to the diagnostic model. It takes time until the user diagnoses with the latest diagnostic model because the procedure for deploying the model to the equipment on the market takes place. Until then, the old diagnostic model has to be used, and the diagnostic performance deteriorates and misdiagnosis occurs. It will occur.

  As a countermeasure, the diagnosis condition control unit 460 according to the present embodiment uses the processing history of the software processing (recording of the processing process) in order to quickly and easily reflect the software update or new defect in the diagnosis model. The following mechanism is taken. That is, when an error or warning occurs while the user is using the image forming apparatus 1, the process history (for example, backtrace log or process log) of the process causing the error or warning trigger is acquired, and each log is used as a basis. Create a function call graph and convert it to a causal network. The information on errors and warnings that occur is associated with backtrace logs and process logs as evidence information, and causal networks are incorporated into the diagnostic model. The processing history may be acquired using a mechanism similar to a so-called debugging technique used in the software development process.

<Fault diagnosis system: first embodiment>
5 and 5A are diagrams showing a first embodiment of a failure diagnosis system 400 in which a management center 401 is connected to a plurality of image forming apparatuses 1 via communication lines. As described above, it is free to place functional parts related to failure diagnosis such as the failure probability inference unit 260 or the diagnosis condition control unit 460 on the image forming apparatus 1 side or on the server side (for example, the management center 401) side. . Here, a configuration example of the management center 401 when the failure probability reasoning unit 260 is arranged on the image forming apparatus 1 side and failure diagnosis is performed on the image forming apparatus 1 side is shown.

  The failure diagnosis system 400 includes a diagnosis server unit 401A that generates, updates, and optimizes a diagnosis model. In the illustrated fault diagnosis system 400, a plurality of image forming apparatuses 1 (A, B) configured to process observation data of the sensor unit 4 by software processing using a memory such as a CPU 912, a RAM 915, or an NVRAM 916. ,... (Excluding Z) are connected to the management center 401 via a communication network 406 such as the Internet. In addition to the image forming apparatus 1 and the management center 401, the communication network 406 includes a personal computer PC used for notifying the management center 401 of failure occurrence information about the image forming apparatus 1Z not connected to the communication network 406. Connection is possible.

  As shown in FIG. 3, each image forming apparatus 1 (A, B,..., Z) is provided with a software data acquisition function unit 908b such as a register for recording a log of software processing. In the case of the image forming apparatus 1 (excluding A, B,...: Z) connected to the communication network 406, the measurement data can be notified to the outside via the communication IF 999. The management center 401 is provided with a host computer, and can perform communication processing with the image forming apparatus 1 (excluding A, B,...: Z) via the communication network 406.

  A plurality of image forming apparatuses 1 (excluding A, B,...: Z) connected to the communication network 406 are managed by, for example, a service engineer SE (Service Engineer) inputting failure occurrence information through an operation panel or the like. It is configured to transmit failure information to the center 401. For the input of failure occurrence information from the operation panel, for example, a menu is hierarchically displayed and selected. Further, regarding the image forming apparatus 1Z not connected to the communication network 406, the failure occurrence information may be printed out by the image forming apparatus 1Z and input to an OCR (Optical Character Reader) at the service base.

  Incidentally, when preparing a diagnostic model on the management center 401 side, the management center 401 constructs a diagnostic model based on information of a plurality of image forming apparatuses 1. In order to adopt this mechanism, the management center 401 generates a diagnosis model using failure information (also referred to as market quality information) regarding the failure content of each device stored in the market quality information database 402a, and updates it appropriately. Then, a failure occurring in the diagnosis target device is diagnosed based on a diagnosis model constituted by a causal network having a conditional probability table at each node constituting the causal network. The market quality information database 402a is an example of a failure information storage unit that stores failure information regarding the failure content of each device.

  The diagnosis server unit 401A manages the generation / update and optimization of the diagnosis model, the database unit 402, the diagnosis model generation / update unit 410 that generates / updates the diagnosis model, and the failure diagnosis apparatus 3 shown in FIG. The diagnostic condition control unit 460 in FIG. In addition, the management center 401 collects quality information generated in the market (trouble content of trouble, hereinafter referred to as market quality information) for each failure location (failed location or software module), various quality information collection units 422, A communication unit 424 that transmits and receives information is provided.

  In this example, each image forming apparatus 1 is equipped with the failure probability inference unit 260 of the failure diagnosis apparatus 3 and performs the failure diagnosis on the image forming apparatus 1 side without taking the form of performing failure diagnosis at the management center 401. As shown in the form, when the trouble diagnosis is performed in the management center 401, the host computer is used for trouble diagnosis except for the data acquisition function unit 908a constituting the trouble diagnosis apparatus 3 on the image forming apparatus 1 side. In order to realize data processing function parts such as a feature quantity acquisition function part, a failure determination function part and an inference engine function part, and a function part (corresponding to the diagnosis condition control unit 460) for optimizing a diagnosis model by software processing The application program is installed.

  In this case, basically, for example, the feature quantity acquisition function part as the data reception function part is the diagnosis information collection part 160. The data processing function part includes, for example, a failure determination unit 262, an inference engine 264 (of course, a diagnosis condition control unit 460), and the like. With this configuration, the failure diagnosis system 400 is a system in which a failure diagnosis unit including the failure determination unit 262 and the inference engine 264 is provided in the management center 401 outside the apparatus using a communication line such as the Internet. The host computer of the management center 401 is configured to perform failure diagnosis on the image forming apparatus 1. In the management center 401, the host computer automatically uses a Bayesian network to determine failure probabilities of parts and software modules based on measurement data, software logs, and feature quantities extracted from the measurement data and software logs. Determine and identify the fault location.

  Functionally, in the case of adopting a configuration in which the diagnosis server unit 401A performs failure diagnosis, as shown by a dotted line, diagnosis information acquisition for acquiring information (diagnosis information) necessary for diagnosis of the device from the diagnosis target device 420 and a failure probability inference unit 430 (corresponding to the failure probability inference unit 260 in FIG. 2) that performs failure diagnosis based on the diagnosis information acquired by the diagnosis information acquisition unit 420. As a result of the failure diagnosis, the failure probability inference unit 430 extracts a higher failure cause candidate whose failure probability is equal to or higher than a predetermined threshold and notifies the image forming apparatus 1 of the failure cause.

  Hereinafter, parts related to the diagnostic model optimization processing function provided in the management center 401 of this embodiment will be described in detail. The “diagnostic model optimization processing function” of the present embodiment controls the diagnostic model used as a fault diagnosis condition for software faults so that software updates and new defects are quickly reflected in the diagnostic model. This is a function provided in the diagnostic condition control unit 460.

  Incidentally, when preparing a diagnostic model on the management center 401 side, the management center 401 constructs a diagnostic model based on information of a plurality of image forming apparatuses 1. In order to adopt this mechanism, the management center 401 generates a diagnosis model using failure information (also referred to as market quality information) regarding the failure content of each device stored in the market quality information database 402a, and updates it appropriately. Then, a failure occurring in the diagnosis target device is diagnosed based on a diagnosis model constituted by a causal network having a conditional probability table at each node constituting the causal network. The market quality information database 402a is an example of a failure information storage unit that stores failure information regarding the failure content of each device.

  As the “failure information”, for example, for each trouble response case in the market, the content of the failure, the worker who performed the measure for the failure, the machine No. , Treatment target parts, treatment content (treatment code), time required for work (work time), and other work content information are recorded.

  The failure information in the market quality information database 402a is configured in a list format, and includes, for example, date / time, machine number, service area code, area area code, customer code, failure location information code, failure phenomenon information code, and treatment information code. ing. The failure phenomenon corresponding to the failure phenomenon code is set for each failure diagnosis model. The market quality information database 402 a is not limited to the form in which the market quality information collection unit 422 collects failure information from each image forming apparatus 1. For example, the market quality information collection unit 422 stores the above contents from the visit history information of service engineers. It may be extracted and stored.

  Although not shown, the market quality information database 402a and the market quality information collection unit 422 of the first configuration example are removed from the management center 401 (diagnostic server unit 401A), and a dedicated server device (market quality management server) is installed. A configuration may be employed in which the market quality information database 402a and the market quality information collection unit 422 are provided in the market quality management server by providing the connection to the communication network 406.

  The diagnostic model generation / update unit 410 converts the market quality information collected by the market quality information collection unit 422 and accumulated in the market quality information database 402a in cooperation with the diagnostic information collection unit 160 and the log recording unit 168 on the image forming apparatus 1 side. Based on the failure occurrence frequency calculation unit 412 that calculates the occurrence frequency of the modeled failure cause for each failure part for each failure phenomenon or for each predetermined period, and the failure occurrence status is acquired from the market quality information database 402a at regular intervals. Then, a probability table update unit 419 that updates the conditional probability table of the diagnosis model is provided as a diagnosis model update unit. Incidentally, the update of the diagnostic model (specifically, the conditional probability table) is realized by updating the probability value of the conditional probability table or adding a node (in this case, a probability value is set for the additional node). The failure occurrence frequency calculation unit 412 registers a diagnosis model as a diagnosis condition for diagnosing the cause of failure of the component in the diagnosis model database 402b based on the calculated failure cause occurrence frequency.

  In addition, the diagnostic server unit 401A of the first embodiment includes the following functional units as a diagnostic condition control unit 460 for quickly and easily reflecting software updates and new defects in a diagnostic model.

  The diagnosis condition control unit 460 of the diagnosis server unit 401A includes an error / warning detection unit 462 that detects an error and a warning, and an error / warning detection as characteristic components of the present embodiment for performing a fault diagnosis of a software fault. The log acquisition unit 464 acquires a software processing history (log) triggered by an error or warning detected by the unit 462.

  Further, the diagnostic condition control unit 460 generates a call function graph generation unit 472 that generates a call function graph based on the backtrace log acquired by the backtrace log acquisition unit 464A, and a call function graph generated by the call function graph generation unit 472. A sub-causal network generation unit 474 that generates a sub-causal network related to a failure caused by software processing based on the base station. The sub-causal network related to a failure caused by software processing associates a software module that causes one or a plurality of failures caused by software processing with the probability that each software module causes.

  The sub-causal network generation unit 474 associates a failure caused by software processing with a malfunction in one or more software modules (library modules) that may have triggered the failure, and determines the conditional probability of the failure. A sub-causal network relating to each probability of failure (malfunction) is generated. For example, the sub-causal network generation unit 474 converts the modules into nodes collectively in units of software modules based on the call function graph generated by the call function graph generation unit 472, and converts the call function into a node state. Create a sub-causal network.

  Further, the diagnosis condition control unit 460 incorporates the sub-causal network generated by the sub-causal network generation unit 474 into the existing diagnosis model so that the diagnosis model is adapted to the diagnosis target device (preferably diagnosis). A diagnostic model optimization unit 476 (optimized according to the target device).

  Here, the log acquisition unit 464 only needs to acquire a processing history at the time of software processing that contributes to generation of the sub-causal network. Examples of the processing history at the time of software processing include a backtrace log, a process log, or Memory leak log, system log, etc. can be applied. Further, the sub-causal network generation unit 474 may generate a sub-causal network by combining the logs. The first embodiment is an example in which a backtrace log is applied as a processing history at the time of software processing, and the log acquisition unit 464 of the first embodiment includes a backtrace log acquisition unit 464A that acquires a backtrace log. It has the characteristics.

  On the other hand, in the second configuration example shown in FIG. 5A, the diagnosis condition control unit 460 of the first configuration example is removed from the diagnosis server unit 401A, and not only the failure probability inference unit 260 but also the diagnosis condition control unit 460 is on the image forming apparatus 1 side. The example of a structure mounted in is shown.

  By adopting such a mechanism of the first embodiment, it is possible to quickly and easily reflect the software update after product shipment or a new defect to the diagnosis model, thereby improving the software diagnosis performance.

<Operation Example: Overview of First Embodiment>
6 is a diagram for explaining diagnosis condition optimization processing ((failure diagnosis model optimization processing) in the failure diagnosis system 400 of the first embodiment, where FIG. This is a flowchart showing the procedure of the image forming process, which will be described in the case of the second configuration example in which the diagnosis condition control unit 460 is mounted on the image forming apparatus 1 side.

  For example, in the system configuration of the first embodiment, the log acquisition unit 464 includes a backtrace log acquisition unit 464A, and when an error / warning detection unit 462 detects an error or warning, the backtrace log acquisition unit 464A. The back trace log is acquired at, and the call function graph generation unit 472 generates a call function graph based on the back trace log. When this call function graph is generated, a function / module description list is extracted from the backtrace log, and a call function graph is generated using this function / module description list (details will be described later).

  For example, the log recording unit 168 records the software process of the image forming apparatus 1 operated by software (S100). In this example, the backtrace log BL can be acquired particularly when a failure occurs. When the error / warning detection unit 462 detects that an error or warning is output from the software or the OS (S102-YES), the error / warning detection unit 462 instructs the log acquisition unit 464 to acquire the backtrace log (S104). However, in the case of a warning, a description is given in advance that the program is temporarily stopped at the same time as the warning is output to the software, the backtrace acquisition program is operated, and the software is resumed when it is finished.

  Upon receiving this instruction, the log acquisition unit 464 acquires the backtrace log BL by the backtrace log acquisition unit 464A, and passes the acquired backtrace log BL to the call function graph generation unit 472 (S106).

  The call function graph generation unit 472 generates a call function graph based on the backtrace log BL received from the log acquisition unit 464 (S110). When the call function graph is generated, first, the function / module description list is obtained by extracting the call function and the library module including the call function from the description of the backtrace log BL and arranging them in the log order (call order). Generate a call path when an error or warning occurs (S112). Then, the function / module unit is graphed together to create a call function graph, and the created call function graph is passed to the sub-causal network generation unit 474 (S114). Specific examples of the function / module description list generation method based on the backtrace log BL and the call function graph generation method based on the function / module description list will be described later.

  The sub-causal network generation unit 474 generates a sub-causal network by converting the nodes, states, and links of the sub-causal network based on the call function graph generated by the call function graph generation unit 472 (S120). The details of the conversion from the call function graph to the node / state will be described later. For example, the sub-causal network generation unit 474 summarizes the call function graph in units of library modules (S122), the library modules as nodes, and functions. Is assigned as the state of the node (S124). Alternatively, a conversion table may be held and converted by referring to the table. Then, the sub-causal network generation unit 474 completes the sub-causal network by generating a link based on the direction of the arrow of the call function graph for each node (S126).

  Next, the diagnostic model optimization unit 476 incorporates the sub-causal network generated by the sub-causal network generation unit 474 into the existing diagnostic model so that the diagnostic model is adapted to the diagnosis target device (S160). ). At this time, the diagnostic model optimization unit 476 searches the node name and link of the sub-causal network with respect to the existing diagnostic model (referred to as an existing model) (S162), and if the node exists in the existing model, the state And the probability value are updated (S164-YES, S166), and if it is a new node that does not exist in the existing model, a probability table is added to the node, link, conditional conditional table (S164-NO, S168).

  The diagnostic model optimization unit 476 stores the appropriate diagnostic model optimized by incorporating the sub-causal network generated by the sub-causal network generation unit 474 into an existing diagnostic model in a predetermined storage medium (for example, the determination index storage unit 230). Store (S180). The diagnostic model optimization unit 476 may replace the appropriate diagnostic model with an existing diagnostic model, or store the optimized diagnostic model and leave the existing diagnostic model as it is. .

  The aptitude diagnosis model optimized by the diagnosis model optimizing unit 476 reflects the latest software environment at that time, such as software update after shipment and response to new defects. It can be used.

<Backtrace log>
FIG. 7 is a diagram illustrating an example of a backtrace log related to the error evidence information node Ee (e is a node number) applied in the first embodiment. The backtrace log BL is summary information that shows how the software (program) has reached the current location, and goes back up the module / function call stack when it stops due to an error or when the program pauses. The log is output to the caller in order for each line number indicated by #. The description in the first line of the log is a description that uniquely identifies the backtrace log BL. Each line is basically displayed in the order of address (description between ** and in), call function (description between in and from), and library module containing the call function (description after from). Yes. A line with a description of a library module is a description related to generation of a call function graph. For example, # 2 indicates that there is a call from a call function “gnome_gtk_module_info_get ()” included in the shared library module “/usr/lib/libgnomeui-2.so.0”.

  The # 0 line without the description of the library module is a description of the calling function related to the OS. Line # 3 in which none of the address, calling function, and library module is described indicates that an event has occurred.

  In this way, the log acquisition unit 464 acquires a call path when stopped due to an error. In the case of a warning, the software (program) pauses when a warning message is output, operates the backtrace, and resumes the software when it is finished. Similarly, the log acquisition unit 464 acquires the call path when the warning occurs. become.

<Generation method of call function graph>
8 and 9 are diagrams for explaining a specific example of a method for generating a call function graph by the call function graph generation unit 472. FIG. FIG. 8 shows an example of a function / module description list extracted from the backtrace log BL related to the error evidence information node Ee. FIG. 9 is a diagram illustrating an example of a call function graph regarding the error evidence information node Ee.

  When generating the call function graph, first, a description between “in” and “from” in the backtrace log BL shown in FIG. 7 is extracted as a call function, and the description following “from” is included in the call function. A function / module description list as shown in FIG. 8 is created by extracting as library modules and listing them in the order of line numbers (# numbers) (S112).

Thereafter, the call function graph generation unit 472 creates a call function graph as shown in FIG. 9 by graphing the unit of the function as “Fm / Mm” (S114). Here, Fm is a call function, Mm is a library module including the call function, and m in “Fm / Mm” corresponds to the row number (# number) in FIGS. For example, in FIG. 9, F2 is a call function “gnome_gtk_module_info_get ()” on the # 2 line, and M2 is a shared library module “/usr/lib/libgnomeui-2.so.0” on the # 2 line. is there. Incidentally, in the example shown in FIGS. 7 and 8, each line of # 1 , # 2 , # 4 to # 12 in which the description of the library module is described is a description related to generation of the call function graph, and # 3 indicating the occurrence of the event. The line is removed.

<Sub-Causal Network Generation Method: First Embodiment>
FIG. 10 is a diagram illustrating a specific example of a sub-causal network generation method by the sub-causal network generation unit 474 according to the first embodiment.

  Since the library module often includes a plurality of calling functions, the sub-causal network generation unit 474 first collects the calling function graph in units of library modules (S122). Further, the library module is assigned as a node and the calling function is assigned as the state of the node (S124).

For example, in the example of FIG. 7 and FIG. 8, the library module “/usr/lib/libgdk-x11-2.0.so.0” includes the calling function “gdk_region_rectangle ()” on the # 5 line. In addition, a state number is set in the calling function on the # 5 line.
Node N4: /usr/lib/libgdk-x11-2.0.so.0
State 1: gdk_region_rectangle (): (# 5)

The library module “/usr/lib/libgtk-x11-2.0.so.0” includes the calling functions on the # 6, # 7 and # 8, # 9, # 10 and # 11, # 12 lines. Therefore, as shown below, different state numbers are set for the calling functions in the # 6, # 7 and # 8, # 9, # 10 and # 11, # 12 lines, respectively.
Node N5: /usr/lib/libgtk-x11-2.0.so.0
State 1: gtk_widget_region_intersect (): (# 6)
State 2: gtk_container_propagate_expose (): (# 7, # 8)
State 3: gtk_box_pack_start_defaults (): (# 9)
State 4: gtk_container_forall (): (# 10, # 11)
State 5: gtk_marshal_BOOLEAN__VOID (): (# 12)

  Here, n in the node Nn indicates a node number, and a serial number from 1 is tentatively assigned when the sub-causal network is generated.

  The sub-causal network generation unit 474 sets a node assigned to the library module as a node of the sub-causal network, and generates a link based on the direction of the arrow of the call function graph, thereby generating a sub-causal network as shown in FIG. Is generated. Here, the arrangement order of the nodes assigned to the library module including a plurality of calling functions is assigned to the node numbers starting from the smallest row number (# number) in FIGS.

  For example, in the example shown in FIG. 9 relating to the error evidence information node Ee (originally FIGS. 7 and 8), # 1, # 2, # 4 to ## related to generation of a call function graph (that is, description of a library module) In each of the 12 rows, the calling function of each row of # 6 to # 12 is included in the same library module, so that the sub-causal network generation unit 474 has the nodes N1 and # 2 related to the # 1 row as shown in FIG. The nodes Nn are arranged in order of the node N2 related to the row, the node N3 related to the # 4th row, the node N4 related to the # 5th row, and the node N5 related to the # 6 to # 12th rows. Then, the sub-causal network generation unit 474 generates a link in the order from the node N5 toward the node N1 (in the direction opposite to the direction of the arrow in the call function graph), and from the node N5 to the error evidence information node Ee. A sub-causal network is completed by generating a link toward (S126). Each node Nn is given a library module Mm as a node name, and a call function Fm is added as a state.

<Diagnostic model optimization processing: first embodiment>
FIG. 11 is a diagram for explaining the details of the diagnostic condition optimization process (diagnostic model optimization process: de facto diagnostic model update process) in the diagnostic model optimization unit 476 of the first embodiment. The diagnostic model optimization unit 476 incorporates the sub-causal network generated by the sub-causal network generation unit 474 into the existing diagnostic model. In the case of the first embodiment, the update before the update ( The node name and link of the sub-causal network are searched for the existing diagnostic model, and if the node exists in the diagnostic model before the update, the node number is not changed and the state is added and the probability is updated before the update. If a new node does not exist in the diagnostic model, the node number is not duplicated with the node number in the diagnostic model before the update and is reassigned to a smaller number, and a node / link / probability table is added.

  For example, when a new error occurs (error evidence information node E4) for the diagnostic model before update shown in FIG. 4, the sub-causal network generated by the sub-causal network generation unit 474 is shown in FIG. As shown, the sub-causal network generation unit 474 has three nodes N1, N2, and N3, and links are generated from the node N3 → the node N2 → the node N1, and the error evidence information node E4 from the node N3. It is assumed that a link is generated toward N1 and N2 are existing nodes existing in the diagnostic model before update, and N3 is a new node that does not exist.

  In this case, since the node N2 and the node N1 of the sub-causal network generated by the sub-causal network generation unit 474 are existing nodes existing in the diagnostic model before the update, as illustrated in FIG. The optimization unit 476 uses the existing node as it is for the node N2 and the node N1, and adds a state and updates a probability value. On the other hand, since the node N3 is a new node that does not exist in the diagnostic model before update, the diagnostic model optimization unit 476 does not overlap the node N3 with the node of the diagnostic model before update as shown in FIG. In addition, the node number N11 is reassigned and added as a small number, and a probability value is set (added) to the node. Further, a link is created from the added node N11 toward the node N2 and the error evidence information node E4. In FIG. 11 (2), the hatched nodes N1, N2, N11, and E4 and their links are portions into which the sub-causal network created by the sub-causal network generation unit 474 is incorporated.

  According to the mechanism of the first embodiment, the sub-causal network generated based on the backtrace log BL acquired using an error or warning as a trigger is immediately incorporated into the existing (before update) diagnostic model. .

  In the mechanisms described in Patent Documents 1 to 3, there is no description about updating the software diagnostic model, and software updates and new defects are not quickly reflected in the diagnostic model. There is a risk of causing a diagnosis.

  On the other hand, in the mechanism of the first embodiment, a back trace log BL, which is an example of a software processing history (record of processing steps), is acquired using an error or warning as a trigger, and based on the back trace log BL. A sub-causal network was generated, and this sub-causal network was incorporated into the diagnostic model before update. For this reason, for example, even if a runtime error that the developer does not expect during actual operation or an error due to interference with software installed and installed by an external vendor occurs, the failure status in the software processing is quick and This is easily reflected in the diagnostic model, and the diagnostic performance of software diagnosis is improved. Software diagnosis performance is improved by quickly and easily reflecting software updates and new defects after product shipment into the diagnostic model.

  In performing failure diagnosis of a system composed of multiple modules linked together, a sub-causal network is generated when a failure occurs, and this sub-causal network is incorporated into the causal network of the existing diagnosis model. It may be pointed out that it is similar to the mechanism described in Patent Document 1. However, the present embodiment performs failure diagnosis of a software processing system composed of a plurality of software modules, and there is a structural difference that a sub-causal network is generated using a software processing history. From these differences, the following specific action that cannot be obtained by the mechanism described in Patent Document 1 can be obtained.

  That is, in Patent Document 1, a plurality of causal relationships of failures that are assumed in advance as failure models are registered, and the corresponding model is inquired according to the failure that occurred and recursively incorporated into the causal network. Therefore, it is necessary to construct a failure model, and a means for restricting the size of the failure model is required to prevent the failure model from becoming very large, which increases the processing load. On the other hand, in the structure of this embodiment, it is not necessary to construct a knowledge-based failure model database in advance, and the size of the diagnostic model increases because only the failures that have occurred are incorporated in the failure model in real time. In addition to suppressing this, it is possible to obtain a specific action that a means for limiting the size of the diagnostic model is unnecessary and the processing load is light.

<Fault diagnosis system: second embodiment>
FIG. 12 is a diagram illustrating a second embodiment (second configuration example) of a failure diagnosis system 400 in which a management center 401 is connected to a plurality of image forming apparatuses 1 via communication lines. Here, although it shows with the modification with respect to the 2nd structural example shown to FIG. 5A, the same deformation | transformation can be added also to the 1st structural example shown in FIG.

  The second embodiment is an example in which the process log PL is applied as a processing history at the time of software processing, and the log acquisition unit 464 of the second embodiment acquires the process log PL in addition to the backtrace log acquisition unit 464A. It is characterized in that a process log acquisition unit 464B is provided. In response to this, the sub-causal network generation unit 474 of the second embodiment causes a failure (error or warning) as a result due to the process list in the process log PL acquired by the process log acquisition unit 464B. To generate a sub-causal network. Since the sub-causal network in which the cause and the result are linked is generated from the process log PL, the sub-causal generated by the process log acquisition unit 464B based on the process log PL without any special measures being taken by the diagnostic model optimization unit 476 The network can be incorporated directly into an existing diagnostic model. Other points are the same as in the first embodiment.

  Incidentally, the back trace log acquisition unit 464A may be removed and a process log acquisition unit 464B may be provided. In this case, the diagnostic condition control unit 460 of the second embodiment does not include the call function graph generation unit 472.

<Operation Example: Overview of Second Embodiment>
FIG. 13 is a diagram for explaining diagnosis condition optimization processing (failure diagnosis model optimization processing) in the failure diagnosis system 400 of the second embodiment. Here, FIG. 13 is a flowchart showing the procedure of the failure diagnosis model optimization process of the second embodiment. The step numbers are shown in the 200s, and the same processing steps as in the first embodiment are shown with the same numbers in the 10s and 1s. Here, the case of the second configuration example in which the diagnosis condition control unit 460 is mounted on the image forming apparatus 1 side will be described.

  For example, in the system configuration of the second embodiment, the log acquisition unit 464 includes a process log acquisition unit 464B. When an error / warning detection unit 462 detects an error or warning, the process log acquisition unit 464B The log PL is acquired, and based on the process log PL, the sub-causal network generation unit 474 generates a sub-causal network in which an error or warning results from the process list in the process log PL (details will be described later). ).

  For example, the log recording unit 168 records the software process of the image forming apparatus 1 operated by software (S200). In this example, the process log PL can be acquired particularly when a failure occurs. When the error / warning detection unit 462 detects that an error or warning is output from the software or the OS (YES in S202), the error / warning detection unit 462 instructs the log acquisition unit 464 to acquire the backtrace log (S205). Upon receiving this instruction, the log acquisition unit 464 acquires the process log PL by the process log acquisition unit 464B, and passes the acquired process log PL to the sub-causal network generation unit 474 (S207). That is, when the error / warning detection unit 462 detects an error or warning, the log acquisition unit 464 acquires the process log at that time by the process log acquisition unit 464B. That is, the process that was started when the error or warning occurred is extracted.

  The sub-causal network generation unit 474 generates a sub-causal network by converting the node, state, and link of the sub-causal network based on the process log PL passed from the process log acquisition unit 464B (S220). The conversion from the process log PL to the sub-causal network in the sub-causal network generation unit 474 is performed, for example, by assigning a process list in the process log PL to the cause node and assigning an error or warning to the result node. Is generated (S223). This is because, in the initial stage, it may be considered that a process started at the time of occurrence of an error or warning causes the error or warning that has occurred.

  The diagnostic model optimization unit 476 optimizes the diagnostic model by incorporating the sub-causal network generated by the sub-causal network generation unit 474 into the existing diagnostic model (S260), and stores the optimized aptitude diagnostic model in a predetermined storage. It memorize | stores in a medium (for example, determination parameter | index storage part 230) (S280).

  The aptitude diagnosis model optimized by the diagnosis model optimizing unit 476 reflects the latest software environment at that time, such as software update after shipment and response to new defects. It can be used.

<Process log>
FIG. 14 is a diagram illustrating an example of the process log PL regarding the error evidence information node Ee and the warning evidence information node Ww (w is a node number) applied in the second embodiment. The process log PL shows a history of processing processes in software processing. As an example, the process log PL includes a process name, a process ID, a parent process ID, an activation date / time, a process time, and the like.

  For example, in FIG. 14, “UID” is an identifier (ID) that uniquely identifies the user who started the process, “PID” is an identifier (ID) that uniquely identifies the process, and “PPID” is the parent process of the started process. “C” is the CPU usage rate (%), “STIME” is the process start date and time, and “TTY” is either the terminal, console, or auto that started the process Carving out (? Indicates automatic), “TIME” indicates the accumulated CPU time of the process, and “CMD” indicates the command.

<Diagnostic model optimization processing: second embodiment>
FIG. 15 is a diagram for explaining the details of the diagnostic model optimization processing (actual diagnostic model update processing) in the diagnostic model optimization unit 476 of the second embodiment. The diagnostic model optimization unit 476 incorporates the sub-causal network generated by the sub-causal network generation unit 474 into the existing diagnostic model. In the case of the second embodiment, the diagnostic model optimization unit 476 applies the pre-update (existing) diagnostic model. In the initial stage, the process is considered to cause an error or a warning, and the process Pp is directly linked to the error evidence information node Ee or the warning evidence information node Ww in the diagnostic model before update (existing). After that, the probability value is automatically adjusted based on the number of occurrences each time the update is repeated, and in some cases, a link is added to update the diagnosis model according to the actual failure occurrence situation.

For example, FIG. 15 shows an application example for FIG. Regarding the error evidence information node E4, the sub causal network generated by the sub causal network generation unit 474 has links generated from the processes P1 and P2 toward the error evidence information node E4 as shown in FIG. To do. In this case, the diagnosis model optimization unit 476 directly links the processes P1 and P2 to the error evidence information node E4 on the assumption that the processes P1 and P2 cause the error that has occurred (error evidence information node E4).

According to the mechanism of the second embodiment as described above, a sub-causal network in which an error or warning is the result is immediately existing (before update) due to the process list in the process log PL acquired using an error or warning as a trigger. It will be incorporated into the diagnostic model. In comparison with the first embodiment, there is a difference between the backtrace log BL and the process log PL, but there is no big difference in that the sub-causal network generated by the sub-causal network generation unit 474 is incorporated in the diagnostic model before update. As in the first embodiment, software update performance after product shipment and new defects are quickly and easily reflected in the diagnosis model, thereby improving software diagnosis performance.

<Failure diagnosis system: Third embodiment>
FIG. 16 is a diagram illustrating a third embodiment of a failure diagnosis system 400 in which a management center 401 is connected to a plurality of image forming apparatuses 1 via a communication line. In the third embodiment, each image forming apparatus 1 generates and holds a sub-causal network, sends this to the diagnosis server unit 401A of the management center 401, and the diagnosis server unit 401A appropriately sets the diagnosis model based on the sub-causal network. It is characterized in that it is configured to send it to each image forming apparatus 1 after being converted (updated).

  In terms of configuration, the functional units constituting the diagnostic condition control unit 460 of the first embodiment or the second embodiment are separately arranged on the image forming apparatus 1 side and the management center 401 (diagnosis server unit 401A) side. It becomes. Specifically, the error / warning detection unit 462, the log acquisition unit 464, the call function graph generation unit 472 (not necessary when the second embodiment is used as a basis), and the sub-causal network generation unit 474 are included in the image forming apparatus 1. The diagnosis model optimization unit 476 is arranged on the management center 401 (diagnosis server unit 401A) side.

  Each image forming apparatus 1 newly stores a sub-causal network generated by the sub-causal network generation unit 474 in addition to the functional units excluding the diagnostic model optimization unit 476 of the first and second embodiments. The causal network holding unit 482 and the sub causal network held in the sub causal network holding unit 482 are output to the diagnosis server unit 401A at a predetermined timing (specifically, when there is a request from the diagnosis server unit 401A). The sub-causal network output unit 484 and the aptitude diagnosis model optimized (updated) based on the sub-causal network are received from the diagnosis server unit 401A and applied as the diagnosis model of the own apparatus (that is, the existing diagnosis model is updated). ) An aptitude diagnosis model application unit 486 is provided.

  In addition, the diagnosis server unit 401A is newly optimized (updated) by a sub-causal network collection unit 492 that collects sub-causal networks from the sub-causal network generation unit 474 of each image forming apparatus 1 and a diagnosis model optimization unit 476. The diagnostic model presenting unit 494 that presents the appropriate diagnostic model to each image forming apparatus 1 is provided. The sub-causal network collection unit 492 stores the sub-causal network collected from each image forming apparatus 1 in a storage unit (for example, a diagnostic model database 402b) such as a hard disk device.

<Operation Example: Overview of Third Embodiment>
FIG. 17 is a diagram for explaining diagnosis condition optimization processing (failure diagnosis model optimization processing) in the failure diagnosis system 400 of the third embodiment. Here, FIG. 17 is a flowchart showing the procedure of the failure diagnosis model optimization process of the third embodiment. The step numbers are shown in the 300s, and the same processing steps as those in the first and second embodiments are shown with the same numbers in the 10s and 1s.

  In each image forming apparatus 1, as in the first and second embodiments, the software recording process of the image forming apparatus 1 operated by software is recorded by the log recording unit 168 (S 300), and errors and warnings are recorded. As a trigger, the log acquisition unit 464 acquires the backtrace log BL and the process log PL (S302, S304), and the subcausal network generation unit 474 generates a subcausal network based on these logs (S320). The sub-causal network generation unit 474 holds the generated sub-causal network in the sub-causal network holding unit 482 (S330).

  The sub-causal network collection unit 492 of the diagnostic server unit 401A (diagnostic server unit 401A) first collects the sub-causal network of each image forming apparatus 1 via the communication network 406 at the output instruction timing first ( (S331-YES), each image forming apparatus 1 is instructed to output a sub-causal network (S332). Upon receiving this instruction, the sub-causal network output unit 484 of each image forming apparatus 1 reads out the sub-causal network held in the sub-causal network holding unit 482 and outputs it to the diagnosis server unit 401A via the communication network 406 ( S334). The sub-causal network collection unit 492 holds the sub-causal network received (collected) from each image forming apparatus 1 in the storage unit (S336).

  The diagnostic model optimization unit 476 performs the diagnostic model optimization processing described in the first and second embodiments on the sub-causal network collected by the sub-causal network collection unit 492 from each image forming apparatus 1 and held in the storage unit 493. In the same manner as described above, the diagnostic model is adapted to the diagnosis target apparatus by being incorporated into the existing (pre-update) diagnostic model (S360). At this time, the diagnostic model optimization unit 476 classifies each sub-causal network collected by the sub-causal network collection unit 492 for each model as processing unique to the third embodiment (S361), and the existing diagnostic model for each model. Incorporate into.

  The diagnostic model presentation unit 494 presents the appropriate diagnostic model that has been optimized (updated) by the diagnostic model optimization unit 476 to the corresponding device (S370). The aptitude diagnosis model application unit 486 of the image forming apparatus 1 that has received the appropriate diagnosis model from the diagnosis server unit 401A stores the received aptitude diagnosis model in a predetermined storage medium (for example, the determination index storage unit 230). Then, the existing diagnosis model is updated, and the diagnosis using the received aptitude diagnosis model is performed (S380).

  According to such a mechanism of the third embodiment, the diagnostic server unit generates the sub-causal network generated individually by each image forming apparatus 1 based on the backtrace log BL and the process log PL acquired using an error or warning as a trigger. Since the diagnostic model optimization unit 476 of 401A is integrated into an existing diagnostic model, the software diagnostic accuracy is further improved. A diagnostic model that covers all the software fault information individually held in each image forming apparatus 1 is generated, and the diagnostic accuracy is further improved.

  As mentioned above, although this invention was demonstrated using embodiment, the technical scope of this invention is not limited to the range as described in the said embodiment. Various changes or improvements can be added to the above-described embodiment without departing from the gist of the invention, and embodiments to which such changes or improvements are added are also included in the technical scope of the present invention.

  Further, the above embodiments do not limit the invention according to the claims (claims), and all combinations of features described in the embodiments are not necessarily essential to the solution means of the invention. Absent. The embodiments described above include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. Even if some constituent requirements are deleted from all the constituent requirements shown in the embodiment, as long as an effect is obtained, a configuration from which these some constituent requirements are deleted can be extracted as an invention.

  For example, in the above-described embodiment, an example in which a failure diagnosis device that performs a failure diagnosis of a software failure is applied to an image forming apparatus such as a copying machine, a printer function, a facsimile function, or a multifunction machine having a combination of these functions is shown. However, a device to which a failure diagnosis device that performs software failure failure diagnosis is applied is not limited to an image forming device, and may be applied to other arbitrary devices such as home appliances and automobiles.

It is a figure showing an example of composition of an image forming device carrying one embodiment of a failure diagnosis device. It is a block diagram showing one embodiment of a failure diagnosis device. It is a block diagram which shows an example of a hardware configuration in the case of implement | achieving a failure diagnosis apparatus like software using an electronic computer. It is a Bayesian network model figure which shows the structural example of the Bayesian network utilized at the time of fault diagnosis of a software failure in a failure probability reasoning part. It is a figure which shows 1st Embodiment (1st structural example) of a failure diagnosis system. It is a figure which shows 1st Embodiment (2nd structural example) of a failure diagnosis system. It is a flowchart which shows the procedure of the failure diagnosis model optimization process in the failure diagnosis system of 1st Embodiment. It is a figure which shows an example of the backtrace log regarding the error evidence information node applied in 1st Embodiment. It is a figure which shows an example of the function / module description list extracted from the backtrace log regarding an error evidence information node. It is a figure which shows an example of the call function graph regarding an error evidence information node. It is a figure explaining the specific example of the production method of the subcausal network by the subcausal network production | generation part of 1st Embodiment. It is a figure explaining the detail of the diagnostic model optimization process in the diagnostic model optimization part of 1st Embodiment. It is a figure which shows 2nd Embodiment (2nd structural example) of a failure diagnosis system. It is a flowchart which shows the procedure of the failure diagnosis model optimization process in the failure diagnosis system of 2nd Embodiment. It is a figure which shows an example of the process log regarding the error proof information node and warning proof information node applied in 2nd Embodiment. It is a figure explaining the detail of the diagnostic model optimization process in the diagnostic model optimization part of 2nd Embodiment. It is a figure which shows 3rd Embodiment of a failure diagnosis system. It is a flowchart which shows the procedure of the failure diagnosis model optimization process in the failure diagnosis system of 3rd Embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Image forming apparatus 140 ... Operation | movement state information acquisition part, 152 ... Failure information acquisition part, 160 ... Diagnostic information collection part, 168 ... Log recording part, 230 ... Determination index storage part, 260 ... Failure probability reasoning part, 262 ... Failure determination unit, 264 ... inference engine, 3 ... failure diagnosis device, 3A ... diagnosis information generation unit, 3B ... failure diagnosis unit, 4 ... sensor unit, 400 ... failure diagnosis system, 401 ... management center, 401A ... diagnosis server unit, 402 ... Database unit, 402a ... Market quality information database, 402b ... Diagnostic model database, 406 ... Communication network, 410 ... Diagnostic model generation / update unit, 412 ... Failure occurrence frequency calculation unit, 419 ... Probability table update unit, 420 ... Diagnosis Information acquisition unit, 422 ... market quality information collection unit, 424 ... communication unit, 430 ... failure probability reasoning unit, 460 ... diagnostic condition control unit, 462 ... error / Warning detection unit, 464 ... log acquisition unit, 464A ... backtrace log acquisition unit, 464B ... process log acquisition unit, 472 ... call function graph generation unit, 474 ... sub-causal network generation unit, 476 ... diagnostic model optimization unit, 482 ... sub-causal network holding unit, 484 ... sub-causal network output unit, 486 ... aptitude diagnosis model application unit, 492 ... sub-causal network collection unit, 494 ... diagnosis model presentation unit

Claims (6)

A recording means for recording a processing history of software for operating the electronic device;
An acquisition means for acquiring a processing history of the software before the occurrence of the failure from the recording means when a failure due to the software processing occurs in the electronic device;
Classification means for classifying the software processing into one or a plurality of cause modules based on the processing history acquired by the acquisition means;
Generating means for generating a sub-causal network in which each of the cause modules classified by the classification means is associated with probability;
A fault diagnosis apparatus comprising: an updating unit that updates the existing diagnostic model by incorporating the sub-causal network generated by the generating unit into a causal network of an existing diagnostic model. The acquisition unit acquires a backtrace log output retroactively from a call stack of a function of a software module that has notified the occurrence of the failure, as the processing history of the software,
A call function graph generation unit that extracts a call function and a software module including the call function from the backtrace log acquired by the acquisition unit, and generates a call function graph by graphing in units of the call function and the software module; In addition,
The generation means assigns a software module of the call function graph generated by the function graph generation unit to a node of the sub-causal network, assigns the call function to a state of the node, and assigns each node in the reading order of the call function. The failure diagnosis apparatus according to claim 1, wherein the sub-causal network is generated by linking based on the link. The updating means, in combining the sub-causal network generated by the sub-causal network generation unit with the causal network of the existing diagnostic model,
For the causal network of the existing diagnostic model, search the node name and link of the sub-causal network generated by the sub-causal network generation unit,
When the node of the sub-causal network exists in the existing diagnostic model, the state is added and the probability value is updated,
The failure diagnosis apparatus according to claim 2, wherein a node, a link, and a probability table are added when a node of the sub-causal network does not exist in an existing diagnosis model. The acquisition means acquires a process log of the software processing system as the processing history of the software,
The failure diagnosis apparatus according to claim 1, wherein the generation unit generates the sub-causal network by using the process list in the process log acquired by the acquisition unit as a cause and generating the failure as a result. A sub-causal network holding unit that stores the sub-causal network generated by the generating unit;
A sub-causal network collection unit that collects the sub-causal network held in each sub-causal network holding unit of the plurality of electronic devices at a predetermined timing; and
The failure diagnosis apparatus according to claim 1, wherein the updating unit classifies the sub-causal network of each electronic device collected by the sub-causal network collection unit for each model and incorporates the sub-causal network into an existing diagnosis model for each model. Computer
Recording means for recording a processing history of software for operating an electronic device ;
An acquisition unit configured to acquire , from the recording unit, a processing history of the software before the occurrence of the failure when a failure caused by the software processing occurs in the electronic device ;
Classification means for classifying into one or a plurality of cause modules of a failure caused by the software processing based on the processing history acquired by the acquisition means;
Generating means for generating a sub-causal network in which each of the cause modules classified by the classification means is associated with probability ;
Update means for updating the existing diagnostic model by incorporating the sub-causal network generated by the generating means into the causal network of the existing diagnostic model ;
Program to function as .

Images