JPH09321868A - Fault notice system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a fault notice system in the exchange system in which a host function block does not make useless fault processing based on a fault notice from a plurality of devices due to the same cause. SOLUTION: On the occurrence of an SPFB-B interface fault notice in a control system core 6 from a speech system function block SPFB-A7 leading to a system bus, a fault discrimination section 3 in a fault notice device 1 starts a fault watchdog timer 2, and in the case of occurrence of a fault notice from the SPFB-B8 itself and an interface fault notice with other SPFB-B8 during the operation of the fault watchdog timer 2, the fault notice history is left in the memory 4 and the fault notice to a host function block is aborted.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a fault information collecting system, and more particularly to a fault information collecting system for collecting faults due to the same factor and notifying them to upper functional blocks.

[0002]

2. Description of the Related Art In a conventional exchange system, when a failure occurs due to the same factor as a failure processing method from each functional block (hereinafter referred to as FB), each FB issues a failure notification and the upper FB Failure processing was executed each time a failure notification was issued.

Further, as shown in Japanese Patent Laid-Open No. 05-095357 "Deletion method of non-target information by waiting for failure information", the failure processing method is used when a failure due to the same factor occurs and the upper FB is notified. After accumulating fault information for a certain period of time, only the same cause message is left and the others are deleted and processed. However, in the above method, since waiting is performed for a certain period of time from the occurrence of a failure until the upper FB starts processing, the failure processing on the FB side is delayed, which is not a good measure in terms of processing capacity.

[0004]

In the conventional exchange system, the failure processing method is such that, even if a failure occurs due to the same factor from each FB, the FBs do not perform contention processing of failure information between the FBs. Since each failure notification is generated, the failure processing occurs in the upper FB each time the failure notification is issued, and there is a risk that the processing capacity on the FB side is reduced due to unnecessary failure processing.

Further, when a failure occurs in a failure processing system such as the above-mentioned Japanese Patent Laid-Open No. 05-095357, "a method of deleting non-target information by waiting for failure information", the failure information is held for a certain period of time in the failed FB, Since the information is selected, the FB processing may be delayed.

An object of the present invention is to prevent delay in processing start time of failure processing of the upper FB, avoid duplication of failure notification due to factors, and improve performance of switching system at the time of failure.
It is to provide a fault notification method aiming at high reliability.

[0007]

A failure notification system of the present invention is a failure notification system in an exchange system which receives a failure notification from each FB connected to a system bus and carries out failure processing. Means for transferring the first notified failure to the upper FB when the FB notifies the failure successively due to the failure due to the same factor;
Means for deleting a notification other than the first failure due to the same factor during the failure processing by the background processing of the failure processing of the upper FB without interrupting the failure processing of the upper FB; It has means for accumulating the information of the fault in which the information and the notification are deleted in the memory, and searching the fault history from the memory on the upper FB side.

Further, the failure information is information of a failure which is distinguished from a hardware failure inside the own FB as an interface failure between adjacent FBs and has a failure code given in advance in a number form.

Further, the means for transferring to the upper FB of the failure has a means for operating the failure timer for a predetermined time at the same time as the transfer.

Further, the means for operating the failure timer for a certain period of time is the time of background processing, and the time required for notification of occurrence of failure from both FBs due to failure of the same factor between adjacent FBs and higher FB. It has a means for operating for a time which is obtained by adding the failure information transfer time.

Further, the means for activating the fault timer for a certain period of time is only required to write the history in the memory of the upper FB even if the fault information due to the same factor of the adjacent FB is notified while the fault timer is operating. It has a means that can not be operated.

[0012]

BEST MODE FOR CARRYING OUT THE INVENTION An embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram of the first embodiment of the present invention.
As shown in Fig. 1, a general act standby (ACT
-SBY) applied to a general duplex exchange system. This duplex exchange system has a plurality of communication path system FBs (hereinafter SP-FB) connected to a CPUFB 5 (hereinafter CPU-FB) on which a higher-level FB runs by a system bus.
It consists of. The SP-FBs are connected to each other or in a star shape. The fault notification device 1 of the present invention is a CP
It is installed between the U-FB5 and the system bus. CP
A control system core 6 is formed by the U-FB 5 and the fault notification device 1. Normal CPU-FB5 and SPFB-A7 to SPFB
-Interchange (instruction / response) with C9 is performed via the system bus, and is operated as a switching system as a whole. The fault occurring in each SP-FB is notified to the CPU-FB 5, that is, the upper FB via the system bus and the fault notification device 1 of the present invention.

The fault notifying apparatus 1 includes a fault discriminating section 3 for discriminating a fault and a CPU for receiving the fault information and transferring it to the upper FB.
An FB 5, a failure monitoring timer 2 that is activated after transfer, a failure determination unit 3 that discards failure notifications that have the same content until the failure monitoring timer 2 is turned off, and a memory 4 that records a history of failure information. It is composed by.

Next, the operation of the embodiment of the present invention will be described in detail with reference to FIGS.

When a fault occurs in each of SPFB-A7 to SPFB-C9, the fault is notified to the control system core 6. As shown in FIG. 3, the failure notification is DMA-transferred to the inside of the control system core on the system bus in a fixed format. Multiple F that cannot identify suspected FB such as HW failure
For the interface failure with B, the failure code is unified in a pre-reserved number form so that the failure notification device 1 can recognize it.

When an HW failure with SPFB-B8 occurs in SPFB-A7, the control system core 6 is notified of the HW failure. In the failure notification device 1, the CPU-FB 5 (upper F
B) is notified of the HW failure and SPFB-A7 and S
The PFB-B8 fault timer 2 is operated for a certain period of time.

Even if the SPFB-B8 notifies the HW fault with the SPFB-A7 while the fault timer 2 is operating, the fault notifying apparatus 1 only writes the history in the memory 4 and the CPU-F.
B5 is not notified.

The timer operating time is the same between SPFB-A7 and SPFB-B8 due to a failure of the same factor.
Is set in advance, which is the sum of the time at which a failure may occur and the transfer time to the control system core 6.

The CPU-FB5 reads the fault information of the SPFB-A7 and SPFB-B8 by HW fault notification with the SPFB-B8 in the SPFB-A7, isolates and identifies the fault location, and switches the system and the suspected F.
B is disconnected to maintain normal operation as an exchange system.

The fault history accumulated in the memory 4 is used as statistical information, and SPFB-A7 is used for SPFB.
It is also effective as a detailed isolation means when the isolation is impossible only by the failure notification with B8.

Next, a second embodiment of the present invention will be described with reference to the drawings. FIG. 4 is a block diagram of the second embodiment of the present invention. The difference from the first embodiment is that the communication path system FB
(Hereinafter, SP-FB). That is, SP-F
B is a switch FB (SW
FB) and SDH-FB for controlling the SDH line, and the SP-FBs are connected to each other or in a star pattern between the FBs.

When a failure occurs in each FB, the failure is notified to the control system core. Failure notification is performed by DMA transfer on the system bus in a fixed format (for example, FIG. 3). SWFBO system in FIG. 4 (hereinafter SWFB #
0) to SDHFB-AO system (hereinafter SDHFB-
An example will be described in which a HW failure (described as A # 0) occurs. FIG. 5 is a block diagram showing only the interface portion of SWFB and SDHFB-A.

The fault code in SWFB # 0 is set as shown in FIG. When a fault occurs in the code from SWFB # 0 to SWFB5001, the fault notification device 1 sets the SDHFB-A # 0 suspicious fault state according to the flowchart of FIG. 2 and activates the SDHFB-A # 0 suspicious timer. SDHFB-A # 0 is SWFB # due to the same factor in the timer time.
0 detected failure, or SWFB # 1 SDH
FB-A # 0 is detected as a failure, and a value is set that sufficiently secures the timing at which upper notification is possible.

The fault notifying apparatus 1 immediately notifies the upper FB running on the CPU-FB 5 of the fault to the SDHFB-A # 0HW from the SWFB # 0. Upon receiving this notification, the upper FB starts failure processing. Upper FB is SWFB # 1 and S
By reading the failure information of DHFB-A # 0, the failure location (failure FB) is isolated and the failure F is detected.
The system B is disconnected from the system and the system is switched to the normal system to maintain the normal operation of the exchange system.

In the fault notification device 1, when a fault is reported from another SP-FB while the fault monitoring timer 2 is operating, SD
Fault notifications that can be determined to be caused by the HFB-A # 0 suspicious fault are accumulated in the memory 4 only in the fault notification history, and the notices themselves are discarded.

Specifically, according to the algorithm of the flow chart of FIG. 2, the SDHFB-A # 0 to SWFB # 0 interface fault notification (code 5101, pair 0).
System) and SWFB-A # 1 to SDHFB-A # 0
If the failure notification (code of 5001; 0 system) on the interface comes up within the operation time of the failure monitoring timer 2, the failure notification is discarded. However, the CPU-FB 5 is immediately notified of other factors.

[0028]

As described above, according to the present invention, a plurality of fault notifications that occur due to the same factor have a higher level than call processing by discarding the other fault notifications only once. Since it is possible to avoid interrupting normal call processing due to high failure processing and lowering the processing capacity of the exchange system, it is possible to reduce the load on the upper FB and improve the system performance.

Further, since the upper FB is immediately notified when a failure occurs, there is an effect that the failure processing delay of the upper FB is not caused.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a first embodiment of the present invention.

FIG. 2 is a flowchart of a fault notification method.

FIG. 3 is a diagram illustrating an example of a failure notification format.

FIG. 4 is a configuration diagram of a second embodiment of the present invention.

FIG. 5 is an interface block diagram of SWFB and SDHFB-A.

FIG. 6 is a diagram showing an example of a fault code in SWFB.

[Explanation of symbols]

 1 Fault Notification Device 2 Fault Monitoring Timer 3 Fault Judgment Unit 4 Memory 5 CPU-FB 6 Control Core 7 SPFB-A 8 SPFB-B 9 SPFB-C 16 SDHFB-A 17 SWFB 18 SDHFB-B

Claims (5)

[Claims] 1. A failure notification method in a switching system for receiving failure notification from each functional block connected to a system bus and performing failure processing, wherein the plurality of functional blocks are successively replaced by a failure due to the same factor. When a failure is notified, a means for transferring the first notified failure to a higher-level functional block and a notification other than the first failure due to the same factor while the upper-level functional block is performing failure processing are deleted by background processing. And a means for storing failure information notified first and failure information for which notification has been deleted in a memory, and searching the failure history from the memory on the higher functional block side. 2. The fault information is fault information that is distinguished from a hardware fault inside its own functional block as an interface fault between adjacent functional blocks and has a fault code in a preassigned number form. Fault notification method described. 3. The fault notification system according to claim 1, wherein the means for transferring to the higher functional block of the failure has means for operating a failure timer for a predetermined time at the same time as the transfer. 4. The means for operating the fault timer for a certain period of time is the time of background processing, and the time required for notification of the fault occurrence from both functional blocks due to the fault of the same factor between adjacent functional blocks. 4. A means for operating for a time period in which a fault information transfer time to a functional block is added.
Fault notification method described. 5. The means for operating the fault timer for a certain period of time is only required to write the history in the memory of the upper functional block even if fault information due to the same factor of the adjacent functional block is notified while the fault timer is operating. The fault notification system according to claim 3, further comprising means for not operating the fault processing.