JPH01276301A - Maintenance back-up device for multiplex system - Google Patents

Abstract

PURPOSE:To surely grasp the working state of a multiplex system and at the same time to take a proper recovering measure before the occurrence of a trouble by using a common trouble extracting means which compares the information on the result of each system of the multiplex system with each other for extraction of the common trouble conditions that may possibly cause the discontinuation of operations of all systems. CONSTITUTION:A result information storage means 21 stores the information on the result of either one or both of the logging information and the diagnosing test information received from each system of a multiplex system. The means 21 fetches the information on the result of the logging information, the diagnosing information, etc., received from each system and sends these result information to a common trouble extracting means 23. The means 23 decides the presence or absence of the hard and soft common trouble conditions based on the result information on each system. When the presence of the common trouble conditions is confirmed, the trouble contents are displayed and informed to a maintenance operator. Thus it is possible to quickly take a proper recovering measure in accordance with the contents of each trouble before all systems have troubles.

Description

[Detailed Description of the Invention] [Object of the Invention] (Industrial Application Field) The present invention is applicable to, for example, process instrumentation systems, various data processing systems, FA (factory automation) systems, and other various applications. The present invention relates to a maintenance support device for a multiplex system used as a backup system, etc., and particularly to a maintenance support device for a multiplex system that promptly detects a serious failure, including a failure that stops the entire system, and notifies maintenance personnel.

(Prior art) In general, multiplexing systems are widely used in various systems that suffer large losses due to failures, etc., from the perspective of increasing the reliability of the system, and even at this stage, multiplexing systems have been widely used. There is.

However, despite the adoption of a multiplex system, there are still cases where the entire system fails and stops. For example, in a redundant computer system, failures in common parts such as failures in the CPU or memory, bugs in application software, etc. may occur, and in this case, the entire system will go down. For example, in the case of a process instrumentation system, if the entire system fails and stops while the plant is online, product production will be significantly down due to the system's operation being stopped, resulting in a huge loss. Furthermore, depending on the nature of the failure, it may have a significant impact on the local environment or cause an explosion, resulting in an extremely dangerous situation.

Therefore, in conventional multiplexed systems, even if it is impossible to perform periodic maintenance and inspection of all systems, other standby systems are periodically stopped while taking care not to affect the active system. Logging
) Maintenance and inspection work is carried out to quickly and efficiently determine the presence or absence of a failure while referring to information.

(Problem to be solved by the invention) However, among the maintenance and inspection work for the multiplexed system as described above, maintenance and inspection work for parts that may lead to serious accidents in particular requires the ability to predict failures based on knowledge of failures and actual data. This requires not only the experience and skill of the maintenance personnel, but also a considerable burden and responsibility on the maintenance personnel. Moreover, the judgment result differs depending on the maintenance personnel, and in the unlikely event that a point that should be maintained and inspected is overlooked and there is a failure at that point, the failure rate of the entire system is high because the actual operation begins without the failure being removed. If this happens and the entire system goes down, it will take a lot of time and effort to find the cause, and you will suffer a lot of loss in various ways.

The present invention was made in order to solve the above-mentioned problems, and it automatically finds common failure conditions in the hardware and software of multiple systems, and enables system operation without the need for special experience or skill. It is an object of the present invention to provide a maintenance support device for a multiplexed system that can reliably grasp the situation and take appropriate recovery measures before a failure occurs.

In addition, another object of the present invention is to monitor the active system for any signs of failure, and if there are signs of failure, switch to the standby system while checking the health of the standby system. stability of the system.

The purpose is to ensure smooth operation.

[Structure of the Invention] (Means for Solving the Problem) In order to achieve the above object, the maintenance support device for a multiplexed system according to the present invention uses any of the logging information and diagnostic test information sent from each system. The common fault extraction means includes performance information storage means for storing performance information of one or both of the systems, and common fault extraction means for comparing the performance information of each of the systems and extracting a common fault condition that may cause a stoppage of all systems. Output the fault details extracted by
5 = Powerful configuration.

□Another invention is a failure symptom detection means for detecting a failure symptom from logging information of an active system in a multiplexed system, and the presence of a failure symptom is detected by this failure symptom detection means. a health determining means for taking in diagnostic test information or logging information from the standby system to determine whether the standby system is healthy; and receiving a failure symptom signal from the failure symptom detection means; The switching condition determination means switches to the standby system on the condition that the standby system is healthy based on the diagnostic test result or logging information by the determination means.

(Function) Therefore, the present invention employs the above-mentioned means in 314 ways, so that after the performance information storage means sucks up performance information such as logging information 1 diagnostic test information from each system, this performance information is used to extract common faults. send to means. This common fault extraction means determines whether a =6- common fault condition exists on hardware and software based on the performance information of each system, and if there is a common fault condition, displays the details of the fault. By notifying the maintenance personnel, prompt recovery measures can be taken in accordance with the details of the failure before the entire system fails.

Further, in another invention, the failure symptom detection means always takes in logging information from the active system to check whether there are any failure symptoms, and if there are failure symptoms, the health judgment means uses the standby system to detect the failure symptoms. Check the health of the standby system for two weeks by importing diagnostic result information or logging information from the side system. When it is determined that the active system has a failure symptom and the standby system is healthy, the switching condition determining means switches to the standby system and continues operation.

(Example) Hereinafter, an example of the present invention will be described with reference to FIG. In the figure, reference numeral 10 denotes a parallel duplex computer system as an example of a configuration of a multiplex system. This system 10 includes a central processing unit (CPU) 1 that executes arithmetic processing based on a predetermined sequence program for each system.
1, 1.1, bulk memory 12, 12, for example, an I10 interface 14.1 that sends control signals to the process system 1B and takes in necessary signals from the process system 13
．． 4 etc., each central processing unit], 1. , 11 and a common memory 15 managed individually by each central processing unit 1.1, 1.
A connecting device 16 or the like for connecting 1 is provided. Each of these systems acquires logging information during operation using each solid device]1, and periodically executes a diagnostic test to acquire diagnostic test information. Therefore, this device collects performance information such as logging information 1 and diagnostic test information to determine whether or not a common failure has occurred in both systems. 20 was established.

This maintenance support device 20 stores logging information (error information) during operation that is sequentially sent from each central processing unit 1, performance information such as diagnostic test I/information, the number of occurrences thereof, the timing of occurrence, etc., in a predetermined memory. A common fault extraction means 2B reads out performance information from the performance information storage means 2 via a lotus 22 and searches for common fault conditions based on a predetermined processing sequence. , and a display section 24 that displays the common fault contents extracted by the common fault extraction means 23 as guidance. Note that the logging information and diagnostic test information include, for example, Item I as shown in Tables 1 and 2.

Table 1: Examples of logging information Table 2: Examples of diagnostic test information Next, the operation of the apparatus configured as shown below will be explained. First, the performance information storage means 2] and the central processing unit 1
For example, the logging information during operation shown in Table 1 and the diagnostic test information shown in Table 2 are sent from 1 and 1.1, so these performance information are sequentially stored together with the number of occurrences and the timing of occurrence.

After the performance information is stored in the performance information storage means 21 as described above, or during storage, the common fault extraction means 22 searches for common fault contents based on the sequence shown in FIG. 2, for example. . That is, after the start command is issued, it is determined whether logging information or diagnostic test information is to be read (steps St, S2).
. In case of reading logging information, performance information storage means 2
The logging information is read from 1 and it is determined whether a common failure has occurred in both systems (step S3). When a common failure condition occurs, it is subsequently determined whether the failure is a hardware failure or a software failure (steps S4 and S5).

-]O- For example, the failure timing occurs randomly, and
If the occurrence frequency is high, it is determined to be a hardware failure, and if, for example, an execution time error occurs at a specific timing in the program execution process, it is determined to be a software bug. Then, in case of hardware failure, step S6
．． S7, in case of software failure, step S8.
In S9, the failure details are determined, and maintenance guidance corresponding to the failure mode stored in the memory in advance is read out and displayed on the display unit 24 according to the failure contents. For example, in the case of a CPU failure, the maintenance guidance ``rCPU failure has occurred'' is read out from the memory and displayed to notify maintenance personnel of the failure details (CPU failure).

On the other hand, in the case of reading diagnostic test information, it is similarly determined whether or not the common failure condition is satisfied (step 511). If the common failure condition is satisfied, it is determined whether the failure is a hardware failure or a software failure. (Step S12°813). For example, if a failure occurs during a shared memory read/write test or a bulk memory read/write test, there is a serious failure in the hardware such as the shared memory 15 or bulk memory 12 of both systems. In this case, it can be determined that the failure is due to a software bug. In the case of hardware failure, step S14. In accordance with S15, guidance is displayed, for example, "A read failure occurred during read/write of the shared memory", and in the case of a software failure, step S16. Similar processing is performed in accordance with S17 to display guidance on the details of the failure.

Therefore, according to the configuration of the embodiment as described above, the performance information sent from both systems is stored, and it is determined from the performance information whether or not there is a common failure content. It is possible to quickly detect the common failure contents that commonly occur in both systems, and also to determine whether it is a hardware failure or a software failure based on the failure condition, and to identify the failure contents in both systems. Since the guidance is displayed, maintenance personnel can appropriately know the details of the failure, and can give top priority to investigating the location of the failure.

This means that by specifying the details of the failure, a failure in another system can be repaired in a short time while one system is in operation, thereby preventing the entire system from going down. Furthermore, the reliability of system maintenance can be improved without overlooking the cause of a major failure.

Note that the common fault extraction means 23 may be provided with a knowledge base storage section 23a and an inference section 23b, as shown in FIG. 3, for example. The knowledge base storage unit 23a stores maintenance guidance in the form of rules in accordance with failure details, that is, failure modes, while the inference unit 23b has a function of comparing performance information with the knowledge base. That is, the inference unit 23b sends out the failure details, for example, from the knowledge base storage unit 23a in the case of a failure in the shared memory, such as “Switch to the standby side shared memory and perform a diagnostic test”, and in the case of a software bug, for example, from the knowledge base storage unit 23a. The configuration is such that maintenance guidance "Debug errors in the write routine" is read out and displayed on the display unit 24.

According to such a configuration, maintenance guidance can be defined in more detail, and maintenance guidance can be easily added while taking subsequent failure conditions into consideration.

Next, FIG. 4 is a block diagram showing another embodiment of the device of the present invention, which constantly monitors the operational status of the operating system and performs a diagnostic test on the standby system when a failure symptom appears. If there is no abnormality, the system switches to the standby system and continues the required operation. First, although there are various configurations of multiplexing systems, for convenience of explanation, an example using the same configuration as that shown in FIG. 1, that is, a parallel duplex computer system will be described. In FIG. 4, the subscript a indicates the active system, and the subscript s indicates the standby system.

On the other hand, the maintenance support device 20 includes a failure symptom detection means 31, a switching condition determination means 32, a diagnostic test means 33 as a health determination means, a display section 34, and the like.

The failure symptom detection means 31 detects logging information (error log information) sent from the central processing unit of the operational system], 1a, for example, program execution time errors, single bit errors, retry errors, etc. as shown in Table 3. It has the function of counting the number of occurrences of the occurrence of the problem, and determining that there is a failure symptom in the operational system when the count value exceeds the threshold number of times.

Table 3 Example of logging information When the switching condition determining means 32 receives a signal S1 indicating that there is a failure symptom from the failure symptom detecting means 3, it outputs a signal indicating that standby system diagnosis is necessary to the display section 34.

This diagnostic test means 33 receives a signal indicating that a standby system diagnosis is necessary from an operation by a maintenance person or from a switching condition determining means 32 (not shown), and the central processing unit of the standby system].
1b, and based on the diagnostic test information S3 as shown in Table 4, for example, determines the quality of the standby system based on the diagnostic test information S3, and sends the determination signal. is sent to the switching condition determining means 32.

Therefore, this switching condition determining means 32 sends a switching permission signal to the standby prefecture side to the display section 34 when there is a failure symptom in the active system and the standby system is in good condition. Although not shown in the drawing, each of the central processing units 1], a, and llb is provided with a failure symptom detection signal line 1, a diagnostic command signal line, and a diagnostic test information signal line, respectively.

Table 4 Example of diagnostic test information Therefore, according to the configuration of the embodiment as described above, when the number of occurrences of a specific error in the operational system exceeds a predetermined threshold number of times in the failure symptom detection means 3] At this time, it is determined that there is a symptom of a failure in the active system, and it is displayed on the display section 34 through the switching condition determining means, and the diagnostic test means 33 gives a diagnostic command to the standby system to receive and receive the diagnostic test information. If the diagnostic test information shows that the standby system is in good condition, it is immediately switched to the standby system.On the other hand, if the standby system is abnormal, switching is not permitted because there is a risk that the entire system will go down. Therefore, if the standby system is found to be healthy as a result of the above diagnosis, quickly switch to the standby system and maintain the active system, while if the diagnosis result of the standby system is not good, then maintenance and repair of the standby system is performed. By performing the switchover, the reliability of the system switchover improves, and it is possible to prevent the entire system from going down.

Next, FIG. 5 is a block diagram showing another embodiment of the apparatus shown in FIG. 4. In this embodiment, as the health judgment means, a normal 111 similar to that shown in FIG. When receiving a signal S4 indicating that there is a failure symptom from the means 31, the operation control signal S5 is sent to the failure symptom detection means 33a, and the switching condition determination means 32
A switching determination start signal S6 is sent to. Here, the failure symptom detection means 33a determines whether or not there is a failure symptom in the standby system, and sends the determination signal to the switching condition determination means 32. This switching condition determining means 32 is a failure symptom detecting means 33a.
I10 interface 14 of the standby system when it is determined from the determination signal that there is no failure sign, that is, the system is healthy.
Sends the lock release signal of b. Usually, standby I1
0 interface 14b is in a locked state. After unlocking the I10 interface 1.4b in this way, the standby system is switched over and actual operation begins.

According to such a configuration, the reliability of switching can be further improved by actually checking the presence or absence of failure symptoms in the standby system.

[Effects of the Invention] As detailed above, the present invention provides the following various effects.

In claim 1, it is determined whether there is a common failure based on the performance information of each system, and if there is a common failure, it is determined whether it is a hardware failure or a software failure, and maintenance guidance is output according to the content of the failure. This makes it possible to automatically find common failure conditions in the hardware and software of multiple systems, and it is possible to reliably understand the operating status of the system without the need for special experience or skill, and to detect failure conditions before a failure occurs. Appropriate remedial action can be taken.

Next, in claim 2, the presence or absence of failure symptoms in the active system is monitored, and if there is a failure sign, the health of the standby system is confirmed and the switch is made to the standby system, thereby increasing the reliability of switching. This can ensure stable and smooth operation of the multiplex system.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing one embodiment of the apparatus of the present invention, FIG. 2 is a flowchart explaining the operation of FIG. 1, and FIGS. 3 to 5 are block diagrams showing other embodiments. 10...Parallel redundant computer system, 11゜11a,
llb...Central processing unit, 12...Bulk memory, 15
...Shared memory, 20...Maintenance support device, 21...
・Achievement information storage means, 2B... Common fault extraction means, 2
3a...Knowledge base storage unit, 23b...Inference unit, 2
4.34...Display unit, 31...Failure symptom detection means,
32...Switching condition determination means, 33...Diagnostic test means, 33a...Failure symptom detection means, 33b...Standby system operation confirmation unit. Applicant's agent Patent attorney Takehiko Suzue

Claims (2)

[Claims] (1) In a maintenance support device for a multiplexed system that monitors the operating status of the multiplexed system, performance information that stores performance information of either or both of logging information and diagnostic test information sent from each of the systems. The system comprises a storage means and a common fault extraction means for comparing performance information of each of the systems and extracting a common fault condition that may lead to failure and stoppage of all the systems, and outputting the details of the fault extracted by the common fault extraction means. A maintenance support device for a multiplexed system characterized by: (2) A maintenance support device for a multiplexed system that monitors the operating state of the multiplexed system, comprising a failure symptom detection means for detecting a failure symptom from logging information on the operational side of the multiplexed system, and the failure symptom detection means. a health determining means for determining whether or not the standby system is healthy by taking in diagnostic test information or logging information from the standby side system when the presence of a failure symptom is detected by the means; The switching condition determining means receives a symptom signal and switches to the standby system on the condition that the standby system is healthy based on the diagnostic test result or logging information by the health determining means. Maintenance support equipment for multiplexed systems.