JPH09114701A - Simple multiprocessor monitoring system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make a CPU on a monitoring side able to discriminate an operation history or the like until the fault generation of a runaway CPU on a side to be monitored in a simple multiprocessor monitoring system in which the CPU on the monitoring side can identify in which part of a task under a processing by the CPU on the side to be monitored runaway occurs. SOLUTION: Through COM RAMs 11 and 21 provided with the operating state detailed information of sub-CPUs 31 and 41 and areas (STS/CMD areas) 13 and 23 where a main CPU 1 stores the command of a restoration procedure or the like when a fault is generated in the sub-CPUs 31 and 41, the sub-CPUs 31 and 41 perform the operation of tentatively interrupting the task during the processing by a runaway monitoring module for monitoring the runaway of the respective sub-CPUs 31 and 41 themselves, shifting the processing to the runaway monitoring module, performing monitoring and recovering the processing of the tentatively interrupted task after the processing of the runaway monitoring module is ended in a prescribed cycle and inform the main CPU 1 of the operating states of the respective sub-CPUs themselves.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multiprocessor monitoring system composed of a plurality of CPUs for the purpose of distributing processing, and in particular, it includes a main CPU and at least one sub CPU, and each main CPU is a sub CPU.
A multiprocessor monitoring system for monitoring U,
The present invention relates to a simple multiprocessor monitoring system that does not require support tools.

[0002]

2. Description of the Related Art Conventionally, as a multiprocessor monitoring system composed of a plurality of CPUs, for example, Japanese Patent Laid-Open No.
3-49948 is mentioned.

As shown in FIG. 7, this system includes a plurality of CPUs 100 and 200, and each CPU 10
Each of 0 and 200 has a ROM that stores a module that is a program for individually detecting runaway. Further, each CPU 100, 200 is reset at a predetermined timing during normal operation, and when a failure, that is, a runaway occurs, each CPU 10 is reset after a predetermined time has elapsed.
A stall timer for interrupting 0 and 200 is connected.

In the illustrated example, the CPU 100 will be described as a monitoring CPU, and the CPU 200 will be described as a monitored CPU.

First, when the monitored CPU 200 is operating normally, the monitored CPU 100 moves to the monitored CPU.
In response to a request to the CPU 200, the stall timer 103 of the monitoring CPU 100 counts up and the monitoring CPU 10
Before enabling INT2 of 0, the monitored CPU
200 receives a response from the monitoring CPU 100. Upon receiving the response from the monitored CPU 200, the monitoring CPU 100 clears the stall timer 103 of the monitoring CPU 100.

On the other hand, if there is no response from the monitored CPU 200 to the monitored CPU 100 even if the monitored CPU 100 runs out of control and the stall timer 103 of the monitored CPU 100 counts up, if the monitored CPU 100 does not respond.
Stall timer 103 interrupts the monitoring CPU 100, and an INT2 interrupt is generated in the monitoring CPU 100. The monitoring CPU 100 sends the NMI signal 109 to the NM of the monitored CPU 200 in accordance with the INT2 interrupt.
Output to I terminal. A reset operation is performed by the reset signal 107 in the interrupt processing to prevent runaway and erroneous recognition, thereby constructing a system that does not affect other CPUs.

[0007]

However, in the above-mentioned conventional example, the monitoring side CPU could not identify in which part of the task being processed the monitored CPU went out of control.

Further, the monitoring CPU that is monitoring the monitored CPU cannot identify the operation history of the runaway monitored CPU until the occurrence of a failure.

As a result, the system shown in the figure has a problem in that it cannot prevent the runaway and erroneous recognition, and that the recovery procedure corresponding to the failure cannot be performed accurately.

On the other hand, even in a simple multiprocessor monitoring system which does not require a support tool or the like, improvement in system reliability and quick failure recovery are required. Under these circumstances,
The system of FIG. 7 which can detect runaway simply has a drawback that it cannot sufficiently meet the demand of the consumer.

In order to solve the above problems, an object of the present invention is to provide a simple multiprocessor monitoring system in which the monitoring CPU can identify in which part of the task the monitored CPU has runaway. To provide.

Another object of the present invention is to provide a simple multiprocessor monitoring system in which a monitoring CPU can identify detailed operation state information such as an operation history of a runaway monitored CPU until a failure occurs. It is in.

[0013]

According to the present invention, a main CPU, at least one sub CPU, and the main CPU and the sub CPUs are provided, and the main CPU and the sub CPUs are provided. In a simple multiprocessor monitoring system including a common memory used in common, the main CPU, the sub CPUs, and a data bus connecting the common memories corresponding to the sub CPUs, the common memory is the sub CPU. State / command area for storing detailed operating state information and commands from the main CPU to the sub CPU, and detailed operating state information of the sub CPU and the main CPU to the sub CPU
A data area for storing data other than commands to the main CPU,
A simple multiprocessor monitoring system characterized in that each sub CPU is monitored by referring to the detailed operation state information stored in the command area can be obtained.

Further, according to the present invention, in the simple multiprocessor monitoring system, each of the sub CPUs is
By having a unit for writing the state of each sub CPU as the detailed operating state information in the state / command area of each common memory, and the main CPU having a unit for reading the detailed operating state information, Each sub-C
When a runaway occurs in a PU, a simple multiprocessor monitoring system characterized by being able to know at which part of the task the sub CPU has runaway is obtained.

Further, according to the present invention, in the simple multiprocessor monitoring system, one of the main CPU and the common memory has a unit for accumulating the sub CPU state information, whereby the sub CP
A simple multiprocessor monitoring system characterized by being able to store the operation history until the failure of U occurs.

Further, according to the present invention, in the simple multiprocessor monitoring system, the main CPU is
A function of detecting the operation history is provided, and when a failure occurs in the sub CPU, a recovery procedure process corresponding to the failure is performed on the sub CPU based on the detected operation history. A simple multiprocessor monitoring system can be obtained.

[0017]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings.

First, as shown in FIG. 1, the simplified multiprocessor monitoring system of the present embodiment is a main CP.
The U1 is connected to each of the sub CPUs 31 and 41 via a common memory (hereinafter, COM RAM) 11 and 21 and data buses 4, 34 and 44, respectively.

Here, the COM RAMs 11 and 21 have detailed operational state information of the sub CPUs 31 and 41 and the sub CP.
Area where the main CPU 1 stores commands such as a recovery procedure when a failure occurs in U31 and U1 (hereinafter referred to as STS / C
MD areas) 13, 23, and areas (hereinafter referred to as DATA areas) 12, 22 for transmitting and receiving normal data other than the above-mentioned operation state detailed information and commands.

Each of the sub CPUs 31 and 41 has a runaway monitoring module for monitoring the runaway of the sub CPU 31 or 41 itself. As shown in FIG. 2, the task being processed is temporarily suspended ( S101), the process is transferred to the runaway monitoring module for monitoring (S102), and after the process of the runaway monitoring module is completed, the operation of returning to the process of the temporarily suspended task (S103) is performed in a predetermined cycle.

(First Embodiment) Next, as a first embodiment, the process of the runaway monitoring module of each of the sub CPUs 31 and 41 in step S102 of FIG. 2 will be described with reference to FIG.

First, the sub CPUs 31 and 41 which have temporarily suspended the task being processed and have transferred the processing to the runaway monitoring module.
Is the COM RAM with respect to the COM RAMs 11 and 21.
Get requests of 11 and 21 are made (S201). COM
If the RAMs 11 and 21 are accessible (S20
2) In order to identify at which point in the suspended task the runaway monitoring module was called, a return address indicating where to return to the suspended task after the processing of the runaway monitoring module is completed. COM RAM1
It is set to 1 and 21 (S203).

Next, the sub CPUs 31 and 41 each have their own internal registers (AX register / BX register / CX register / DX register / DI register / SI register / DS [data segment] / E.
The contents of S [extra segment] / SS [stack segment] / SP [stack pointer] / BP [base pointer] / PS [program segment] / PC [program code]) are used as detailed operating state information for COM.
The RAM 11 and 21 are set (S204).

Further, as will be described later, the main CPU can acquire detailed operation state information set in the COM RAMs 11 and 21 by the sub CPU.

This means that the sub CPUs 31 and 41 send the program area address, the data area address, the stack pointer address, and the base pointer address which the sub CPUs 31 and 41 are currently accessing to the main C.
This means that PU1 can be notified.

After that, the sub CPUs 31 and 41 perform a normal runaway detection process (S205), and the runaway monitoring module returns to the called task according to the return address set in S203.

Further, as shown in FIG. 4, the main CPU 1 first performs COM on the COM RAMs 11 and 21.
A request to get the RAMs 11 and 21 is made (S301). C
If the OMRAMs 11 and 21 are accessible (S20
2), detailed operation state information of the sub CPUs 31 and 41 stored in the COM RAMs 11 and 21 is read (S3).
03). The main CPU 1 writes the read detailed operation state information in a ring buffer that secures a certain area of the RAM 3 of the main CPU 1 itself, thereby sub C
The operation state history of the PUs 31 and 41 is created (S30
4). The main CPU 1 can grasp the running state of the task operated by the sub CPUs 31 and 41 and the operating state such as the address of each data area being used from the return address and the contents of the internal register.

Further, when a failure such as a runaway occurs in the sub CPUs 31 and 41, the sub CPUs 31 and 41 cannot shift the processing to the runaway monitoring module.
The detailed operation state information of the sub CPUs 31 and 41 in M11 and M21 will not be rewritten. Therefore, the main CPU 1 has a certain number of
If there is no change in the operation state detailed information of the sub CPUs 31 and 41 in the sub CPUs 1 and 21 (S305), the sub CPUs 31 and 41
Of the task and the operation history of the sub CPUs 31 and 41 indicated in the operation state detailed information, the task restart request, the task end request,
In the worst case, the recovery procedure processing corresponding to the failure at that time, such as the initialization processing by the rewriting instruction of PS and PC, is performed (S306).

Incidentally, in the first embodiment of the present invention,
Although the main CPU creates the operation state history in the ring buffer that secures a certain area of the RAM 3 of the main CPU 1 itself, the operation state detailed information of the sub CPUs 31 and 41 is stored in the COMRAMs 11 and 21. May be accumulated and an operating state history may be created. However, in any case, the main CPU performs the process of handling the created operation state history.

(Second Embodiment) Next, a second embodiment will be described with reference to FIGS. 5 and 6 in comparison with the above-described first embodiment.

In the second embodiment, the main CPU
1 is a COM RAM1 by the runaway monitoring module.
The sub CPU 31, which is written in the first and the second 21 in a predetermined cycle,
In addition to the operation state detailed information of 41, the main CPU 1 requests data from the sub CPUs 31 and 41 as needed, so that the data of the address specified by the main CPU 1 in addition to the internal registers in the sub CPUs 31 and 41 at that time. Can also be obtained via the COM RAMs 11 and 21.

As shown in FIG. 5, each of the sub CPUs 31 and 41 has its own internal register with a CO register.
After setting in the M RAMs 11 and 21 (S204), the data of the designated address requested from the main CPU 1 is set into the COM RAMs 11 and 21 (S204).
By a), the RAM 33 of the sub CPUs 31 and 41,
The data content of 43 can be notified to the main CPU 1 via the COM RAMs 11 and 21.

On the other hand, as shown in FIG. 6, the main CPU 1 has a sub C stored in the COM RAMs 11 and 21.
The detailed operation state information of the PUs 31 and 41 is read (S30
3) The operation state history of the sub CPUs 31 and 41 is created (S304) by writing the read operation state detailed information into a ring buffer that secures a certain area of the RAM 3 of the main CPU 1 itself.
COMR the data of the specified address requested to 41
The data contents of the RAMs 33 and 43 of the sub CPUs 31 and 41 can be acquired by reading from the AMs 11 and 21 (S304a).

Further, the main CPU 1 has each sub CPU 3
Since detailed operation state information and operation history of Nos. 1 and 41 can be notified to a higher CPU (not shown) (S304b), the operation states of all the CPUs can be recognized as a system, and the higher CPU can Main CPU1
It is also possible to request the status of each sub CPU 31, 41.

[0035]

As described above, according to the present invention, detailed information on the operating state of the monitored CPU, and a command such as a recovery procedure for the monitored CPU when a monitored CPU fails. An area for storing, detailed information on the operating state of the monitored CPU, and an area for transmitting and receiving normal data other than commands such as a recovery procedure stored by the monitoring CPU when a failure occurs in the monitored CPU A common memory consisting of, and using the common memory, which part of the task being processed by the monitored CPU has runaway,
It is possible to provide a simple multiprocessor monitoring system that can be identified by the monitoring CPU.

Further, according to the present invention, the monitoring CPU is
It is possible to provide a simple multiprocessor monitoring system capable of identifying detailed operation state information such as an operation history of a runaway monitored CPU until a failure occurs.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration of a simple multiprocessor monitoring system of the present invention.

FIG. 2 is a flowchart showing an operation of a sub CPU.

FIG. 3 is a flowchart showing the operation of the runaway monitoring module of the sub CPU according to the first embodiment of the present invention.

FIG. 4 is a flowchart showing an operation of the main CPU unit according to the first embodiment of the present invention.

FIG. 5 is a flowchart showing the operation of the runaway monitoring module of the sub CPU according to the second embodiment of the present invention.

FIG. 6 is a flowchart showing the operation of the main CPU unit according to the first embodiment of the present invention.

FIG. 7 is a diagram showing a configuration of a conventional multiprocessor monitoring system.

[Explanation of Codes] 1 main CPU 11, 21 common memory 31, 41 sub CPU 2, 32, 42 ROM 3, 33, 43 RAM 100 monitoring CPU 103 stall timer 107 reset signal 109 NMI signal 110 common memory (dual port RA
M) 200 Monitored CPU

Claims (4)

[Claims] 1. A main CPU, at least one sub CPU, and a common memory provided between the main CPU and each of the sub CPUs and commonly used by the main CPU and each of the sub CPUs. In the simple multiprocessor monitoring system, the common memory includes a detailed operation state information of the sub CPU and a status / command area for storing a command from the main CPU to the sub CPU, and the main CPU stores the common memory in the common memory. A simple multiprocessor monitoring system, wherein each sub CPU is monitored by referring to detailed operation state information stored in the state / command area. 2. The simple multiprocessor monitoring system according to claim 1, wherein each of the sub CPUs writes the status of each of the sub CPUs in the status / command area of each of the common memories as the detailed operation status information. The main CPU reads the operation state detailed information and determines the run state, so that when a runaway occurs in each sub CPU, the runaway occurs in which part of the task the sub CPU is processing. A simple multiprocessor monitoring system characterized by being able to detect whether or not it has. 3. The simplified multiprocessor monitoring system according to claim 2, wherein one of the main CPU and the common memory has a unit for accumulating the sub CPU state information, so that the failure of the sub CPU occurs. A simple multiprocessor monitoring system characterized by being able to store the operation history up to the occurrence. 4. The simplified multiprocessor monitoring system according to claim 3, wherein the main CPU has a function of detecting the operation history, and when a failure occurs in the sub CPU, the detected operation history. A simple multiprocessor monitoring system characterized by performing a recovery procedure process corresponding to the failure on the sub CPU based on the above.