WO2007099578A1 - 故障解析装置 - Google Patents

故障解析装置 Download PDF

Info

Publication number
WO2007099578A1
WO2007099578A1 PCT/JP2006/303553 JP2006303553W WO2007099578A1 WO 2007099578 A1 WO2007099578 A1 WO 2007099578A1 JP 2006303553 W JP2006303553 W JP 2006303553W WO 2007099578 A1 WO2007099578 A1 WO 2007099578A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
analysis
failure
log
log information
Prior art date
Application number
PCT/JP2006/303553
Other languages
English (en)
French (fr)
Inventor
Masato Nakagawa
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2006/303553 priority Critical patent/WO2007099578A1/ja
Priority to JP2008502565A priority patent/JP4523659B2/ja
Priority to EP06714690.2A priority patent/EP1990722B1/en
Publication of WO2007099578A1 publication Critical patent/WO2007099578A1/ja
Priority to US12/230,241 priority patent/US8166337B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2268—Logging of test results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis

Definitions

  • the present invention relates to a failure analysis device that is mounted on an information processing device including a plurality of boards on which a plurality of logic circuits are mounted and analyzes what kind of failure has occurred in those logic circuits. In particular, it is possible to reduce memory resources, speed up processing, reduce development man-hours, analyze serious failures without omissions, and reduce the range that cannot be analyzed.
  • the present invention relates to a failure analysis apparatus.
  • An information processing apparatus equipped with an ASIC usually includes a plurality of system boards equipped with a plurality of types of ASICs.
  • FIG. 15 illustrates the configuration of the prior art.
  • 100 indicates a plurality of system boards to be analyzed mounted in the information processing apparatus
  • 110 indicates a board analysis information table
  • 120 indicates a system analysis information table
  • 130 represents an analysis processing unit.
  • This system board 100 is usually equipped with a plurality of types of ASICs!
  • the board analysis information table 110 is defined for each system board 100 and stores information necessary for analyzing a failure occurring in an ASIC mounted on the system board 100.
  • the system analysis information table 120 stores information necessary for failure analysis between the system boards 100.
  • the analysis processing unit 130 includes an analysis processing function that performs failure analysis for each system board 100 and an analysis processing function that performs failure analysis of the entire system.
  • the analysis processing unit 130 is specifically realized by firmware (hereinafter sometimes referred to as monitoring firmware) mounted on the information processing apparatus, and includes the board analysis information table 110 and system analysis.
  • the information table 120 is expanded on the memory of the firmware.
  • the board analysis information table defined for each system board 100 is obtained by collecting ASIC log information (hardware failure flag described later) for each system board 100.
  • the failure that occurred in the system board 100 is identified by performing the failure analysis on the system board 100 using 110 !.
  • the system analysis information table 120 is subsequently used. For example, a failure detected on the receiving side occurs with a failure occurring on the transmitting side. In the end, the failure detected on the receiving side is excluded from the failure analysis, and the failure analysis of the entire system is performed to identify what kind of failure has finally occurred. .
  • the AS The IC designer or the system board 100 designer creates the system analysis information table 120.
  • the system designer or the system board 100 designer creates the system analysis information table 120.
  • the board analysis definition which is the data before compilation of the board analysis information table 110, is uniquely determined by each ASIC designer for each ASIC type. Alternatively, create it individually in consultation with the system board 100 designer. The system designer who compiles the system independently or in consultation with the designer of the system board 100, edits the board analysis definition of the system analysis information table 120 before compiling the system analysis. Create a definition. Then, the board analysis information table 110 and the system analysis information table 120 are created by compiling the board analysis definition and system analysis definition created in this way into a format that can be captured by the monitoring firmware. .
  • the analysis processing unit 130 is a force that performs failure analysis on the system board 100 using the board analysis information table 110 created in this way. In this case, as shown in FIG. Identifying what kind of failure occurred by storing in the failure flag buffer secured in the failure analysis the hardware failure flags that collect power (in-node flags that leave the cause of failure in case of hardware failure) Will be processed.
  • the conventional analysis processing unit 130 stores the previously detected node failure flag in the failure flag buffer, and when the failure flag buffer is full, The hardware failure flag detected after that is discarded, and what kind of failure has occurred is identified by extracting what kind of hardware failure flag is stored in the failure flag buffer. I made it like that.
  • the analysis processing unit 130 performs failure analysis using the board analysis information table 110 and the system analysis information table 120 created by the method shown in FIG. 16, but the conventional analysis processing unit 130 As shown in Fig. 18, the failure analysis is performed by the system at 130.
  • the board analysis information table 110 and system analysis information table 120 which are the information used in the failure analysis, are temporarily processed when an error occurs in the system. In the monitoring firmware memory.
  • the memory space shown in FIG. 18 shows the system memory space of the monitoring firmware
  • the analysis information shown in FIG. 18 is the board analysis information table 110 and information used for failure analysis.
  • the system analysis information table 120 is shown, and the analysis work shown in FIG. 18 indicates a working memory area used by the monitoring firmware for failure analysis.
  • failure analysis is performed on the system board 100 as a unit, and as shown in FIG. 19, for example, as shown in FIG.
  • the ASIC-D force shown in the figure cannot collect the hardware failure flag, the failure analysis for the system board 100 becomes impossible.
  • the board analysis information table 110 stores the system board 100. Since it is generated in units, the board analysis information table 110 of the same ASIC is redundantly included. This is also a cause of demanding large memory resources.
  • the board analysis information table 110 differs depending on the mounting position.
  • the board analysis information table 110 includes The board analysis information table 110 cannot be shared because it is necessary to describe the analysis definition according to the mounting position of the ASIC. Since the same ASIC board analysis information table 110 is redundantly included, a large memory resource is required.
  • the failure analysis is a temporary process executed when a failure occurs in the system as described in FIG. Nevertheless, the board analysis information table 110 and the system analysis information table 120, which are information used in the failure analysis, are made to be resident in the monitoring firmware memory immediately after system startup. .
  • the board analysis information table 110 and the system analysis information table 120 to be resident at this time are the numbers corresponding to the types and version numbers of the ASICs installed in the information processing apparatus, if they are divided in advance. However, if there is no power distribution in advance, it is necessary to make all of the information that can be installed in the information processing device resident, so a large amount of memory is required for the resident.
  • failure analysis is performed using two tables: the board analysis information table 110 and the system analysis information table 120 !.
  • the board analysis information table 110 is created by the ASIC designer and the system board 100 designer
  • the system analysis information table 120 is created by the system designer and the system board 100 designer. become.
  • failure analysis is interrupted with a fixed number of detections in accordance with the fact that they cannot be stored in the failure flag buffer. It was like that.
  • the present invention has been made in view of strong circumstances, and when realizing a function of analyzing a failure occurring in a logic circuit such as an LSI installed in an information processing apparatus, a memory resource is provided. Reduction of energy sources, high-speed processing, and reduction of development man-hours. The purpose is to provide a new failure analysis technology that realizes analysis without omission and further reduces the range where analysis is impossible.
  • the failure analysis apparatus of the present invention is mounted on an information processing apparatus including a plurality of boards on which a plurality of logic circuits are mounted, and what kind of failure occurs in those logic circuits.
  • the log information is collected for the log information that also collects the logic circuit power in association with the board number and board mounting position on which the logic circuit is mounted.
  • Storage means for storing analysis information to be collected, (2) collection means for collecting log information indicating failure occurrence from the logic circuit when a failure occurs in the logic circuit, (3) log information collected by the collection means, and storage Solutions stored in the means Based on the information, and sea urchin configured by including an analysis means for any failure to the logic circuit to analyze whether the generated.
  • the index information used for indexing analysis information applied to a logic circuit that may be mounted on an information processing apparatus to be analyzed at the time of apparatus startup (4) First analysis means to be stored in the storage means, and (5) required for analysis of the analysis means according to the logic circuit information and index information installed in the information processing device to be analyzed when a logic circuit failure occurs
  • Second analysis means for specifying the analysis information to be stored, and storing the specified analysis information in a storage means.
  • the storage means may describe, as information on the conditions under which the log information is valid, information on the conditions indicating which log information indicates the occurrence of a failure.
  • the log information indicates the occurrence of a failure and the condition information as conditions information that makes the log information invalid.
  • index information used for indexing analysis information is stored in the storage means when the apparatus is activated.
  • log information indicating the failure occurrence is collected from each logic circuit.
  • information on what kind of logic circuit is used in the information processing apparatus is acquired, and the information is acquired according to the index information stored in the storage means.
  • the analysis information applied to the logic circuit indicated by the information is specified, and the specified analysis information is stored in the storage means.
  • the log information that displays the occurrence of the failure is extracted based on the condition information described in the analysis information. By doing so, it is analyzed what kind of failure has occurred in the logic circuit.
  • the extraction process prioritizes the extracted log information. If the log information is higher than the priority of the log information stored in the buffer with the specified memory capacity, the extracted log information is replaced with the log information with the lowest priority stored in the buffer. If the priority of the log information stored and extracted is lower than the priority of the log information stored in the buffer, the extracted log information is not stored in the buffer. It is possible.
  • log information is generated for log information collected for the logic circuit force in association with the board number and board mounting position on which the logic circuit is mounted.
  • Analysis information describing the information to be processed, the condition information for which the log information is valid, and the condition information for which the log information is invalid.
  • the system board is used as a unit, and failure analysis is performed using this analysis information as a unit of logic circuit.
  • the memory required for failure analysis can be greatly reduced as compared with the conventional failure analysis method using the system board as a unit.
  • analysis information necessary for failure analysis is defined in association with the board number on which the logic circuit is mounted and the mounting position on the board, and takes such a description format. Since failure analysis is performed using analysis information, when the same logic circuit is mounted on the system board, analysis information about these logic circuits can be shared.
  • the memory required for failure analysis can be greatly reduced as compared with the conventional failure analysis method using system boards as units.
  • the analysis information is not made resident in the storage means for storing the analysis information, and only the necessary analysis information is developed for the storage means at the time of failure occurrence.
  • the memory required for failure analysis is reduced as compared with the conventional failure analysis method in which analysis information is made resident in the memory means in a manner that includes even unused analysis information. It can be greatly reduced.
  • the present invention uses a failure analysis method in units of logic circuits, much less log information can be analyzed than in a conventional failure analysis method in units of system boards. It is sufficient to search for analysis information limited to a single logic circuit.
  • the processing time required for failure analysis can be greatly reduced as compared with the conventional failure analysis method using system boards as a unit.
  • a failure analysis method using a logic circuit as a unit is used, and further, what is described according to the specified contents is used as analysis information used for failure analysis.
  • the definition format of the analysis information input by the logic circuit designer can be made common, so that the input work can be integrated and a tool that supports the input work.
  • the creation of consistent analysis information by the logic circuit designer can be realized, and the development man-hours can be greatly reduced.
  • the definition format can reduce the difference in the recognition definition of the analysis information among the designers, the occurrence of a failure due to the difference in recognition. Can be prevented.
  • failure analysis is performed by checking log information indicating failure occurrence in accordance with the priority order defined in the analysis information.
  • a failure analysis impossible range due to lack of log information is a logic circuit unit.
  • FIG. 1 is a block diagram of the present invention.
  • FIG. 2 is a diagram showing an example of a configuration of failure analysis firmware.
  • FIG. 3 is an explanatory diagram of the data structure of a RAS-DB file.
  • FIG. 4 is a diagram showing an example of information defined in a common definition block.
  • FIG. 5 is a diagram showing an example of analysis information defined in a data definition block.
  • FIG. 6 is a diagram showing an example of a system board on which an ASIC is mounted. [7] It is a diagram showing an example of analysis information.
  • FIG. 8 is a diagram showing an example of analysis information.
  • FIG. 10 This is a processing flow executed by the main body log analysis process.
  • FIG. 11 This is a processing flow executed by the main body log analysis process.
  • FIG. 12 is an explanatory diagram of processing executed by the main body log analysis process.
  • FIG. 13 is an explanatory diagram of processing executed by the main body log analysis process. 14] An explanatory diagram of a failure analysis impossible range according to the present invention. 15] It is explanatory drawing of a prior art.
  • FIG. 1 illustrates the configuration of the present invention for performing this process.
  • 10 indicates N ASICs to be analyzed mounted in the information processing apparatus
  • 11 indicates a RAS-DB file
  • 12 indicates an analysis processing unit.
  • RAS Reliability Availability Serviceability
  • DB file 11 is defined for each ASICIO and stores analysis information necessary for analysis of failures occurring in that ASICIO, and is included in this analysis information. Stores analysis information necessary for analyzing the failure of the entire system.
  • the analysis processing unit 12 uses the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to calculate the analysis information stored in the RAS-DB file 11 to
  • the failure analysis of the entire system can be realized at the same time.
  • log information is collected from N ASICIOs when a failure occurs, and the analysis processing unit 12 performs processing to perform failure analysis on each of the collected log information. .
  • the failure analysis performed at this time includes not only the failure analysis in the ASICIO but also the failure analysis of the entire system according to the analysis information stored in the RAS-DB file 11.
  • the analysis information stored in the RAS-DB file 11 is used. By analyzing the failure that occurred in the ASIC10 and analyzing the failure, the failure analysis of the entire system can be realized at the same time.
  • the analysis processing unit 12 for performing the failure analysis characteristic of the present invention is specifically realized by firmware installed in the information processing apparatus, and is connected to the RAS-DB file 11! /
  • FIG. 2 shows an example of the configuration of the failure analysis firmware 20 that manages this failure analysis process.
  • FIG. 2 the same components as those shown in FIG. 1 are denoted by the same symbols.
  • the solid line in Fig. 2 indicates the flow of processing, and the broken line in Fig. 2 indicates the flow of data.
  • the failure analysis firmware 20 that manages the failure analysis processing of the present invention includes an interrupt handler 30, a main body log process 31, in addition to the RAS-DB file 11 described in FIG. And an analysis log file 32, a detailed log file 33, and a main body log analysis process 34.
  • the interrupt handler 30 receives an interrupt indicating that a failure has occurred from the ASIC 10.
  • the main body log process 31 receives the interrupt reception notification from the interrupt handler 30 and reads the log information from the ASIC 10 force.
  • the analysis log file 32 is configured on the ROM included in the failure analysis firmware 20 and stores the log information read by the main body log process 31 that is necessary for failure analysis.
  • the detailed log file 33 is configured on the ROM included in the failure analysis firmware 20, and stores the log information read by the main body log process 31 that is not required for failure analysis.
  • the body log analysis process 34 refers to the analysis information stored in the RAS-DB file 11 and performs failure analysis on the log information stored in the analysis log file 32.
  • the main body log analysis process 34 includes a buffer 40 having a specified capacity for storing log information as a result of failure analysis, and work memory prepared for failure analysis work. 41 will be provided.
  • RAS-DB definition file 50 and RAS-DB generator 51 are prepared and created by the designer of ASIC 10.
  • the RAS—DB generator 5 1 compiles the analysis definition and stores it in the RAS-DB file 11, so that it is stored in the RAS-DB file 11. It will be.
  • the main body log process 31 sends an interrupt reception notification from the interrupt handler 30. In response, log information is read from ASIC10.
  • the main body log process 31 stores the log information read from the ASIC 10 that is necessary for failure troubleshooting in the analysis log file 32, and the detailed log that is not required for failure analysis. After storing in file 33, it instructs the main unit log analysis process 34 to perform failure analysis.
  • the main unit log analysis process 34 Upon receiving this instruction, the main unit log analysis process 34 refers to the analysis information stored in the RAS-DB file 11 and performs failure analysis on the log information stored in the analysis log file 32. Report the analysis results to the report destination.
  • FIG. 3 illustrates the data structure of the RAS—DB file 11.
  • the RAS-DB file 11 is composed of a declaration unit 60 that declares file names and the like, and a definition unit 61 that defines specific contents of analysis information. 61 is composed of a data definition block 62 that defines the main body of analysis information, and a common definition block 63 that defines common values used in each item of the data definition block 62.
  • the value defined in the common definition block 63 is used as a default value when the item of the data definition block 62 is omitted. Now that the common definition block 63 is prepared, the ASIC10 designer who creates analysis information can omit the description of information that is commonly used in the analysis information to be created. .
  • FIG. 4 illustrates an example of information defined in the common definition block 63.
  • the type of the ASIC 10 'version number ASIC
  • the model type of the information processing device on which the ASIC 10 is installed MODEL
  • the number of the system board on which the ASIC 10 is installed BORAD
  • ASIC10 system board mounting position PACE
  • which hardware Function mode FUNCTION TYPE
  • IR indicating log type
  • ASIC interface direction DIRECTION
  • QU IET code QUIET
  • error event This indicates that it is possible to define each level (LEVEL), conversion rule number (CONVERT), and fault mark (MARK) indicating a replacement part.
  • FIG. 5 illustrates an example of analysis information defined in the data definition block 62.
  • ASIC type ASIC version number
  • model type function mode
  • mounting board bd
  • mounting position pi
  • IR code ir
  • scan address adrs
  • RCZRT display rcrt
  • priority pr
  • entry suppression condition dis
  • entry permission condition enb
  • event level lvl
  • message number msg
  • action type action
  • conversion rule number conv
  • fault marker By defining values for each item such as mark, the analysis information used for failure analysis of ASIC10 is defined.
  • this seventh analysis information is that the type of the ASIC 10 is "SC” and the information processing apparatus on which the ASIC 10 is mounted. Is applied to ASIC10 whose model type is "DC2", the number of the system board on which the ASIC10 is mounted is "0001", and the mounting position of the ASIC10 on the system board is "F”. This indicates that the analysis information is applied when a failure flag is set at the address bit position of “0373” in the log collected from the ASIC 10 according to “59”.
  • the seventh analysis information indicates that the bit of this log is an RC (Region Code) bit and is subject to failure analysis, and the priority of this log is " When “10”, “ZXCZRC—COPY—LOCK—CE” and! /, The bit is set! /, The analysis information becomes invalid, and "/ XC / RC_RETRY_LOCK_CE” t, the bit is set. ! If this analysis information is valid, this analysis information is valid. In the event of “alarm”, report the message with the message number 2A to the report destination, perform the “SC—FTL 1—INTF” t action, and use the replacement part as “ZCM U # 0 "When it comes to things, it's analysis information to describe! /, Show things! /,
  • the analysis information used in the present invention there is such another kind of log information collected from the ASIC 10 in association with the system board number on which the ASIC 10 is mounted and the mounting position on the board.
  • the analysis information for the log information is invalid, and when some other log information indicates the occurrence of a failure, the analysis information is valid according to the log information. If so, the configuration is defined so that the information to be processed when the log information is generated and the priority information of the log information are defined while being described under the conditions.
  • the log information collected from the ASIC 10 mounted on another system board is included, and when such other log information indicates the occurrence of failure, the analysis information becomes invalid. When such other log information indicates the occurrence of a failure, the analysis information is described as valid.
  • the analysis processing unit 12 uses the analysis information stored in the RAS-DB file 11 to analyze the failure that occurred in the ASIC 10, it automatically realizes the failure analysis of the entire system at the same time. become able to.
  • CPU # 0, 1, 2, and 3 each have a transmission port of the bus "/ AO / BUS—SND", and the checker power to check the transmission port has failed.
  • the flag shall be written in the flag area indicated by the signal name “ZAOZRC—OUT”, IR number “58” and address bit position “10”.
  • SC # 0 matches the bus port of CPU # 0.
  • the checker power that has a bus reception port and checks the reception port. When a failure occurs, a flag is written in the flag area indicated by the signal name “ZXOZRC—RSV”, IR number “10”, and address bit position “123”.
  • SC # 0 has a bus reception port "ZXlZBUS- RS V" according to the bus transmission port of CPU # 1, and checker power to check the reception port. If it occurs, the flag shall be written in the flag area indicated by the signal name “ZX1ZRC-RSV”, IR number “11”, and address bit position “123”.
  • SC # 0 has a bus reception port called "ZX2ZBUS- RS V" according to the bus transmission port of CPU # 2, and the checker power to check the reception port. If it occurs, the flag shall be written in the flag area indicated by the signal name “ZX2ZRC-RSV”, IR number “12” and address bit position “123”.
  • SC # 0 has a bus reception port "ZX3ZBUS- RS V" according to the bus transmission port of CPU # 3, and checker power to check the reception port. If it occurs, the flag shall be written in the flag area indicated by the signal name "ZX3ZRC-RSV", IR number "13", and address bit position "123".
  • SC # 0 is a flag area for writing a flag indicating the occurrence of an internal failure.
  • Signal name "ZAZRC-XX”, IR number "20” and address bit position "20 0” (2) Signal name “ZAZRC—YY”, IR number "50” and flag area pointed to by address bit position "044", and (3) Signal name "ZBZRC-XX”, IR number Four flags: “20” and the flag area pointed to by address bit position "300” and (4) the flag area pointed to by signal name "ZBZRC-YY", IR number "50” and address bit position "144” It is assumed that it has an area.
  • the RAS-DB file 11 stores the analysis information of CPU # 0, 1, 2, 3 as shown in FIG.
  • Fig. 7 defines the analysis information for the DC model and the analysis information for the FF model. The only difference between the two is that the displayed message is different.
  • the RAS-DB file 11 stores the analysis information of SC # 0 as shown in FIG.
  • entry suppression conditions are defined in the same system board
  • entry suppression conditions and entry permission conditions are not limited to the same system board. It may be defined between boards.
  • the analysis information stored in the RAS—DB file 11 is created by the ASIC 10 designer who creates the analysis definition stored in the RAS—DB definition file 50.
  • 51 compiles the analysis definition and stores it in RAS-DB file 11, it is stored in RAS-DB file 11.
  • an item value such as entry suppression (dis), entry permission condition (enb), or failure mark (mark) is used as a model of the information processing apparatus.
  • entry suppression diis
  • entry permission condition enb
  • failure mark mark
  • the RAS10 DB definition specific to the ASIC10 is defined for the designer of the ASIC10 (a general form of RASDB that does not depend on the information processing device model).
  • RAS-DB definition specific to ASIC10 is created by creating a definition) and checking the format.
  • the designer of ASIC 10 does not have to create separate analysis information for each model of the information processing apparatus.
  • main unit log analysis process 34 issues an analysis instruction for log information stored in the analysis log file 32 (log information indicating failure occurrence) from the main unit log process 31, first, the main step analysis process 34 In S 10, buffer 40 is cleared.
  • step S11 it is determined whether or not all log information stored in the analysis log file 32 has been processed.
  • step S11 When it is determined that all the log information stored in the analysis log file 32 has not been processed according to the determination process in step S11, the process proceeds to step S12, and the log file 32 for analysis has not been processed. Read one process log information.
  • step S13 the mouth read from RAS-DB file 11 in step S12 Get analysis information associated with group information.
  • step S14 it is determined whether or not an entry suppression condition is described in the analysis information acquired in step S13.
  • step S15 the log stored in the analysis log file 32 is stored. By referring to the information, it is judged whether or not the entry deterrence condition is satisfied.
  • step S16 when it is determined in step S16 that the entry suppression condition described in the analysis information acquired in step S13 is satisfied according to the determination process in step S15, the next log information should be processed. The process returns to step S11.
  • step S13 when the entry suppression condition described in the analysis information acquired in step S13 is satisfied, the analysis information becomes invalid, and there is no need to analyze the log information read in step S12. Therefore, the process returns to the process of step S 11 to process the next log information.
  • step S14 it is determined that the entry suppression condition is not described in the analysis information acquired in step S13, or in step S13 according to the determination process in step S16.
  • step S17 it is determined that the entry suppression condition described in the acquired analysis information is not satisfied.
  • step S17 When it is determined that the entry permission condition is described in the analysis information acquired in step S13 according to the determination process in step S17, the process proceeds to step S18, and the log stored in the analysis log file 32 is stored. By referring to the information, it is determined whether or not the entry permission condition is satisfied.
  • step S19 when it is determined in step S19 that the entry permission condition described in the analysis information acquired in step S13 is not satisfied according to the determination process in step S18, the next log information should be processed. The process returns to step S11.
  • step S13 That is, if the entry permission condition described in the analysis information acquired in step S13 is not satisfied, the analysis information becomes invalid, and the log read in step S12. Since there is no need to analyze the information, the process returns to the process of step S 11 where the next log information should be processed.
  • step S17 it is determined that the entry permission condition is not described in the analysis information acquired in step S13.
  • step S19 in step S13.
  • the process proceeds to step S20 to determine whether or not the buffer 40 is full.
  • step S13 determines whether or not the analysis information acquired in step S13 is finally valid. If it is determined that the analysis information acquired in step S13 is finally valid, the process proceeds to step S20 to determine whether or not the buffer 40 is full. .
  • step S20 When it is determined that the buffer 40 is not full in accordance with the determination process in step S20, the process proceeds to step S21, and the analysis information acquired in step S13 is stored in the buffer 40, so that it is read in step S12. After analyzing the log information, the process returns to the process of step S11 where the next log information should be processed.
  • step S20 when it is determined that the buffer 40 is full according to the determination processing in step S20, the process proceeds to step S22, and in accordance with the priority information described in the analysis information acquired in step S13, step S12 is performed. Identifies the priority of the log information read in.
  • step S23 according to the analysis information sorted at the end of the nota 40 (the one with the lowest priority is sorted), the mouth in which the analysis result is stored in the nota 40 is stored. Specify the lowest priority of the group information.
  • step S24 it is determined whether or not the priority specified in step S22 is lower than the priority specified in step S23.
  • step S24 the priority specified in step S22 is set to step When it is determined that the priority is lower than the priority specified in S23, the process returns to the process of step S11 where the next log information is to be processed.
  • step S12 when it is determined that the priority specified in step S22 is lower than the priority specified in step S23, the log information read in step S12 is stored in the buffer 40 and the analysis result is stored! As soon as it is determined that the log information is more important than the log information and no processing is performed, the processing returns to step S11.
  • step S22 when it is determined that the priority specified in step S22 is higher than the priority specified in step S23 according to the determination process in step S24, the process proceeds to step S25 and is added to the end of nota 40.
  • the analysis information acquired in step S13 in the buffer 40 in the form of replacement with the analysis information to be sorted (the one with the lowest priority is sorted), the log information read out in step S12 is stored. Perform analysis.
  • step S22 if it is determined that the priority specified in step S22 is higher than the priority specified in step S23, the log information read in step S12 is stored in the buffer 40 and the analysis result is stored!
  • the analysis result is stored in the buffer 40 by judging that it is more important than the log information having the lowest priority and replacing it with the log information.
  • step S26 the analysis information stored in the nota 40 is sorted according to the priority, and then the process returns to step S11 where the next log information is to be processed.
  • step S11 When it is determined that all log information stored in the analysis log file 32 has been processed in step S11 when the processing of step S11 to step S26 is repeated, Proceeding to S27, the analysis information stored in the buffer 40 is reported to the report destination as the analysis result of the failure analysis, and the process ends.
  • the main body log analysis process 34 issues an analysis instruction for log information stored in the analysis log file 32 (log information indicating failure occurrence) from the main body log process 31, As shown in Fig. 12, the analysis information associated with the log information is acquired from the RAS-DB file 11 according to the priority order, and stored in the buffer 40 so that the failure analysis is performed. is there.
  • the main body log analysis process 34 in order to reduce the capacity of the working memory 41, stores the RAS-DB file 11 at the time of system startup as shown in FIG. The analysis information to be stored is not read into the work memory 41 so that only the index table used for the index of the analysis information is written into the work memory 41.
  • the ASIC 10 is installed in the information processing apparatus that implements the process, and the index that has been read into the work memory 41 is acquired. According to the table, the analysis information applied to the ASIC 10 indicated by the acquired information is specified, and it is read from the RAS-DB file 11 and written to the work memory 41.
  • the working memory 41 required for failure analysis is compared with the conventional failure analysis method in which the analysis information is made resident in the working memory 41 so as to include even unused analysis information.
  • the capacity of can be greatly reduced.
  • the present invention does not perform failure analysis in units of system boards as in the prior art, but performs failure analysis in units of hardware circuits such as ASIC10 mounted on the system board. It is characterized by.
  • the impossible range of failure analysis due to lack of log information is a hard circuit unit.
  • a hardware failure flag cannot be collected from one ASIC 10 (for example, ASIC-D shown in the figure) mounted on the system board 100.
  • ASIC 10 for example, ASIC-D shown in the figure

Abstract

　論理回路の実装されるボード番号及びボード上搭載位置に対応付けて、その論理回路から収集するログ情報について、そのログ情報が発生するときに処理すべき情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を定義して、この解析情報を使って、論理回路を単位として故障解析を行うようにする。そして、この解析情報がさらにログ情報の優先度の情報を記述するようにすることで、この論理回路を単位とする故障解析の実現にあたって、重大な故障を漏れのない形で解析することを実現する。

Description

明 細 書
故障解析装置
技術分野
[0001] 本発明は、複数の論理回路を搭載する複数のボードを具備する情報処理装置に 実装されて、それらの論理回路にどのような故障が発生したのかを解析する故障解 析装置に関し、特に、メモリ資源の削減、処理の高速ィ匕および開発工数の削減を実 現するとともに、重大な故障を漏れなく解析することを実現し、さらに、解析不可能範 囲を小さくすることを実現する故障解析装置に関する。
[0002] 今日、高密度に集積化され複雑化した ASIC (Application Specific Integrated Circ uit：特定用途向け IC)などのような LSIを搭載する情報処理装置においては、停止 時間や復旧時間の削減のために、 LSIに故障が発生するときに、その正確な故障箇 所を自律的に速やかに判定するとともに、その影響範囲を自律的に速やかに判定す る故障解析機能の実現が強く求められている。
[0003] LSIの集積ィ匕が進むことで、 LSIの故障解析に必要となる解析情報は増加の一途 を迪つており、それらの大量の解析情報の入力作業が必要となっている。し力も、各 LSIの設計者と LSIを搭載するシステムの設計者と LSIの故障解析を行うファームゥ エアの設計者との間に意思の疎通が避けられないことから、そのような故障解析機能 を実現するためには膨大な開発工数が要求されることになる。
[0004] これから、そのような故障解析機能を効率的に実現するための新たな技術の構築 が叫ばれている。
背景技術
[0005] ASICを搭載する情報処理装置では、通常、複数種類の複数の ASICを搭載する システムボードを複数枚具備することになる。
[0006] これから、従来では、 ASICに故障が発生する場合に、各システムボード用に用意 する 1枚又は数枚の解析用テーブルを用いてシステムボードを単位にして故障解析 を行い、そのシステムボードを単位にして行った解析結果を集めて、システム全体と しての解析結果を導出するようにして ヽた。 [0007] 図 15に、従来技術の構成を図示する。
[0008] ここで、図 15中、 100は情報処理装置内に実装される解析対象となる複数のシステ ムボードを示し、 110はボード解析情報テーブルを示し、 120はシステム解析情報テ 一ブルを示し、 130は解析処理部を示す。
[0009] このシステムボード 100には、通常、複数種類の複数の ASICが搭載されて!、る。
ボード解析情報テーブル 110は、システムボード 100毎に定義されて、そのシステム ボード 100に搭載される ASICに発生した故障の解析に必要となる情報を記憶する。 システム解析情報テーブル 120は、システムボード 100間の故障解析に必要となる 情報を記憶する。解析処理部 130は、システムボード 100毎の故障解析を行う解析 処理機能と、システム全体の故障解析を行う解析処理機能とで構成される。
[0010] ここで、解析処理部 130については、具体的には、情報処理装置に実装されるファ ームウェア（以下、監視ファームウェアと称することがある）により実現され、ボード解析 情報テーブル 110およびシステム解析情報テーブル 120については、そのファーム ウェアの持つメモリ上に展開されることになる。
[0011] このように構成される従来技術では、システムボード 100を単位にして ASICのログ 情報 (後述するハード故障フラグ)を収集して、システムボード 100毎に定義されるボ ード解析情報テーブル 110を使ってシステムボード 100につ!/、ての故障解析を行う ことで、そのシステムボード 100で発生した故障を特定する。
[0012] そして、このシステムボード 100についての故障解析を終了すると、続いて、システ ム解析情報テーブル 120を使い、例えば、受信側で検出される故障は送信側で発 生した故障に伴って発生することを考慮して、受信側で検出される故障については 故障解析から除外すると ヽうようなシステム全体の故障解析を行うことで、最終的にど のような故障が発生したのかを特定する。
[0013] このようにして、従来技術では、 ASICに故障が発生する場合に、先ず最初に、シス テムボード 100を単位にして故障解析を行い、続いて、そのシステムボード 100を単 位にして行った解析結果を集めて、システム全体としての解析結果を導出するように していた。
[0014] この故障解析を行うときに必要となるボード解析情報テーブル 110については、 AS ICの設計者やシステムボード 100の設計者が作成し、システム解析情報テーブル 12 0については、システムの設計者やシステムボード 100の設計者が作成することにな る。
[0015] すなわち、従来技術では、図 16に示すように、ボード解析情報テーブル 110のコン パイル前のデータであるボード解析定義については、 ASICの種類毎に、各 ASICの 設計者が独自に、あるいはシステムボード 100の設計者と協議しながら個別に作成 する。そして、システムをとりまとめるシステム設計者が独自に、あるいはシステムボー ド 100の設計者と協議しながら、それらのボード解析定義を編集することで、システム 解析情報テーブル 120のコンパイル前のデータであるシステム解析定義を作成する 。そして、このようにして作成したボード解析定義とシステム解析定義とを監視ファー ムウェアが取り込める形にコンパイルすることで、ボード解析情報テーブル 110とシス テム解析情報テーブル 120とを作成するようにして 、た。
[0016] 解析処理部 130は、このようにして作成されたボード解析情報テーブル 110を使つ てシステムボード 100についての故障解析を行うことになる力 この場合、図 17に示 すように、 ASIC力も収集するハード故障フラグ (ハード故障時に故障原因を残すノヽ ード内フラグ群)を、故障解析で確保する故障フラグバッファに格納していくことで、ど のような故障が発生したのかを特定するという処理を行うことになる。
[0017] この処理を行う場合、従来の解析処理部 130では、先行して検出されたノヽード故障 フラグを故障フラグバッファに格納していって、故障フラグバッファが満杯になる場合 には、それ以降に検出されたハード故障フラグについては破棄するようにして、故障 フラグバッファにどのようなハード故障フラグが格納されているのかを抽出することに より、どのような故障が発生したのかを特定するようにして ヽた。
[0018] すなわち、従来の解析処理部 130では、ハード故障フラグが大量に立った場合に は、一定の検出個数をもって故障解析を中断して、そこまでの故障解析結果を報告 するようにして 、たのである。
[0019] また、解析処理部 130は、図 16に示すような方法により作成されたボード解析情報 テーブル 110およびシステム解析情報テーブル 120を使って故障解析を行うことに なるが、従来の解析処理部 130では、図 18に示すように、その故障解析がシステム に異常が発生した場合に実行する一時的な処理であるのにもかかわらず、その故障 解析で使用する情報であるボード解析情報テーブル 110およびシステム解析情報テ 一ブル 120については、システムの起動直後に監視ファームウェアのメモリに常駐さ せるようにしていた。
[0020] ここで、図 18中に示すメモリ空間は、監視ファームウェアのシステムメモリ空間を示 し、図 18中に示す解析情報は、故障解析で使用する情報であるボード解析情報テ 一ブル 110およびシステム解析情報テーブル 120を示し、図 18中に示す解析ワーク は、監視ファームウェアが故障解析で用いる作業用メモリ域を示している。
[0021] 以上に説明したように、従来技術では、 ASICに故障が発生する場合に、先ず最初 に、システムボード 100を単位にして故障解析を行い、続いて、そのシステムボード 1 00を単位にして行った解析結果を集めて、システム全体としての解析結果を導出す るようにしていた。
[0022] このように、従来技術では、システムボード 100を単位にして故障解析を行って 、る こと力 、図 19に示すように、例えば、システムボード 100に搭載されるある一つの A SIC (例えば、図中に示す ASIC— D)力もハード故障フラグを収集できな 、ような事 態が起こると、そのシステムボード 100についての故障解析全体が不可能となってし まうことになる。
発明の開示
発明が解決しょうとする課題
[0023] このような従来技術に従っていると、次のような問題がある。
[0024] (1)メモリ資源、処理時間についての問題
システムボード 100を単位とする従来の故障解析方法に従っていると、故障解析を 行うときに、システムボード 100にかかる全てのハード故障フラグを故障解析に用いる 作業用メモリ域（図 18に示す解析ワーク）に書き込まなくてはならないことになる。
[0025] しかるに、システムボード 100内には数個力も数十個の ASICが搭載されるため、シ ステムボード 100全体でのハード故障フラグ数は非常に多い。
[0026] これから、システムボード 100を単位とする従来の故障解析方法に従っていると、故 障解析に要するメモリが大きくなるという問題がある。 [0027] し力も、システムボード 100内には同種の ASICが搭載されることがある力 システム ボード 100を単位とする従来の故障解析方法に従っていると、ボード解析情報テー ブル 110はシステムボード 100を単位にして生成されることから、同じ ASICのボード 解析情報テーブル 110が冗長に含まれることになる。これも大きなメモリ資源を要求 される原因となっている。
[0028] すなわち、同じ ASICであっても、その搭載位置に応じてボード解析情報テーブル 110は異なるものとなる力 システムボード 100を単位とする従来の故障解析方法で は、ボード解析情報テーブル 110に ASICの搭載位置に応じた解析定義を記述する t 、う構成を採って ヽな 、ので、これらのボード解析情報テーブル 110を共通化する ことができない。これから、同じ ASICのボード解析情報テーブル 110が冗長に含ま れることになることで大きなメモリ資源を要求されていたのである。
[0029] しかも、システムボード 100を単位とする従来の故障解析方法に従っていると、図 1 8で説明したように、故障解析がシステムに故障が発生した場合に実行する一時的な 処理であるのにもかかわらず、その故障解析で使用する情報であるボード解析情報 テーブル 110およびシステム解析情報テーブル 120につ!/、ては、システムの起動直 後に監視ファームウェアのメモリに常駐させるようにして 、た。
[0030] このときに常駐させるボード解析情報テーブル 110およびシステム解析情報テープ ル 120は、情報処理装置に搭載される ASICの種類や版数が予め分力 ている場合 には、それに応じた数で済むものの、予め分力つていない場合には、情報処理装置 に搭載される可能性のあるものの全てを常駐させる必要があることから、その常駐に 大きなメモリ量を要求されることになる。
[0031] この点力もしても、システムボード 100を単位とする従来の故障解析方法に従って V、ると、大きなメモリ資源を要求されることになると!/、う問題がある。
[0032] また、 1つの ASIC当たり数千力 数万のハード故障フラグを搭載するため、システ ムボード 100全体では数十万個のハード故障フラグの解析となり、し力も、ボード解 析情報テーブル 110もシステムボード 100を単位にして持つことから、その検索に多 大な計算量を要することになる。
[0033] これから、システムボード 100を単位とする従来の故障解析方法に従っていると、故 障解析に膨大な処理時間を要するという問題がある。
[0034] (2)開発工数にっ 、て
システムボード 100を単位とする従来の故障解析方法では、ボード解析情報テー ブル 110とシステム解析情報テーブル 120と!、う 2つのテーブルを使って故障解析を 行うことになるが、図 16で説明したように、ボード解析情報テーブル 110については 、 ASICの設計者やシステムボード 100の設計者が作成し、システム解析情報テープ ル 120については、システムの設計者やシステムボード 100の設計者が作成すること になる。
[0035] これから、システムボード 100を単位とする従来の故障解析方法に従っていると、こ れらのテーブル 110, 120の初期設計時や変更設計時に、それぞれに工数が発生 して各設計者に負担を強 、ると!/、う問題がある。
[0036] し力も、各設計者の間で解析情報の記述定義の認識に違いがでることが避けられ ず、これから、システムボード 100を単位とする従来の故障解析方法に従っていると、 この認識の違 、〖こよる障害を発生する 、う問題もある。
[0037] (3)解析漏れについて
従来の故障解析方法では、図 17で説明したように、ハード故障フラグが大量に立 つた場合には、故障フラグバッファに格納できなくなることに合わせて、一定の検出個 数をもって故障解析を中断するようにしていた。
[0038] これから、従来の故障解析方法に従っていると、故障フラグバッファが満杯になった 後に検出される、より重大な故障を見逃してしまうという問題がある。
[0039] (4)解析不可能範囲について
システムボード 100を単位とする従来の故障解析方法では、図 19で説明したように 、何らかの二次的な問題で、システムボード 100に搭載されるある一つの ASICから でもハード故障フラグを収集できな 、ような事態が起こると、そのシステムボード 100 につ 、ての故障解析全体が不可能になってしまうと 、う問題がある。
[0040] 本発明は力かる事情に鑑みてなされたものであって、情報処理装置に搭載される L SIのような論理回路に発生する故障を解析するという機能を実現するときに、メモリ資 源の削減、処理の高速ィ匕および開発工数の削減を実現するとともに、重大な故障を 漏れなく解析することを実現し、さらに、解析不可能範囲を小さくすることを実現する 新たな故障解析技術の提供を目的とする。
課題を解決するための手段
[0041] この目的を達成するために、本発明の故障解析装置は、複数の論理回路を搭載す る複数のボードを具備する情報処理装置に実装されて、それらの論理回路にどのよ うな故障が発生したのかを解析する処理を行うために、（1)論理回路の搭載されるボ ード番号及びボード上搭載位置に対応付けて、その論理回路力も収集するログ情報 について、そのログ情報が発生するときに処理すべき情報と、そのログ情報の優先度 の情報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なも のとなる条件の情報とについて記述する解析情報を記憶する記憶手段と、（2)論理 回路の故障発生時に、論理回路から故障発生を表示するログ情報を収集する収集 手段と、（3)収集手段の収集したログ情報と、記憶手段に記憶される解析情報とに基 づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えるよ うに構成する。
[0042] この構成を採るときに、さらに、（4)装置起動時に、解析対象となる情報処理装置に 搭載される可能性のある論理回路に適用される解析情報の索引に用いられる索引 情報を、記憶手段に記憶させる第 1の展開手段と、（5)論理回路の故障発生時に、 解析対象となる情報処理装置に搭載される論理回路の情報と索引情報とに従って、 解析手段の解析に必要となる解析情報を特定して、その特定した解析情報を記憶手 段に記憶させる第 2の展開手段とを備えることがある。
[0043] そして、この構成を採るときに、記憶手段は、ログ情報が有効なものとなる条件の情 報として、どのログ情報が故障発生を示す場合という条件の情報について記述するこ とがあり、また、ログ情報が無効なものとなる条件の情報として、どのログ情報が故障 発生を示す場合と ヽぅ条件の情報にっ ヽて記述することがある。
[0044] このように構成される本発明の故障解析装置では、装置起動時に、解析情報の索 引に用いられる索引情報のみを記憶手段に記憶させる。
[0045] この後、情報処理装置が処理を開始するので、その処理の実行中に、ある論理回 路に故障が発生すると、各論理回路から故障発生を表示するログ情報を収集する。 [0046] このとき、そのログ情報の収集に合わせて、情報処理装置でどのような論理回路が 用いられているのかという情報を取得して、記憶手段に記憶される索引情報に従って 、その取得した情報の指す論理回路に適用される解析情報を特定し、その特定した 解析情報を記憶手段に記憶させる。
[0047] 続ヽて、記憶手段の記憶する解析情報を参照することで、収集した故障発生を表 示するログ情報の内、解析情報に記述される条件情報に基づいて有効となるものを 抽出することで、論理回路にどのような故障が発生したのかを解析する。
[0048] このとき、解析情報に記述される優先度情報に基づいて、優先度の高いログ情報を 抽出することで、重大な故障の解析漏れが起こらな！/ヽようにする。
[0049] この抽出処理は、例えば、収集した故障発生を表示するログ情報の内、解析情報 に記述される条件情報に基づいて有効となるログ情報を抽出すると、その抽出した口 グ情報の優先度が規定のメモリ容量を持つバッファに格納されるログ情報の優先度 よりも高い場合には、そのノ ッファに格納される最も優先度の低いログ情報と入れ替 える形でその抽出したログ情報を格納し、その抽出したログ情報の優先度がそのバッ ファに格納されるログ情報の優先度よりも低い場合には、その抽出したログ情報をバ ッファに格納しな 、ようにすることで行うことが可能である。
[0050] このようにして、本発明の故障解析装置では、論理回路の搭載されるボード番号及 びボード上搭載位置に対応付けて、その論理回路力 収集するログ情報について、 そのログ情報が発生するときに処理すべき情報と、そのログ情報が有効なものとなる 条件の情報と、そのログ情報が無効なものとなる条件の情報とについて記述する解 析情報を定義して、従来技術ではシステムボードを単位として行って 、た故障解析を 、この解析情報を使って、論理回路を単位として行うようにするという構成を採るので ある。
[0051] そして、この解析情報がさらにログ情報の優先度の情報を記述するようにすることで 、この論理回路を単位とする故障解析の実現にあたって、重大な故障を漏れのない 形で解析するようにすると ヽぅ構成を採るのである。
発明の効果
[0052] 本発明によれば、次のような効果を実現できるようになる。 [0053] (1)メモリ資源、処理時間についての効果
本発明では、論理回路を単位とする故障解析方法を用いるので、故障解析を行う ベく故障発生を表示するログ情報を作業用メモリに書き込むときに、システムボードを 単位とする従来の故障解析方法に比べて、大幅に少ない量のログ情報を書き込め ば足りることになる。
[0054] このようにして、本発明によれば、システムボードを単位とする従来の故障解析方法 に比べて、故障解析に要するメモリを大幅に削減できるようになる。
[0055] しカゝも、本発明では、論理回路の搭載されるボード番号及びボード上搭載位置に 対応付ける形で故障解析に必要となる解析情報を定義して、そのような記載形式をと る解析情報を用いて故障解析を行うので、システムボードに同じ論理回路が搭載さ れる場合に、それらの論理回路についての解析情報を共通化できるようになる。
[0056] この点力 しても、本発明によれば、システムボードを単位とする従来の故障解析 方法に比べて、故障解析に要するメモリを大幅に削減できるようになる。
[0057] し力も、本発明では、解析情報を記憶する記憶手段に対して解析情報を常駐させ ないようにして、故障発生時点に、記憶手段に対して必要な解析情報のみを展開す るようにする。
[0058] この点力 しても、本発明によれば、使用しない解析情報までも含める形で記憶手 段に解析情報を常駐させるという従来の故障解析方法に比べて、故障解析に要する メモリを大幅に削減できるようになる。
[0059] そして、本発明では、論理回路を単位とする故障解析方法を用いるので、システム ボードを単位とする従来の故障解析方法に比べて、大幅に少な!ヽ量のログ情報を解 析すれば足りることになり、し力も、単一の論理回路に限定した解析情報の検索を行 うことで足りること〖こなる。
[0060] このようにして、本発明によれば、システムボードを単位とする従来の故障解析方法 に比べて、故障解析に要する処理時間を大幅に削減できるようになる。
[0061] (2)開発工数にっ 、て
本発明では、論理回路を単位とする故障解析方法を用いており、さらに、故障解析 に用いる解析情報として、規定の内容にっ 、て記述するものを用いるようにする。 [0062] これから、本発明によれば、論理回路の設計者の入力する解析情報の定義フォー マットを共通化できるようになるので、その入力作業を統合ィ匕でき、その入力作業を サポートするツールを用いることで、論理回路の設計者による一貫した解析情報の作 成を実現できるようになり、開発工数を大幅に削減できるようになる。
[0063] し力も、本発明によれば、定義フォーマットによって、各設計者の間における解析情 報の記述定義の認識の違 、を小さくできるようになるので、この認識の違いによる障 害の発生を防止できるようになる。
[0064] (3)解析漏れについて
本発明では、解析情報に定義された優先度の順番に従って、故障発生を表示する ログ情報をチェックすることで故障解析を行うようにする。
[0065] これから、本発明によれば、より重大な故障を見逃してしまうというような不都合の発 生を防止できるようになる。
[0066] (4)解析不可能範囲について
本発明では、論理回路を単位とする故障解析方法を用いるので、ログ情報の欠落 による故障解析の不可能範囲が論理回路単位となる。
[0067] これから、本発明によれば、従来技術に比べて、故障解析の不可能範囲を大幅に /J、さくすることができるよう〖こなる。
[0068] このようにして、本発明によれば、情報処理装置に搭載される LSIのような論理回路 に発生する故障を解析するという機能を実現するときに、メモリ資源の削減、処理の 高速ィ匕および開発工数の削減を実現できるようになるとともに、重大な故障を漏れな く解析することを実現できるようになり、さらに、解析不可能範囲を小さくすることを実 現でさるよう〖こなる。
図面の簡単な説明
[0069] [図 1]本発明の構成図である。
[図 2]故障解析用ファームウェアの構成の一例を示す図である。
[図 3]RAS— DBファイルのデータ構造の説明図である。
[図 4]共通定義ブロックで定義される情報の一例を示す図である。
[図 5]データ定義ブロックで定義される解析情報の一例を示す図である。 [図 6]ASICを搭載するシステムボードの一例を示す図である。 圆 7]解析情報の一例を示す図である。
圆 8]解析情報の一例を示す図である。
圆 9]解析情報の作成方法の説明図である。
[図 10]本体ログ解析プロセスの実行する処理フローである。
[図 11]本体ログ解析プロセスの実行する処理フローである。
[図 12]本体ログ解析プロセスの実行する処理の説明図である。
[図 13]本体ログ解析プロセスの実行する処理の説明図である。 圆 14]本発明による故障解析不可能範囲の説明図である。 圆 15]従来技術の説明図である。
圆 16]従来技術の説明図である。
圆 17]従来技術の説明図である。
圆 18]従来技術の説明図である。
圆 19]従来技術の説明図である。
符号の説明
10 ASIC
11 RAS— DBファイル
12 解析処理部
20 故障解析用ファームウェア
30 割込ハンドラ
31 本体ログプロセス
32 解析用ログファイル
33 詳細ログファイル
34 本体ログ解析プロセス
40 ノ ッファ
41 作業用メモリ
50 RAS— DB定義ファイル
51 RAS DBジェネレータ 60 宣言部
61 定義部
62 データ定義ブロック
63 共通定義ブロック
発明を実施するための最良の形態
[0071] 以下、実施の形態に従って本発明を詳細に説明する。
[0072] 本発明では、 ASICを搭載する情報処理装置において、 ASICに故障が発生する 場合に、 ASICを単位にして故障解析を行うことで、システム全体としての解析結果を 導出するという処理を行い、これにより、従来のシステムボードを単位にして行ってい た故障解析で必要とされていたシステム全体の故障解析を不要にすることを実現す る。
[0073] 図 1に、この処理を行う本発明の構成を図示する。
[0074] ここで、図 1中、 10は情報処理装置内に搭載される解析対象となる N個の ASICを 示し、 11は RAS— DBファイルを示し、 12は解析処理部を示す。
[0075] RAS(Reliability Availability Serviceability)—DBファイル 11は、 ASICIO毎に定 義されて、その ASICIOに発生した故障の解析に必要となる解析情報を記憶すると ともに、この解析情報に含める形で、システム全体の故障の解析に必要となる解析情 報を記憶する。
[0076] 解析処理部 12は、 RAS— DBファイル 11に格納される解析情報を使って、 ASIC1
0に発生した故障を解析するとともに、その故障解析を行うことで、システム全体の故 障解析を同時に実現する。
[0077] このように構成される本発明では、故障発生時に、 N個の ASICIOからログ情報を 収集し、解析処理部 12は、その収集したログ情報のそれぞれについて故障解析を 行うように処理する。
[0078] このとき行う故障解析は、 RAS— DBファイル 11に格納される解析情報に従って、 ASICIO内の故障解析にとどまらずに、システム全体の故障解析までも含めたものと なる。
[0079] このようにして、本発明では、 RAS— DBファイル 11に格納される解析情報を使つ て、 ASIC10に発生した故障を解析するとともに、その故障解析を行うことで、システ ム全体の故障解析を同時に実現するのである。
[0080] この本発明に特徴的な故障解析を行う解析処理部 12は、具体的には、情報処理 装置に実装されるファームウェアにより実現され、 RAS— DBファイル 11につ!/、ては
、そのファームウェアの備える ROM上に記憶されることになる。
[0081] 図 2に、この故障解析処理を司る故障解析用ファームウェア 20の構成の一例を図 示する。
[0082] ここで、図 2中、図 1で示したものと同じものについては同一の記号で示してある。ま 、図 2中に示す実線は処理の流れを示し、図 2中に示す破線はデータの流れを示し ている。
[0083] 図 2に示すように、本発明の故障解析処理を司る故障解析用ファームウェア 20は、 図 1で説明した RAS— DBファイル 11に加えて、割込ハンドラ 30と、本体ログプロセ ス 31と、解析用ログファイル 32と、詳細ログファイル 33と、本体ログ解析プロセス 34と を備える。
[0084] 割込ハンドラ 30は、 ASIC10から故障が発生したことを示す割り込みを受信する。
本体ログプロセス 31は、割込ハンドラ 30からの割込受信通知を受けて、 ASIC10力 らログ情報を読み出す。解析用ログファイル 32は、故障解析用ファームウェア 20の 備える ROM上に構成されて、本体ログプロセス 31の読み出したログ情報の内の故 障解析に必要となるものを格納する。詳細ログファイル 33は、故障解析用ファームゥ エア 20の備える ROM上に構成されて、本体ログプロセス 31の読み出したログ情報 の内の故障解析に必要とならないものを格納する。本体ログ解析プロセス 34は、 RA S— DBファイル 11に格納される解析情報を参照して、解析用ログファイル 32に格納 されるログ情報について故障解析を行う。
[0085] ここで、本体ログ解析プロセス 34には、故障解析の結果となるログ情報を格納する 規定の容量の大きさを持つバッファ 40と、故障解析の作業用に用意される作業用メ モリ 41とが備えられることになる。
[0086] また、 RAS— DBファイル 11に格納される解析情報については、 RAS— DB定義フ アイル 50と RAS - DBジェネレータ 51とが用意されて、 ASIC 10の設計者の作成し た解析定義が RAS— DB定義ファイル 50に格納されると、 RAS— DBジェネレータ 5 1がその解析定義をコンパイルして RAS - DBファイル 11に格納することで、 RAS - DBファイル 11に格納されることになる。
[0087] このように構成される故障解析用ファームウェア 20では、割込ハンドラ 30が ASIC1 0から故障発生の割り込みを受信すると、本体ログプロセス 31は、割込ハンドラ 30か らの割込受信通知を受けて、 ASIC10からログ情報を読み出す。
[0088] 続いて、本体ログプロセス 31は、 ASIC10から読み出したログ情報の内の故障解 祈に必要となるものを解析用ログファイル 32に格納し、故障解析に必要とならないも のを詳細ログファイル 33に格納してから、本体ログ解析プロセス 34に対して故障解 析を行うことを指示する。
[0089] この指示を受けて、本体ログ解析プロセス 34は、 RAS— DBファイル 11に格納され る解析情報を参照して、解析用ログファイル 32に格納されるログ情報について故障 解析を行い、その解析結果を報告先に報告する。
[0090] 次に、 RAS— DBファイル 11に格納される解析情報にっ 、て説明する。
[0091] 図 3に、 RAS— DBファイル 11のデータ構造を図示する。
[0092] RAS— DBファイル 11は、図 3に示すように、ファイル名などについて宣言する宣言 部 60と、解析情報の具体的な内容について定義する定義部 61とで構成され、さらに 、定義部 61は、解析情報の本体について定義するデータ定義ブロック 62と、データ 定義ブロック 62の各項目で用いる共通の値につ!、て定義する共通定義ブロック 63と で構成される。
[0093] 共通定義ブロック 63で定義した値については、データ定義ブロック 62の項目を省 略した場合のデフォルト値として使用されることになる。これから、共通定義ブロック 6 3が用意されることで、解析情報を作成する ASIC10の設計者は、作成する解析情 報で共通的に使用する情報については、その記載を省略することが可能になる。
[0094] 図 4に、共通定義ブロック 63で定義される情報の一例を図示する。
[0095] 図 4に示す共通定義ブロック 63では、 ASIC10の種別'版数 (ASIC)、 ASIC10を 搭載する情報処理装置のモデル種別 (MODEL), ASIC10を搭載するシステムボー ドの番号（BORAD)、 ASIC10のシステムボード上の搭載位置（PLACE)、どのハード 機能が有効かを示す機能モード（FUNCTION TYPE), ASICスキャンループの IRコ ード（IR:ログの種類を示すもの）、 ASIC間インタフェースの方向（DIRECTION), QU IETコード（QUIET)、エラー事象のレベル（LEVEL)、変換ルールの番号（CONVERT )、交換部品を示す故障マーク (MARK)のそれぞれにつ ヽて定義可能であることを示 している。
[0096] 図 5に、データ定義ブロック 62で定義される解析情報の一例を図示する。
[0097] データ定義ブロック 62では、 ASIC種別、 ASIC版数、モデル種別、機能モード、搭 載ボード (bd)、搭載位置（pi)、 IRコード（ir)、スキャンアドレス（adrs)、 RCZRT表示 (rcrt)、優先度 (pr)、エントリ抑止条件 (dis)、エントリ許可条件 (enb)、事象レベル (lvl) 、メッセージ番号（msg)、アクション種別（action)、変換ルール番号（conv)、故障マー ク（mark)などの各項目について値を定義することで、 ASIC10の故障解析に用いる 解析情報を定義すると ヽぅ構成を採る。
[0098] ここで、図 5に示すデータ定義ブロック 62の例では、 ASIC版数 (ver)、 ASIC10を 搭載する情報処理装置のモデル種別 (mdl)、どのハード機能が有効かを示す機能モ ード (fonc)については共通定義ブロック 63で定義されていることで、データ定義ブロ ック 62ではその定義が省略されて 、ることを想定して 、る。
[0099] 図 5に示す第 7番目の解析情報を具体例にして説明するならば、この第 7番目の解 析情報は、 ASIC10の種別が" SC"で、その ASIC10を搭載する情報処理装置のモ デル種別が" DC2"で、その ASIC10を搭載するシステムボードの番号が" 0001"で 、その ASIC10のシステムボード上の搭載位置が" F"であるという ASIC10に適用さ れて、 IR番号" 59"に従ってその ASIC10から収集されたログの中の" 0373"のアド レスビット位置に故障フラグが立っている場合に適用される解析情報であるということ を示している。
[0100] そして、この第 7番目の解析情報は、このログのビットが RC (Region Code)ビットであ ることで故障解析の対象となるものであることを示し、このログの優先度が" 10"で、 " ZXCZRC— COPY— LOCK— CE "と!/、うビットが立って!/、た場合にはこの解析情 報が無効となり、 "/XC/RC_RETRY_LOCK_CE" t 、うビットが立って！/、た 場合にはこの解析情報が有効となるもので、この解析情報が有効である場合には、 " アラーム"という事象で、 2Aというメッセージ番号のメッセージを報告先に報告し、 "S C— FTL 1— INTF" t ヽぅァクションを行って、そのときに用!、る交換部品は "ZCM U # 0"になると 、うことにつ 、て記述する解析情報であると!/、うことを示して！/、る。
[0101] このように、本発明で用いられる解析情報では、 ASIC10の搭載されるシステムボ ード番号及びそのボード上搭載位置に対応付けて、その ASIC10から収集するログ 情報について、こういう別のあるログ情報が故障発生を表示しているときにはそのログ 情報についての解析情報が無効となり、こういう別のあるログ情報が故障発生を表示 して 、るときにはそのログ情報にっ 、ての解析情報が有効となると 、う条件にっ 、て 記述しつつ、そのログ情報が発生するときに処理すべき情報と、そのログ情報の優先 度の情報とについて定義するという構成を採る。
[0102] このときに、他のシステムボードに搭載される ASIC10から収集されるログ情報につ いても含める形で、こういう別のあるログ情報が故障発生を表示しているときには解析 情報が無効となり、こういう別のあるログ情報が故障発生を表示しているときには解析 情報が有効となると 、うことにつ 、て記述して 、る。
[0103] この記述形式に従って、解析処理部 12が RAS— DBファイル 11に格納される解析 情報を使って ASIC10に発生した故障を解析すると、自ずとシステム全体の故障解 析につ ヽても同時に実現できるようになる。
[0104] 次に、図 6に示す CMU#0というシステムボードを具体例にして、このことが実現で きるようになると 、うことにつ 、て説明する。
[0105] 図 6に示す CMU#0というシステムボードでは、 CPU #0という ASIC 10と、 CPU
# 1という ASIC10と、じ？11# 2とぃぅ八31じ10と、 CPU# 3という ASIC10と、 SC# 0と!、う 5つの ASIC10が搭載されて!、ることを想定して 、る。
[0106] ここで、 CPU#0, 1, 2, 3は、それぞれ"/ AO/BUS— SND"というバスの送信 口を持ち、その送信口をチェックするチェッカ力 その送信口に故障が発生した場合 には、信号名" ZAOZRC— OUT"、 IR番号" 58"およびアドレスビット位置" 10"の 指すフラグ域にフラグを書き込むものとする。
[0107] また、 SC # 0は、 CPU # 0の持つバスの送信口に合わせて" ZXOZBUS— RSV
"というバスの受信口を持ち、その受信口をチェックするチェッカ力 その受信口に故 障が発生した場合には、信号名" ZXOZRC— RSV"、 IR番号" 10"およびアドレス ビット位置" 123"の指すフラグ域にフラグを書き込むものとする。
[0108] そして、 SC # 0は、 CPU # 1の持つバスの送信口に合わせて" ZXlZBUS— RS V"というバスの受信口を持ち、その受信口をチェックするチェッカ力 その受信口に 故障が発生した場合には、信号名" ZX1ZRC— RSV"、 IR番号" 11"およびァドレ スビット位置" 123"の指すフラグ域にフラグを書き込むものとする。
[0109] そして、 SC # 0は、 CPU # 2の持つバスの送信口に合わせて" ZX2ZBUS— RS V"というバスの受信口を持ち、その受信口をチェックするチェッカ力 その受信口に 故障が発生した場合には、信号名" ZX2ZRC— RSV"、 IR番号" 12"およびァドレ スビット位置" 123"の指すフラグ域にフラグを書き込むものとする。
[0110] そして、 SC # 0は、 CPU # 3の持つバスの送信口に合わせて" ZX3ZBUS— RS V"というバスの受信口を持ち、その受信口をチェックするチェッカ力 その受信口に 故障が発生した場合には、信号名" ZX3ZRC— RSV"、 IR番号" 13"およびァドレ スビット位置" 123"の指すフラグ域にフラグを書き込むものとする。
[0111] さらに、 SC # 0は、内部における故障の発生を示すフラグを書き込むためのフラグ 域として、（1)信号名" ZAZRC— XX"、 IR番号" 20"およびアドレスビット位置" 20 0"の指すフラグ域と、（2)信号名" ZAZRC— YY"、 IR番号" 50"およびアドレスビ ット位置" 044"の指すフラグ域と、（3)信号名" ZBZRC— XX"、 IR番号" 20"およ びアドレスビット位置" 300"の指すフラグ域と、（4)信号名" ZBZRC— YY"、 IR番 号" 50"およびアドレスビット位置" 144"の指すフラグ域という 4つのフラグ域を持つこ とを想定している。
[0112] この場合、 RAS— DBファイル 11には、 CPU # 0, 1, 2, 3の解析情報として、図 7 に示すものが格納される。ここで、図 7では、 DCモデル用の解析情報と、 FFモデル 用の解析情報とを定義して 、るが、この 2つの違 ヽは表示メッセージが異なる点だけ である。
[0113] 一方、 RAS— DBファイル 11には、 SC # 0の解析情報として、図 8に示すものが格 納される。
[0114] 図 8に示す SC # 0の解析情報では、エントリ抑止条件として、 CPU # 0, 1, 2, 3の 送信口側に故障が発生した場合には、受信口側である sc#oで発生した故障につ
Vヽては無効にすると!/、うことが定義されて 、る。
[0115] この定義に従って、 CPU # 0, 1, 2, 3の送信口側に故障が発生した場合には、受 信口側である SC # 0でも故障が発生することになるが、それについては付随的に発 生したものであって本質的なものではないことから無視して、送信口側で発生した本 質的な故障のみを解析することが可能になるのである。
[0116] この具体例では、エントリ抑止条件が同一のシステムボード内で定義されることを示 したが、エントリ抑止条件やエントリ許可条件については、同一のシステムボード内に 限られるものではなぐ異なるシステムボード間で定義されてもょ 、。
[0117] このこと〖こより、本発明によれば、システムボードを単位とする従来の故障解析方法 で必要とされて ヽたシステム全体の故障解析を行うことを省略することができるように なるのである。
[0118] 次に、図 9に従って、図 3ないし 5に示したデータ構造を持つ解析情報の作成方法 について説明する。
[0119] 図 2で説明したように、 RAS— DBファイル 11に格納される解析情報については、 ASIC 10の設計者が RAS— DB定義フアイル 50に格納する解析定義を作成すると、 RAS - DBジェネレータ 51がその解析定義をコンパイルして RAS - DBファイル 11 に格納することで、 RAS - DBファイル 11に格納されることになる。
[0120] この解析情報の作成にあたって、 ASIC10の搭載される情報処理装置のモデルに よって、システムボートの枚数やそこに搭載される ASIC10の搭載位置が変わること で、解析情報に記述されるエントリ抑止 (dis)やエントリ許可条件 (enb)や故障マーク（ mark)などの項目値が変更されることになる。
[0121] しかし、そのような変更に合わせて、 ASIC10の設計者に対して、情報処理装置の モデル毎に、別々の解析情報を作成させるように要求して 、たのでは多大な負荷を 強 ヽること〖こなる。
[0122] そこで、本発明では、 ASIC10の設計者に対して、エントリ抑止（dis)やエントリ許可 条件（enb)や故障マーク (mark)などの項目値にっ 、て、情報処理装置のモデルに合 わせた読み替えの変換ルールを作成させるとともに、解析情報については情報処理 装置のモデルに依らな 、一般的な形で作成させて、この変換ルールを利用すること で、情報処理装置のモデルに合った解析情報の作成を実現すると 、う方法を用いる ようにしている。
[0123] すなわち、本発明では、図 9に示すように、 ASIC10の設計者に対して、 ASIC10 に固有の RAS— DB定義（情報処理装置のモデルに依らな 、一般的な形の RAS— DB定義）を作成させて、それをフォーマットチェックすることで ASIC10に固有の RA S— DB定義を作成する。
[0124] そして、 ASIC 10の設計者 (システムの設計者でもよい）に対して、エントリ抑止（dis) やエントリ許可条件 (enb)や故障マーク (mark)などの項目値にっ 、て、情報処理装 置のモデルに合わせた読み替えの変換ルール定義を作成させて、それをフォーマツ トチェックすることで情報処理装置のモデルに合わせた読み替えの変換ルール定義 を作成する。
[0125] そして、作成した RAS— DB定義と作成した変換ルール定義とを組み合わせて、そ れをコンパイルすることで、解析対象となる情報処理装置のモデルに合った解析情 報を作成して、それを RAS - DBファイル 11に格納するようにして 、る。
[0126] この構成に従って、本発明によれば、 ASIC10の設計者は情報処理装置のモデル 毎に別々の解析情報を作成しなくても済むようになる。
[0127] 次に、図 10及び図 11の処理フローに従って、図 2に示す本体ログ解析プロセス 34 の実行する処理について詳細に説明する。
[0128] 本体ログ解析プロセス 34は、本体ログプロセス 31から解析用ログファイル 32に格 納されるログ情報 (故障発生を表示するログ情報)の解析指示が発行されると、先ず 最初に、ステップ S 10で、バッファ 40をクリアする。
[0129] 続いて、ステップ S11で、解析用ログファイル 32に格納される全てのログ情報を処 理したのカゝ否かを判断する。
[0130] このステップ S11の判断処理に従って、解析用ログファイル 32に格納される全ての ログ情報を処理していないことを判断するときには、ステップ S12に進んで、解析用口 グファイル 32から、未処理のログ情報を 1つ読み出す。
[0131] 続いて、ステップ S13で、 RAS— DBファイル 11から、ステップ S12で読み出した口 グ情報に対応付けられる解析情報を取得する。
[0132] 続いて、ステップ S14で、ステップ S13で取得した解析情報にエントリ抑止条件が 記述されて!ヽるのか否かを判断する。
[0133] このステップ S14の判断処理に従って、ステップ S 13で取得した解析情報にエントリ 抑止条件が記述されていることを判断するときには、ステップ S15に進んで、解析用 ログファイル 32に格納されるログ情報を参照することで、そのエントリ抑止条件が成立 するの力否かを判断する。
[0134] 続いて、ステップ S16で、ステップ S15の判断処理に従って、ステップ S13で取得し た解析情報に記述されるエントリ抑止条件が成立することを判断するときには、次の ログ情報について処理すベぐステップ S11の処理に戻る。
[0135] すなわち、ステップ S13で取得した解析情報に記述されるエントリ抑止条件が成立 する場合には、その解析情報が無効となることで、ステップ S12で読み出したログ情 報を解析する必要がないので、次のログ情報について処理すベぐステップ S 11の 処理に戻るのである。
[0136] 一方、ステップ S14の判断処理に従って、ステップ S 13で取得した解析情報にェン トリ抑止条件が記述されていないことを判断し、あるいは、ステップ S 16の判断処理に 従って、ステップ S13で取得した解析情報に記述されるエントリ抑止条件が成立しな いことを判断するときには、ステップ S17に進んで、ステップ S 13で取得した解析情報 にエントリ許可条件が記述されているのか否かを判断する。
[0137] このステップ S17の判断処理に従って、ステップ S 13で取得した解析情報にエントリ 許可条件が記述されていることを判断するときには、ステップ S18に進んで、解析用 ログファイル 32に格納されるログ情報を参照することで、そのエントリ許可条件が成立 するの力否かを判断する。
[0138] 続いて、ステップ S19で、ステップ S18の判断処理に従って、ステップ S13で取得し た解析情報に記述されるエントリ許可条件が成立しないことを判断するときには、次 のログ情報について処理すベぐステップ S11の処理に戻る。
[0139] すなわち、ステップ S13で取得した解析情報に記述されるエントリ許可条件が成立 しない場合には、その解析情報が無効となることで、ステップ S12で読み出したログ 情報を解析する必要がないので、次のログ情報について処理すベぐステップ S 11 の処理に戻るのである。
[0140] 一方、ステップ S17の判断処理に従って、ステップ S 13で取得した解析情報にェン トリ許可条件が記述されていないことを判断し、あるいは、ステップ S 19の判断処理に 従って、ステップ S13で取得した解析情報に記述されるエントリ許可条件が成立する ことを判断するときには、ステップ S20に進んで、バッファ 40が満杯であるのか否かを 判断する。
[0141] すなわち、ステップ S13で取得した解析情報が最終的に有効なものであると判断す る場合には、ステップ S20に進んで、バッファ 40が満杯であるのか否かを判断するの である。
[0142] このステップ S20の判断処理に従って、バッファ 40が満杯でないことを判断するとき には、ステップ S21に進んで、ステップ S13で取得した解析情報をバッファ 40に格納 することで、ステップ S12で読み出したログ情報の解析を行ってから、次のログ情報 について処理すベぐステップ S 11の処理に戻る。
[0143] すなわち、ステップ S12で読み出したログ情報に対応付けられる解析情報には、そ のログ情報が発生するときには、このような故障が発生したので、このような処理を行 えと!/、うことが記述されて 、るので、それを解析結果としてバッファ 40に格納してから 、次のログ情報について処理すベぐステップ S 11の処理に戻るのである。
[0144] 一方、ステップ S20の判断処理に従って、バッファ 40が満杯であるということを判断 するときには、ステップ S22に進んで、ステップ S 13で取得した解析情報に記述され る優先度情報に従って、ステップ S12で読み出したログ情報の持つ優先度を特定す る。
[0145] 続いて、ステップ S23で、ノ ッファ 40の最後尾にソートされる解析情報 (最も低い優 先度のものがソートされている）に従って、ノ ッファ 40に解析結果が格納されている口 グ情報の持つ最も低 、優先度を特定する。
[0146] 続!、て、ステップ S24で、ステップ S22で特定した優先度がステップ S23で特定し た優先度よりも低 、の力否かを判断する。
[0147] このステップ S24の判断処理に従って、ステップ S22で特定した優先度がステップ S23で特定した優先度よりも低いことを判断するときには、次のログ情報について処 理すべぐステップ S11の処理に戻る。
[0148] すなわち、ステップ S22で特定した優先度がステップ S23で特定した優先度よりも 低いことを判断する場合には、ステップ S12で読み出したログ情報がバッファ 40に解 析結果が格納されて!、るログ情報よりも重要でな 、ことを判断して、何の処理も行うこ となぐ直ちに、ステップ S 11の処理に戻るのである。
[0149] 一方、ステップ S24の判断処理に従って、ステップ S22で特定した優先度がステツ プ S23で特定した優先度よりも高いことを判断するときには、ステップ S25に進んで、 ノ ッファ 40の最後尾にソートされる解析情報 (最も低 、優先度のものがソートされて いる）と入れ替える形で、ステップ S 13で取得した解析情報をバッファ 40に格納する ことで、ステップ S 12で読み出したログ情報の解析を行う。
[0150] すなわち、ステップ S22で特定した優先度がステップ S23で特定した優先度よりも 高いことを判断する場合には、ステップ S12で読み出したログ情報がバッファ 40に解 析結果が格納されて!ヽる最も低!ヽ優先度を持つログ情報よりも重要であることを判断 して、そのログ情報と入れ替える形で、解析結果をバッファ 40に格納するのである。
[0151] 続いて、ステップ S26で、ノ ッファ 40に格納される解析情報を優先度に従ってソー トしてから、次のログ情報について処理すベぐステップ S 11の処理に戻る。
[0152] そして、ステップ S 11〜ステップ S26の処理を繰り返していくときに、ステップ S 11で 、解析用ログファイル 32に格納される全てのログ情報を処理したことを判断するとき には、ステップ S27に進んで、バッファ 40に格納される解析情報を故障解析の解析 結果として報告先に報告して、処理を終了する。
[0153] このようにして、本体ログ解析プロセス 34は、本体ログプロセス 31から解析用ログフ アイル 32に格納されるログ情報 (故障発生を表示するログ情報)の解析指示が発行さ れると、図 12に示すように、 RAS— DBファイル 11から、優先度の順番に従ってログ 情報に対応付けられる解析情報を取得して、それをバッファ 40に格納することで故 障解析を行うように処理するのである。
[0154] この処理に従って、本発明によれば、優先度の高!、ログ情報の解析が漏れなく行 われることを保証できるようになる。 [0155] 以上に説明した処理の実行にあたって、本体ログ解析プロセス 34は、作業用メモリ 41の容量を削減するために、図 13に示すように、システムの起動時には、 RAS-D Bファイル 11に格納される解析情報にっ 、ては作業用メモリ 41に読み出さな 、ように して、解析情報の索引に用いられる索引テーブルのみを作業用メモリ 41に書き込む ようにする。
[0156] そして、故障が発生すると、自プロセスを実装する情報処理装置にどのような ASIC 10が搭載されて 、るのかと 、う情報を取得して、作業用メモリ 41に読み出してある索 引テーブルに従って、その取得した情報の指す ASIC10に適用される解析情報を特 定して、それを RAS— DBファイル 11から読み出して作業用メモリ 41に書き込むよう にする。
[0157] この構成に従って、本発明によれば、使用しない解析情報までも含める形で作業用 メモリ 41に解析情報を常駐させるという従来の故障解析方法に比べて、故障解析に 要する作業用メモリ 41の容量を大幅に削減できるようになる。
[0158] 本発明は、従来技術のように、システムボードを単位とする故障解析を行うのではな くて、システムボードに搭載する ASIC10のようなハードウェア回路を単位とする故障 解析を行うことを特徴とする。
[0159] これから、本発明では、ログ情報の欠落による故障解析の不可能範囲がハードゥエ ァ回路単位となる。
[0160] したがって、本発明では、図 14に示すように、例えば、システムボード 100に搭載さ れるある一つの ASIC10 (例えば、図中に示す ASIC— D)からハード故障フラグを収 集できないような事態が起こるときには、その ASIC10のみが解析不可能になるだけ であって、従来技術のように、システムボード全体について解析不可能になるようなこ とはない。
[0161] このように、本発明によれば、従来技術に比べて、故障解析の不可能範囲を大幅 に小さくすることができるようになる。
産業上の利用可能性
[0162] 本発明によれば、情報処理装置に搭載される LSIのような論理回路に発生する故 障を解析するという機能を実現するときに、メモリ資源の削減、処理の高速化および 開発工数の削減を実現できるようになるとともに、重大な故障を漏れなく解析すること を実現できるようになり、さらに、解析不可能範囲を小さくすることを実現できるように なる。

Claims

請求の範囲
[1] 複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、 それらの論理回路にどのような故障が発生したのかを解析する故障解析装置であつ て、
論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理 回路力 収集するログ情報について、そのログ情報が発生するときに処理すべき情 報と、そのログ情報が有効なものとなる条件の情報と、そのログ情報が無効なものとな る条件の情報とについて記述する解析情報を記憶する記憶手段と、
論理回路の故障発生時に、論理回路力 故障発生を表示するログ情報を収集する 収集手段と、
上記収集手段の収集したログ情報と、上記記憶手段に記憶される解析情報とに基 づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えるこ とを、
特徴とする故障解析装置。
[2] 複数の論理回路を搭載する複数のボードを具備する情報処理装置に実装されて、 それらの論理回路にどのような故障が発生したのかを解析する故障解析装置であつ て、
論理回路の搭載されるボード番号及びボード上搭載位置に対応付けて、その論理 回路力 収集するログ情報について、そのログ情報が発生するときに処理すべき情 報と、そのログ情報の優先度の情報と、そのログ情報が有効なものとなる条件の情報 と、そのログ情報が無効なものとなる条件の情報とについて記述する解析情報を記 憶する記憶手段と、
論理回路の故障発生時に、論理回路力 故障発生を表示するログ情報を収集する 収集手段と、
上記収集手段の収集したログ情報と、上記記憶手段に記憶される解析情報とに基 づいて、論理回路にどのような故障が発生したのかを解析する解析手段とを備えるこ とを、
特徴とする故障解析装置。
[3] 請求項 2に記載の故障解析装置において、
上記記憶手段は、上記ログ情報が有効なものとなる条件の情報として、どのログ情 報が故障発生を示す場合という条件の情報について記述することを、
特徴とする故障解析装置。
[4] 請求項 2に記載の故障解析装置において、
上記記憶手段は、上記ログ情報が無効なものとなる条件の情報として、どのログ情 報が故障発生を示す場合という条件の情報について記述することを、
特徴とする故障解析装置。
[5] 請求項 2な 、し 4の 、ずれか 1項に記載の故障解析装置にぉ 、て、
上記解析手段は、上記収集手段の収集したログ情報の内、上記解析情報に記述さ れる条件情報に基づいて有効となるものを抽出することで、論理回路にどのような故 障が発生したのかを解析することを、
特徴とする故障解析装置。
[6] 請求項 5に記載の故障解析装置において、
上記解析手段は、上記抽出したログ情報の内、上記解析情報に記述される優先度 情報に基づ 、て優先度の高 、ものを抽出することを、
特徴とする故障解析装置。
[7] 請求項 6に記載の故障解析装置において、
上記解析手段は、上記収集手段の収集したログ情報の内、上記解析情報に記述さ れる条件情報に基づいて有効となるログ情報を抽出すると、その抽出したログ情報の 優先度が規定のメモリ容量を持つバッファに格納されるログ情報の優先度よりも高い 場合には、そのバッファに格納される最も優先度の低いログ情報と入れ替える形でそ の抽出したログ情報を格納し、その抽出したログ情報の優先度がそのノ ッファに格納 されるログ情報の優先度よりも低い場合には、その抽出したログ情報をバッファに格 納しな 、ようにすることで、優先度の高 、ログ情報を抽出することを、
特徴とする故障解析装置。
[8] 請求項 2な 、し 7の 、ずれか 1項に記載の故障解析装置にぉ 、て、
装置起動時に、解析対象となる情報処理装置に搭載される可能性のある論理回路 に適用される上記解析情報の索引に用いられる索引情報を、上記記憶手段に記憶 させる第 1の展開手段と、
論理回路の故障発生時に、解析対象となる情報処理装置に搭載される論理回路 の情報と上記索引情報とに従って、上記解析手段の解析に必要となる上記解析情 報を特定して、その特定した解析情報を上記記憶手段に記憶させる第 2の展開手段 とを備えることを、
特徴とする故障解析装置。
PCT/JP2006/303553 2006-02-27 2006-02-27 故障解析装置 WO2007099578A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2006/303553 WO2007099578A1 (ja) 2006-02-27 2006-02-27 故障解析装置
JP2008502565A JP4523659B2 (ja) 2006-02-27 2006-02-27 故障解析装置
EP06714690.2A EP1990722B1 (en) 2006-02-27 2006-02-27 Failure analyzer
US12/230,241 US8166337B2 (en) 2006-02-27 2008-08-26 Failure analysis apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2006/303553 WO2007099578A1 (ja) 2006-02-27 2006-02-27 故障解析装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/230,241 Continuation US8166337B2 (en) 2006-02-27 2008-08-26 Failure analysis apparatus

Publications (1)

Publication Number Publication Date
WO2007099578A1 true WO2007099578A1 (ja) 2007-09-07

Family

ID=38458701

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/303553 WO2007099578A1 (ja) 2006-02-27 2006-02-27 故障解析装置

Country Status (4)

Country Link
US (1) US8166337B2 (ja)
EP (1) EP1990722B1 (ja)
JP (1) JP4523659B2 (ja)
WO (1) WO2007099578A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8327193B2 (en) * 2009-04-13 2012-12-04 Seagate Technology Llc Data storage device including a failure diagnostic log
US9104583B2 (en) 2010-06-24 2015-08-11 International Business Machines Corporation On demand allocation of cache buffer slots
US20110320863A1 (en) * 2010-06-24 2011-12-29 International Business Machines Corporation Dynamic re-allocation of cache buffer slots
US9311176B1 (en) * 2012-11-20 2016-04-12 Emc Corporation Evaluating a set of storage devices and providing recommended activities
JP6123472B2 (ja) * 2013-05-13 2017-05-10 株式会社リコー 機器管理装置、機器管理システム、機器管理方法及びプログラム
JP6328595B2 (ja) * 2015-09-29 2018-05-23 東芝テック株式会社 情報処理装置及びプログラム
JP2017220022A (ja) * 2016-06-07 2017-12-14 富士通株式会社 情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001331350A (ja) * 2000-05-19 2001-11-30 Mitsubishi Electric Corp 保守管理装置
JP2003162430A (ja) * 2001-11-27 2003-06-06 Mitsubishi Electric Corp 障害情報管理装置および障害情報管理方法
JP2005004326A (ja) * 2003-06-10 2005-01-06 Canon Inc 情報通知装置
JP2005284357A (ja) * 2004-03-26 2005-10-13 Fujitsu Ltd ログ解析プログラム及びログ解析装置

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2738173B2 (ja) * 1991-07-17 1998-04-08 富士通株式会社 スタンドアロン型装置の診断システム
US5826068A (en) * 1994-11-09 1998-10-20 Adaptec, Inc. Integrated circuit with a serial port having only one pin
US6236654B1 (en) * 1997-02-14 2001-05-22 Advanced Micro Devices, Inc. Method and apparatus for managing learning in an address table in memory
JP3704871B2 (ja) * 1997-03-17 2005-10-12 富士通株式会社 障害調査情報装置
US6202103B1 (en) * 1998-11-23 2001-03-13 3A International, Inc. Bus data analyzer including a modular bus interface
FR2789502B1 (fr) * 1999-02-08 2001-08-10 Bull Sa Procede et outil d'analyse et de localisation de pannes materielles dans une machine informatique
US6363452B1 (en) * 1999-03-29 2002-03-26 Sun Microsystems, Inc. Method and apparatus for adding and removing components without powering down computer system
US6532558B1 (en) * 2000-03-02 2003-03-11 International Business Machines Corporation Manufacturing testing of hot-plug circuits on a computer backplane
US6598179B1 (en) * 2000-03-31 2003-07-22 International Business Machines Corporation Table-based error log analysis
JP2001311766A (ja) * 2000-04-28 2001-11-09 Advantest Corp 半導体デバイス試験装置及び試験方法
US6959257B1 (en) * 2000-09-11 2005-10-25 Cypress Semiconductor Corp. Apparatus and method to test high speed devices with a low speed tester
US7509532B2 (en) * 2000-09-13 2009-03-24 Kingston Technology Corp. Robotic memory-module tester using adapter cards for vertically mounting PC motherboards
US20020121913A1 (en) * 2000-12-28 2002-09-05 Advanced Micro Devices, Inc. Tester with independent control of devices under test
US6754817B2 (en) * 2001-01-25 2004-06-22 Dell Products L.P. Apparatus and method for detecting a change in system hardware configuration to reduce the amount of time to execute a post routine
US6832342B2 (en) * 2001-03-01 2004-12-14 International Business Machines Corporation Method and apparatus for reducing hardware scan dump data
US8166361B2 (en) * 2001-09-28 2012-04-24 Rambus Inc. Integrated circuit testing module configured for set-up and hold time testing
US7020815B2 (en) * 2002-08-29 2006-03-28 Micron Technology, Inc. Memory technology test apparatus
US7039836B2 (en) * 2003-04-01 2006-05-02 Hewlett-Packard Development Company, L.P. High performance computer system having a firmware error queue and automatic error handling
US7284153B2 (en) * 2003-11-17 2007-10-16 International Business Machines Corporation Apparatus, method, and system for logging diagnostic information
US20070168068A1 (en) * 2004-03-22 2007-07-19 Masao Saito Display apparatus, program product causing computer to function as the display apparatus, and recording medium storing the program product
US7359831B2 (en) * 2004-05-21 2008-04-15 Bea Systems, Inc. Diagnostic context
US7802144B2 (en) * 2005-04-15 2010-09-21 Microsoft Corporation Model-based system monitoring

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001331350A (ja) * 2000-05-19 2001-11-30 Mitsubishi Electric Corp 保守管理装置
JP2003162430A (ja) * 2001-11-27 2003-06-06 Mitsubishi Electric Corp 障害情報管理装置および障害情報管理方法
JP2005004326A (ja) * 2003-06-10 2005-01-06 Canon Inc 情報通知装置
JP2005284357A (ja) * 2004-03-26 2005-10-13 Fujitsu Ltd ログ解析プログラム及びログ解析装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1990722A4 *

Also Published As

Publication number Publication date
JP4523659B2 (ja) 2010-08-11
US20090006896A1 (en) 2009-01-01
EP1990722A4 (en) 2012-06-27
EP1990722B1 (en) 2018-02-28
US8166337B2 (en) 2012-04-24
EP1990722A1 (en) 2008-11-12
JPWO2007099578A1 (ja) 2009-07-16

Similar Documents

Publication Publication Date Title
WO2007099578A1 (ja) 故障解析装置
US6829729B2 (en) Method and system for fault isolation methodology for I/O unrecoverable, uncorrectable error
US9471474B2 (en) Cloud deployment infrastructure validation engine
CN100432949C (zh) 在计算机上当软件崩溃时保存用户数据的方法及装置
US20080148238A1 (en) Runtime Analysis of a Computer Program to Identify Improper Memory Accesses that Cause Further Problems
US6845469B2 (en) Method for managing an uncorrectable, unrecoverable data error (UE) as the UE passes through a plurality of devices in a central electronics complex
CN111414268B (zh) 故障处理方法、装置及服务器
CN1744049A (zh) 用于调试输入/输出故障的方法和系统
US7502956B2 (en) Information processing apparatus and error detecting method
JP5495310B2 (ja) 情報処理装置、障害解析方法及び障害解析プログラム
CN111858448A (zh) 一种i2c死锁并恢复的方法及装置
US8234525B2 (en) Method and system for anomaly detection in software programs with reduced false negatives
CN101398781A (zh) 一种快速诊断系统软件缺陷的系统及方法
US20050268187A1 (en) Method for deferred data collection in a clock running system
CN100377105C (zh) 一种告警自动测试方法
CN108762999A (zh) 一种内核故障收集方法及装置
JP5023086B2 (ja) 計算機システム
JP2002288049A (ja) Ｐｃｉバス不良個所切り離し方法およびそのプログラム
JP2008084080A (ja) 障害情報格納システム、サービスプロセッサ、障害情報格納方法、及びプログラム
JPH07311697A (ja) 計算機システムの故障表示方式
JP7367495B2 (ja) 情報処理装置および通信ケーブルログ情報採取方法
US7337247B2 (en) Buffer and method of diagnosing buffer failure
JP3378975B2 (ja) 障害診断器
JP2005250577A (ja) コンピュータシステム及び演算処理モジュールの健全性判定方法
JP2010055305A (ja) 診断項目登録システム、方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2008502565

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2006714690

Country of ref document: EP