JP2000293407A - Monitoring controller, cpu monitoring method and program recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To specify the process causing a fault and a fault occurrence cause when the CPU fault occurs in a monitoring controller. SOLUTION: Whether or not the processing of a check point included previously in a program is accessed is checked (step 11). Information such as the process number of the accessed destination, a program position, the kinds and numbers of resources are generated (step 12). In the case a fault, etc., in a CPU 4 take place (YES in step 13), the position of the program before transition and process information are outputted (step 14). The outputted information is stored in a RAM 6 for a certain fixed time, and the information can be fetched from the RAM 6 (step 16).

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a monitoring control device, a monitoring method of a CPU (central processing unit; computer) thereof, and a recording medium storing a control program for the monitoring method, and more particularly to a monitoring device for monitoring and controlling a satellite communication earth station. It is about the method.

[0002]

2. Description of the Related Art An example of a conventional CPU (state) monitoring method is disclosed in Japanese Patent Laid-Open No. 1-190051. In this conventional CPU monitoring (alarm transfer) method, when a CPU failure occurs, a fixed pulse pattern is transmitted as serial data output, so that a CPU failure alarm is not transmitted on a separate line, and the transmission side is transmitted on the reception side. CPU
State can be detected.

[0003]

SUMMARY OF THE INVENTION The above-mentioned Japanese Patent Laid-Open Publication No. 1-1
In the CPU monitoring system disclosed in Japanese Patent Application Laid-Open No. 90051, when a failure occurs in a CPU, only the presence or absence of the failure is notified. Therefore, there is a problem that the details of the failure are not notified. The reason is that the serial port is notified with a fixed pulse pattern, so even if a failure has occurred or the location of the failure can be identified from the pulse pattern, the process leading to the failure and the failure occurrence This is because the cause cannot be identified. In addition, there is a problem that even when a fault that can be automatically recovered when a fault occurs in the CPU, the fault is not automatically recovered. The reason is that it is only a notification of the occurrence of a failure by a fixed pulse pattern, and it is not possible to identify whether or not the failure can be automatically recovered, so that the automatic recovery operation cannot be performed.

[0004] An object of the present invention is to provide a system in the event of a CPU failure.
It is an object of the present invention to provide a monitoring control device capable of identifying a process leading to the failure and a cause of the failure, a CPU monitoring method thereof, and a recording medium recording a control program of the method.

Another object of the present invention is to provide an embedded software of a monitoring and control apparatus, in which a resource provided by an OS and an application (software) side are deadlocked due to contention of resources shared independently. It is an object of the present invention to provide a system in which, when a failure such as occurs, which resource is temporarily released from the process leading to the occurrence of the failure by a self-learning function, and the monitoring control device itself is automatically restored.

[0006]

According to the present invention, there is provided a monitoring and control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein a checkpoint predetermined in the program is provided. Monitoring, comprising: a port for outputting operation information of the central processing unit to an external processing device when processing is performed; and a storage unit for storing the operation information of the central processing unit output to the port. A control device is obtained.

[0007] The checkpoint is a system call of main control software or a runaway detection routine. Further, the operation information of the central processing unit is characterized by including the presence or absence of a failure in the central processing unit, the number of the process that performed the processing, or the type and number of the resource used. Furthermore, means for storing, as history data, operation information of the central processing unit for the latest certain period in the storage means, and storing an automatic restoration result when the resource is temporarily released for each resource. Means for learning automatic recovery conditions based on the history data and the automatic recovery result.

According to the present invention, there is provided a monitoring method for a monitoring control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein a checkpoint process predetermined in the program is called. And generating information such as the process number of the callee, the program location, or the type and number of the resource being used at the beginning of the checkpoint. Determining whether the central processing unit has failed and outputting the program position information and the current process information before transitioning to a current process when a failure has occurred in the central processing unit via a port. And a monitoring method characterized by including the following.

According to the present invention, there is provided a recording medium recording a control program of a monitoring method of a monitoring control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein the control program is Confirming that a predetermined checkpoint process has been called in the program; and transmitting information such as a process number of a callee, a program position or a type and a number of a resource being used at the head of the checkpoint. Generating, a step of determining whether or not a failure has occurred in the central processing unit; and, when a failure has occurred in the central processing unit, program position information before transition to a current process and the current Outputting the process information to the outside via a port. It is obtained.

The operation of the present invention is as follows. It has a serial port and a memory area for storing data to be sent to the serial port. When a checkpoint such as a system call of the OS is processed, the process number of the process, and the type and number of the used resource Is output to the serial port, so that when a failure occurs, it is possible to identify the location of the failure and recognize the process leading to the failure.

When the data output to the serial port at the time of occurrence of the above failure is stored as a history for a certain period of time, and a certain type of resource and resource number are temporarily released from the history data, The self-learning function determines whether or not the monitoring and control device system is to be restored, thereby enabling the automatic recovery of the monitoring and control device system. That is, in the embedded software of the monitoring control device, when an easily identifiable checkpoint such as an OS (main control software) system call or a runaway detection routine is processed, the processed process number and the resource number used Required minimum items such as C
By outputting the PU status information to the serial port, the occurrence of a failure can be notified when a failure occurs. Further, the process leading to the occurrence of the failure can be identified by the history data of the serial port.

[0012]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a configuration of an embodiment of a monitoring control device according to the present invention. In FIG. 1, a related system of the present invention communicates with a satellite communication device 2, a monitoring and control device 1 controlled by an external CPU (central processing unit; computer) device 3, and communication via an artificial (communication) satellite. The system comprises a satellite communication device 2 for performing the operation and an external CPU device 3 for controlling the entire system.

Further, the monitoring control device 1 according to the present invention controls the (internal) CPU 4 for controlling the entire monitoring control device 1 and a read-only memory (ROM) 5 storing a control program for (the CPU 4 of) the monitoring control device 1. Having. Further, it has a random access memory (RAM) 6 having a battery backup function 9 for storing the data of the monitoring control device 1 and the data output to the serial port 8 when the CPU 4 fails.

Furthermore, a device communication port 7 for communicating with the satellite communication device 2, a serial port 8 for notifying the external CPU device 3 of the state (operation information) of the CPU 4, and a battery backup function for backing up the RAM 6 (for example, floating) Battery to be charged) 9
Having. Further, it has an internal bus 10 for mutually connecting the CPU 4, the ROM 5, the RAM, the 6 device communication port 7, and the serial port 8.

The operation information of the CPU 4 includes the presence / absence of a failure in the CPU 4, the number of the process that performed the processing, or the type and number of the resource used.

The operation of the embodiment of the present invention will be described with reference to the flowchart of FIG. 2 and FIG. First, in FIG.
It is checked whether a system call of S (main control software; program of the CPU 4) and a checkpoint process such as a runaway monitoring routine created by the application (software) are called (step 11).

Next, at the beginning of the checkpoint process, the callee process number, the callee program position (program counter value; PC), and the type and number of the resource if the resource is used. Information is generated (step 12). Further, it is determined whether a failure such as runaway or deadlock has occurred in the CPU 4 (step 13). If a failure or the like has occurred in the CPU 4 (YES in step 13), register values such as the position (return address) of the program before the transition to the current (current) serial port output process and the corresponding process number at the time of occurrence And other process information to the external CPU device 3 via the serial port 8 (step 1).
4).

When the checkpoint process in the normal state is called (step 13: NO), the callee process number, the call PC value, the used resource number and the type of used resource information are transmitted to the serial port. 8 (step 15). Lastly, the latest information output to the serial port 8 is stored in the RAM 6 for a certain period of time so as to be sequentially updated, and the information from the RAM 6 can be extracted through the serial port 8 as needed. (Step 16). If the storage RAM 6 is backed up by the battery 9, the monitoring control device 1
Even after the restart of the (CPU 4), the information output to the serial port 8 until the restart can be taken out.

In FIG. 1, the monitoring and control apparatus 1 according to the present invention includes a serial port 8 and a battery-backed RAM 6 for storing data to be transmitted to the serial port 8. Therefore, OS
When a checkpoint such as a system call or a runaway monitoring routine of an application is processed, the process number of the process and the type and number of the used resource are output to the serial port 8 so that when a fault occurs, The external CPU device 3 can identify the location of the failure and the process leading to the failure together with the identification of the occurrence.

Referring to FIG. 3, a supervisory control device 1 according to the present invention will be described.
An example of the operation will be described. Monitoring and control device 1 according to the present invention
The (CPU 4) has an OS kernel 26 that manages each process, and a monitoring control main process 24 that performs central processing of the monitoring control device 1. In addition, the satellite communication device 2
A LOCAL device communication process 23 for communicating with the satellite communication device 2 and acquiring the status (operating state information) of the satellite communication device 2, and a display processing process 22 for analyzing the status from the satellite communication device 2 and performing a display process. Further, at the beginning of the checkpoint process, there is a serial port output process 21 for outputting information such as the process number of the callee. Also, the monitoring control main process 24 and the LOCAL
It has a shared resource 25 necessary for transferring the status of the satellite communication device 2 between the device communication process 23 and the display processing process 22 as a processing (process) program (software).

As the process priority in this case, the serial port output process 21 has the highest priority, the display processing process 22 and the LOCAL device communication process 23 in that order, and the last monitor control main process 24 has the highest priority. Is low. In the above-described process configuration, the serial port output process 21 is executed at a certain time interval by the CPU.
4 is started in any state, and if there is information to be output at that time, the information is output to the external device 3.

As examples of failures of the CPU 4, for example, a display processing process 22 and a LOCAL device communication process 2
3 and the supervisory control process 24
It is assumed that a failure such as No. 5 has occurred. In this case, the register value such as the position of the program (here, for example, the PC value of the LOCAL device communication process 23) before the transition to the current (current) serial port output process 21 and the corresponding process number (here, Then, for example, CPU status information such as a LOCAL device communication process 23) and a process number can be output from the serial port 8 by the serial port output process 21.

Although FIG. 1 shows a method of using the serial port 8 as a means for outputting information, similar information may be output as an 8-bit or 16-bit parallel port. Here, as an embodiment of the present invention, a case has been described where the present invention is applied to a supervisory control device using embedded software that requires real-time properties. However, the present invention can be similarly applied to all embedded software that requires real-time properties.

Next, another embodiment of the present invention will be described in detail with reference to the flowchart of FIG. In another embodiment of the present invention, the software incorporated in the ROM 5 in FIG. 1 includes software having a self-learning function. Software equipped with a self-learning function is configured as a CPU state detection process with the highest priority for the software to detect a CPU failure such as no process transition.

In FIG. 4, the flow between steps 11 to 16 is the same as in FIG. First, similarly to the first embodiment (the flow of FIG. 2), it is checked whether a checkpoint process such as a system call of the OS and a runaway monitoring routine created independently by the application is called (step). 11). Next, information such as a callee process number, a callee program position (PC value), and a resource type and number is generated at the beginning of the checkpoint process (step 12). Further, the CPU 4 determines whether a trouble such as runaway or deadlock has occurred (step 13).

If a failure has occurred in the CPU 4,
The register value such as the position of the program before the transition to the current serial port output process and the process information such as the corresponding process number at the time of occurrence are output to the serial port (step 14). Finally, the information output to the serial port is stored in the RAM 6 for a certain period of time, and the information can be extracted from the RAM 6 as needed from the serial port (step 16).

Here, as software having a self-learning function, C has the highest priority for detecting a CPU failure such as a process transition does not occur.
It is assumed that a PU state detection process has been configured.

First, when a CPU failure occurs, the CPU
The state detection process searches the CPU state information stored in the RAM 6 and recognizes that a CPU failure such as deadlock has occurred due to contention of the shared resources 25 or the like (step 31). Recognize CPU failure (Step 3
If 1 is YES), the self-learning function determines which shared resource 25 should be released from the process leading to the failure to recover from the failure, and the shared resource 25 is temporarily released (step 32).

As a measure for releasing the shared resources 25,
If so, the area in which the information of the resource type is stored is temporarily changed (resource release) so that the software can automatically recover. When the software automatically recovers by temporarily releasing the shared resource 25, the resource release information is stored in the RAM 6, and then the contention frequently occurs. Then, if the resource is released temporarily, the automatic recovery is performed. It learns information such as how to do it and releases it from the frequently competing resources with the highest priority. By adopting such a method, automatic recovery of the system can be reliably performed.

[0030]

As described above, according to the present invention, when a checkpoint that can be easily identified, such as an OS system call or a runaway detection routine, is processed in the embedded software of the monitoring control device, the processed process number By outputting the necessary minimum items such as the resource numbers used and the like to the serial port, it is possible to notify an external device of the occurrence of a failure when the failure occurs.

Another effect is that the process leading to the occurrence of a failure can be identified by the data history of the serial port. That is, even in a system having a multi-configuration device configuration,
Even if one of the faults occurs, the content of the fault can be easily identified and analyzed, so that the state of the system can be easily determined by an operator or the like.

Further, in an embedded software system such as a supervisory control device, a failure such as a deadlock occurs due to a conflict between resources provided by the OS and resources uniquely shared by the application (software). In this case, the self-learning function determines which resources are temporarily released from the process leading to the occurrence of the failure, and the monitoring control device itself can be automatically restored. That is, even in an embedded software system in which the state of the CPU cannot be easily grasped, the reliability of the system can be remarkably improved by automatic restoration.

[Brief description of the drawings]

FIG. 1 is a block diagram of an embodiment of the present invention.

FIG. 2 is a flowchart of an embodiment of the present invention.

FIG. 3 is a software configuration diagram of an embodiment of the present invention.

FIG. 4 is a flowchart of another embodiment of the present invention.

[Explanation of symbols]

 REFERENCE SIGNS LIST 1 monitoring control device 2 satellite communication device 3 external CPU device 4 CPU 5 ROM 6 RAM 7 device communication port 8 serial port 9 battery backup function 10 internal bus

Claims (7)

[Claims] 1. A monitoring and control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein when a predetermined checkpoint is processed in the program, the central processing unit A port for outputting the operation information of the central processing unit to an external processing device, and storage means for storing the operation information of the central processing unit output to the port. 2. The monitoring control apparatus according to claim 1, wherein the checkpoint is a system call of a main control software or a runaway detection routine. 3. The operation information of the central processing unit includes the presence / absence of a failure in the central processing unit, the number of the process that performed the processing, or the type and number of the resource used. 3. The monitoring control device according to 1 or 2. 4. The monitoring control device according to claim 1, wherein said storage means is backed up by a battery. 5. A means for storing, as history data, operation information of the central processing unit for the latest fixed period in the storage means, and automatic recovery when the resource is temporarily released for each resource. The monitoring control apparatus according to any one of claims 1 to 4, further comprising means for storing a result, and means for learning an automatic restoration condition based on the history data and the automatic restoration result. 6. A monitoring method for a monitoring control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein a predetermined checkpoint process is called in the program. Confirming, generating information such as a process number of a callee, a program location or a type and a number of a used resource at a head of the check point, and determining whether a failure has occurred in the central processing unit. And outputting the program position information before the transition to the current process and the current process information to the outside via a port when a failure has occurred in the central processing unit. A monitoring method characterized by the above-mentioned. 7. A recording medium recording a control program of a monitoring method of a monitoring control device having a central processing unit and a memory for storing a processing program of the central processing unit, wherein the control program includes A step of confirming that a predetermined checkpoint process has been called; and a step of generating information such as a process number of a callee, a program position or a type and a number of a used resource at the head of the checkpoint. Determining whether a failure has occurred in the central processing unit; and, when the failure has occurred in the central processing unit, the program position information and the current process information before transitioning to a current process. Outputting to outside via a port.