JPH09130482A - Specification method for fault occurrence position - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain the method facilitating a processing progress state management and the location of a fault occurrence position by controlling execution of plural tasks and storing task identification information and a task start message to a device and referencing stored data. SOLUTION: A message block is made up of a destination identification number ID2, a source identification number ID1, a message type MK1 and parameters PA1 -PAn . The identification number ID2 has an identification number of a task or interrupt handler of a message source. The identification number ID1 has the task of sender or the number of interruption handler. Furthermore, the type MK1 has a content of the message. The task or interrupt handler of the message source writes the identification numbers ID1, ID2, the message type MK1 and the parameters PA1 -PAn to the message block. Then desired information is written in a management block.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure occurrence point for specifying a failure occurrence point when a failure occurs in any of the peripheral device management units in an electronic exchange having a plurality of peripheral device management units having a central processing unit. The specific method can be applied to, for example, a peripheral package of a private branch exchange.

[0002]

2. Description of the Related Art In a private branch exchange equipped with a plurality of peripheral packages having a central processing unit, a failure occurs when a failure occurs in a communication terminal connected to the peripheral packages in the private branch exchange or an interface between the peripheral package and the communication terminal. The information related to the above is saved, and the failure recovery is performed based on the saved information.

FIG. 2 shows the structure of a general private branch exchange.

The private branch exchange P0 of FIG. 2 has a plurality of (four in the figure) peripheral packages P1 to P4.
And further accommodates a plurality of communication terminals U1 to U4, and each of the communication terminals U1 to U4 has an interface L1 to a peripheral package P1 to P4 which accommodates each of the communication terminals U1 to U4.
It is connected via L4.

Peripheral packages P1 to P4 accommodate peripheral devices such as communication terminals U1 to U4 (generally, telephone lines such as subscriber telephones, extension telephones, station line repeaters, and other auxiliary equipment for communication). It manages and controls peripheral devices, has a central processing unit inside, and consists of hardware and software.

The software S1 to S4 in the peripheral packages P1 to P4 are controlled and managed by software S0 (main control program) that controls the entire private branch exchange P0.

Conventionally, when a failure occurs in such a private branch exchange P0 (when the communication terminals U1 to U4 do not return a normal response, or the interfaces L1 to L4).
(For example, when the line is disconnected), information about the communication terminals U1 to U4, the peripheral packages P1 to P4 and the communication terminal U1.
The information about the interfaces L1 to L4 that connect U4 to U4 is stored, and subsequent failure analysis / recovery is performed based on the information.

[0008]

However, in the conventional fault information control method, when a fault (hardware fault or software fault) occurs in the peripheral package itself, or a fault occurs in the interface between the private branch exchange and the peripheral package. When hardware failure or software failure occurred, information about the failure was not saved, so it took a lot of time to analyze and recover from the failure. When such a failure occurs, it takes time to identify the location of the failure, so the peripheral package was replaced, and then failure analysis was performed.

[0009]

SUMMARY OF THE INVENTION According to the present invention, there is provided a failure for specifying a failure occurrence point when a failure occurs in any of the peripheral device management units in an electronic exchange having a plurality of peripheral device management units having a central processing unit. The method for identifying the occurrence location is characterized by the following. The task being executed on the central processing unit in each peripheral device management unit is not forcibly switched to another task.

That is, a task management program that manages and controls the execution of a task in the peripheral device management unit, at least the task identification information of the last executed task or the task to be executed from now on, and the task identification information that has been handed over to or from this task. The task wakeup message to be handed over to this task is saved in the uninitialized storage device that is not initialized even when the peripheral device management unit is initialized, and when a failure occurs, the failure location identification subject becomes the uninitialized storage device. Refer to the saved task identification information and task wakeup message.

According to the fault location identification method of the present invention,
By storing the task identification information and the task wake-up message in the non-initialization target storage device, the progress status of the processing is managed, and at the time of failure, the fault location identification body identifies the task saved in the non-initialization target storage device. By referring to the information and the task wakeup message, the location of the failure can be easily specified.

[0012]

BEST MODE FOR CARRYING OUT THE INVENTION (First Embodiment) The configuration of a private branch exchange to which the failure occurrence location identifying method of the first embodiment is applied is the same as that shown in FIG. Since each unit other than the software S1 to S4 in the peripheral package functions in the same manner as the conventional one, the description thereof will be omitted.

FIG. 3 shows a detailed configuration of the software S1 to S4 in the peripheral package, using the software in the first peripheral package P1 as an example. Software S2 in other peripheral packages P2-P4
Since S3 to S3 have the same configuration as the software S1 in the first peripheral package P1, the description thereof will be omitted. The software S1 in the first peripheral package P1 includes a monitor program K1, a plurality (three in the figure) interrupt handlers H1 to H3, and a plurality (four in the figure) tasks T1 to T4.

The monitor program K1 controls the execution of the interrupt handlers H1 to H3 and the tasks T1 to T4, and provides a communication function by messages between the interrupt handler and the task and between the task and the task. The monitor program K1 in the first embodiment is a single-task operating system, and it is assumed that the task being executed is not forcibly switched to another task.

The tasks T1 to T4 refer to processing units to which the control right of the central processing unit is assigned, and are generally called tasks, threads, and processes.

The interrupt handlers H1 to H3 are interrupt processing programs that are activated when an interrupt occurs.

FIG. 4 shows the first peripheral package P1.
The relationship between the interrupt handler in the software S1 in FIG. Other peripheral packages P2-P4
The software S2 to S3 in the first peripheral package P1 has the same relation between the interrupt handler and the task in the first peripheral package P1 as that of the first software S1. The same and corresponding parts as those in FIG. 2 are denoted by the same reference numerals.

The first interrupt handler H1 can send a message to the first task T1. Similarly, the second interrupt handler H2 and the third interrupt handler H3 can send messages to the second task T2 and the third task T3, respectively. Further, the first to third tasks T1 to T3 can send a message to the fourth task T4. further,
The fourth task T4 can send a message to the first to third tasks T1 to T3.

The message boxes m1 to m4 are
A window for receiving messages sent to the tasks T1 to T4, and tasks T1 to T4 receiving the messages
Performs the desired operation by analyzing the messages sent to the message boxes m1 to m4 attached to each.

Further, the interrupt handlers H1 to H3 and the tasks T1 to T4 are provided with identification numbers for identifying them.

The flow of processing when the first interrupt handler H1 wakes up the task T4 in such a state will be described with reference to FIG. The same parts as those in FIGS. 2 and 3 are designated by the same reference numerals.

When an event occurs, the first interrupt handler H1 corresponding to this event detects the interrupt and requests the monitor program K1 to send a message to the first task T1 corresponding to this interrupt. . The monitor program K1 receives the message transmission request of the first task T1, wakes up the first task T1, and transmits the message for which the transmission request is received to the message box m1 attached to the first task T1. The first task T1 having received the message in the attached message box m1 analyzes the message and then performs a desired operation.

The flow of processing when one task wakes up another task is the same as the flow of processing when the interrupt handler wakes up a task.

In the fault location identification method applied to the peripheral package in the private branch exchange according to the present embodiment, the monitor program K1 stores data in a non-initialized memory (not shown) when the message is sent and the task is awakened as described above. The contents of a message block described later are copied, and interrupt handlers H1 to H3 and task T
Details of message blocks exchanged between 1 to T4 and the monitor program K1 will be described below with reference to FIG.

FIG. 1 shows a message management block managed by the monitor program K1 and a message block used as a message notification area.

The message block is a transmission destination identification number ID2 for storing the identification number of the transmission destination task of the message.
And a transmission source identification number ID1 for storing the identification number of the task or interrupt handler of the message transmission source, a message type MK1 for storing the content of the message, and parameters PA1 to PAn. The task or interrupt handler that sent the message
The sender identification number ID1, the destination identification number ID2, the message type MK1 and the parameters PA1 to PAn are written, and then desired information is written in the message management block.

The message management block is a destination identification number ID for storing the identification number of the destination task of the message.
0, a message address (upper) AD1 and a message address (lower) AD2 that specify the storage location of the message block.

That is, the task or interrupt handler of the message transmission source makes a request for message transmission to the task to the monitor program by writing desired information in the message block and the message management block.

The flow of processing when copying the contents of the above-mentioned message block to the non-initialized memory will be described in detail with reference to FIG.

The flow of processing described below is such that after the task or interrupt handler of the message sender writes desired information in the message block and the message management block, the control right of the central processing unit is transferred to the monitor program. This is the process flow of the monitor program immediately after.

The monitor program, which has acquired the control right of the central processing unit and occupies the central processing unit, refers to the message address (upper) and the message address (lower) of the message management block to deinitialize the contents of the message block. Copy to memory (step 601).

After that, the monitor program determines the task of the message transmission destination from the transmission destination identification number of the message management block, wakes up the task, and stores the message address (upper) and message address (lower) in the message box attached to the task. ) Is notified (steps 602-604).

In this way, the monitor program manages the progress of the task by writing the identification number of the latest wake-up task and the content of the message to this task in the non-initialized memory.

When a failure occurs in the peripheral package, a private branch maintenance console (not shown)
The peripheral package is initialized by performing a hardware reset, the contents of the non-initialization target memory are read, and the cause of failure is analyzed by referring to the identification number of the latest wakeup task and the contents of the message to the task.

According to the first embodiment described above, the monitor program writes the contents of the message block in the memory to be uninitialized and reads the contents of the memory to be uninitialized from the private branch exchange maintenance console after a failure occurs. so,
Since the cause of failure is analyzed, it is possible to quickly identify the location of failure.

(Other Embodiments) In the first embodiment, the method of identifying a failure occurrence point of the present invention is applied to a single task operating system, but it is also applicable to a non-preemptive multitasking operating system. It can be applied, and even in a preemptive multitasking operating system, it can be applied by setting the same priority for execution of each task or by setting each task to be task dispatch disabled.

In the first embodiment, the contents of the message block for the task that is about to wake up are copied to the non-initialization target memory. The contents may be copied to the non-initialization target memory.

Further, in the first embodiment, the contents written in the message block are copied to the non-initialization target memory, but they may be copied to the auxiliary storage device.

The information in the message block and the storage format of the non-initialization target memory are arbitrary, and the information of the message transmission source may be omitted.

[0040]

According to the present invention, the task identification information and the task wake-up message are stored in the non-initialized storage device,
When a failure occurs, the task identification information and task wake-up message saved in the non-initialized storage device are referenced, so it is possible to easily and quickly identify the location of the failure, and analyze the cause of the failure. The time can be greatly reduced.

[Brief description of the drawings]

FIG. 1 is an explanatory diagram of a message block according to a first embodiment.

FIG. 2 is a configuration diagram of a private branch exchange.

FIG. 3 is a configuration diagram of software according to the first embodiment.

FIG. 4 is a diagram showing a relationship between an interrupt handler and a task according to the first embodiment.

FIG. 5 is an explanatory diagram of waking up a task according to the first embodiment.

FIG. 6 is a flowchart showing processing in a monitor program according to the first embodiment.

[Explanation of symbols]

 ID1 sender identification number ID2 destination identification number MK1 message type PA1 to PAn parameters

Claims (1)

[Claims] 1. A failure occurrence location identifying method for identifying a failure occurrence location when a failure occurs in any of the peripheral device management units in an electronic exchange having a plurality of peripheral device management units having a central processing unit, Execution of multiple tasks is controlled so that the task running on the central processing unit in each peripheral device management unit is not forcibly switched to another task. The task management program that manages and controls the execution, at least the task identification information of the last executed task or the task that is about to be executed, and the task wakeup message that has been handed over to this task or will be handed over to this task. Save to non-initialized storage device that is not initialized even when the unit is initialized Te, when a failure occurs, failure source identifying method characterized in that a fault source identifying principal has to be able to see the task identification information and the task wakeup messages stored in the non-initialization target storage device.