KR20000065593A - Method for displaying alarm history detail information in exchanger - Google Patents

Abstract

PURPOSE: A method for outputting maintenance obstacle items in a switch is provided to easily grasp an obstacle of the switch by describing history and statistic outputs to an obstacle process data generated in the switch as one output type. CONSTITUTION: If an operator requests a MMC(man machine communication) or a periodic output(501), an obstacle process block discriminates an output request data time(503). If the output request data time is a data request according to a time, the obstacle block discriminates as to whether outputting data are stored in a buffer(505). If outputting data are stored in the buffer, the obstacle process block controls the buffer to move contents of the buffer to a "HOUR_buffer_file" of a disk and clears contents stored in the buffer(509). The obstacle process block searches the "HOUR_buffer_file" and extracts a corresponding obstacle item data(511). If the output request data time is one day data request, the obstacle process block searches a "DAY_file" of the disk and extracts a corresponding obstacle item data.

Description

Method of outputting maintenance faults at the exchange {METHOD FOR DISPLAYING ALARM HISTORY DETAIL INFORMATION IN EXCHANGER}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exchange, and more particularly, to a method for outputting a maintenance failure history in an exchange in which a history (HISTORY) and a detailed information (DETAIL INFORMATION) on an ALARM (alarm) generated at an exchange are periodically output at the request of an operator. It is about.

Until now, statistical and history functions have been used as a method of analyzing failures in exchanges. The statistics function is a function of outputting only a failure count for each system, and a history function managed by an MMS or a failure processing block is a function of outputting a history generated by time. Therefore, it is difficult for the operator to expect the exact data that the failure of a certain device has occurred and disappeared over time by using the failure analysis method of a conventional exchange.

Accordingly, an object of the present invention is to provide a method for outputting a maintenance failure history in an exchange that implements a maintenance failure output function of the exchange and outputs history and statistics on failures that occur by device or failure code.

In order to achieve the above object, the present invention provides a maintenance failure history output method in a switch, and when a failure occurs in a software block or a hardware device, the failure type is classified according to a failure code, and then changed into a data format of the same size and stored on a disk. If there is an error data storage process, and an operator request and periodic output request, the error code and the error source for each subsystem are determined by the operator's sort key among the main sort keys that predefine the data read from the disk. Data sorting process of constructing a node tree capable of S (Depth First Search), and after the node tree is formed, the data is read using the D.S., and history details for each subsystem, fault code, and fault source are detailed. Characterized in that the information is made by the display process.

1 is a block diagram of an exchange required to manage maintenance failures of an exchange according to the present invention.

2 is a process diagram of a component for processing and outputting a maintenance fault of an exchange according to an embodiment of the present invention;

3 is a block diagram illustrating a node tree of maintenance failure information according to an exemplary embodiment of the present invention.

4 is a view showing the output format of the maintenance failure history of the exchange according to an embodiment of the present invention;

Figure 5 is a flow chart for outputting the maintenance failure history according to an embodiment of the present invention

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same components have the same reference numerals as much as possible even if they are displayed on different drawings. In addition, in the following description, numerous specific details, such as specific process flows, are set forth in order to provide a more thorough understanding of the present invention. It will be apparent to those skilled in the art that the present invention may be practiced without these specific details. Detailed descriptions of well-known functions and configurations that are determined to unnecessarily obscure the subject matter of the present invention will be omitted.

1 is a block diagram of an exchange required to manage maintenance failures of an exchange according to the present invention;

The failure processing block 10 includes a failure check unit 11 for checking whether a failure of each subsystem # 1 to #N of the exchange occurs, and a hardware (H / W) failure and a software (S / W) failure. Alarm code comparison unit 12 for determining the H / W alarm data conversion unit 13 for extracting the H / W alarm data for the hardware failure from the message to 32 bytes (Byte) data, and S / W alarm data converter 14 for extracting S / W alarm data for software failure from the message and converting the data into 32 bytes of data, and the H / W alarm data converter 13 and S / It is composed of a buffer 15 for storing the data converted by the W alarm data conversion section 14.

The disk 20 generating a file of the contents of the buffer of the failure processing block 10 hourly or daily may be stored in the buffer 15 when the buffer 15 is full and the disk 20 is accessed. The contents are transferred to the HOUR_buffer_file 21, and the HOUR_buffer_file 21 generates a daily file as the DAY file 22 when a specified time (24 hours) elapses. At this time, the buffer 15 is cleared when the buffer 15 is unpacked and the contents of the maintenance failure stored in the HOUR_buffer_file 21 are transferred. In addition, the HOUR_buffer_file 21 generates a 24-hour data record with a size that can store, for example, a fault occurring during 24 hours, and has a characteristic of a circular (CIRCULAR) data. If occurs, overwrites the area of the previous data area. In addition, when the designated time (24 hours) passes, the DAY file is generated. The DAY file 22 is a seven or thirty day data record that is to be deleted after a specified period of time.

2 is a process diagram of a component for processing and outputting a maintenance fault of an exchange according to an embodiment of the present invention;

In order to deal with the maintenance failure history, the present invention is largely divided into three parts, firstly, a disk storage part for a failure message, a second sorting part, and a third display part. First, the disk storage for the failure message is a failure message in the failure processing block 103 that identifies and processes the failure of the software block 101 or the hardware device 102 of the peripheral processor (PP) and the main processor (MP). If a problem occurs, the software failure or hardware failure is classified according to the failure code, and the software failure or hardware failure is reformatted into 32 bytes of data according to the 32-byte data conversion function 104 to change the format. Therefore, when accessing the disk area, data can be easily read by accessing in multiples of 32 bytes. The data conversion function for a software or hardware failure uses an interface function that causes the operator to store only 32 bytes of data for history or statistical display in the failure message. For example, if there is a "00S" failure, there are several data such as EQP_CNT, OOS_CNT, but this is not necessary for the operator, so it ignores all and only stores the count of OOS failure. However, in the case of a disk failure, the information indicating that the disk has failed several times is valid, so the disk number as well as the failure count are stored in the 32-byte data. The thus-converted fault data is transferred to the HOUR_buffer_file 21, which is a disk buffer, when a certain amount is accumulated in the buffer 15 on the memory. In addition, the failure data stored in the HOUR_buffer_file 21 is also transferred to the DAY_file 22 after 24 hours. Therefore, the failure history of the daily data is stored in the DAY_file 22 format. The data stored in the disk 20 are selectively accessed and displayed at the request of the operator. The node 20 is arranged by arranging 32 bytes of data read from the file in the sorting part, which is the second failure processing part, before the display. do. The sorting portion will be described in more detail; The hardware failure format of the 32-byte fault data is configured as shown in Table 1 below, and the software failure format is configured as shown in Table 2 below.

Information Information form Subsystem NumberAlarm Code DateAlarm On_OffFI_InxSrc_NoDummyDummyDummy BYTESHORTData type (8 bytes) BYTEINTINTINTINTINT Total 32 Byte

Information Information form Subsystem NumberAlarm Code DateAlarm On_OffIpc_AddrCd_Dev_NoIn_Ch_NoDupli_InfoInform BYTESHORTData type (8 bytes) BYTEINTINTINTINTINT Total 32 Byte

As shown in Table 1 and Table 2, in the case of hardware failure and software failure, the format of the failure data transmitted from the lower block to the upper block is different from each other. However, there is no problem in reading the data by accessing the disk by storing the data in the same size. The read data is processed in the failure processing block 203 according to the key value according to the operator request 201 and the periodic output request 202. The 32-byte data inverse transform function 24 through the data inverse transform table 205 is used. In operation 206, the node tree as shown in FIG. 3 is generated. Here, the priority condition of the key is a service system number, an error code, and a date, and the other key values are different for each error code, and thus a sort key table for each error code is provided. Thus, when the node tree is constructed, a tree capable of depth first search (DFS) for a failure code and a failure source for each subsystem is formed. When the node tree is formed and then searched using the DFS 301, the node tree is output to the operator in the display format as shown in FIG. 4. Here, FIG. 3 shows maintenance failure information according to an exemplary embodiment of the present invention. A node tree structure diagram of 32-byte data read from the disk 20 is included in the main sort key. The main sort key includes a subsystem number, an error code, a date, and an error_on_off. When the node tree is configured, the node tree is read, and then read to Depth First Search (DFS) to output alarm on / off for each subsystem, fault code, and fault source.

4 is a view showing the output format of the maintenance failure history of the exchange according to an embodiment of the present invention.

The display portion output to the operator will be described in detail; The display part refers to a method of searching for data required by an operator. When there is a display request for history data within 24 hours from the current time, the buffer 15 and the HOUR_buffer_file 21 Can be printed by referring to). If there is data corresponding to the output request time in the contents of the buffer 15, even if the buffer 15 is not stacked in a full, the HOUR_buffer_file 21 is moved to the HOUR_buffer_file 21 The data is retrieved from (21). This simplifies the processing routine, which is divided into two paths for hourly data requests.

Data older than 24 hours based on the current time are directly accessed after the DAY_file 22 is retrieved and output. The storage period of the DAY_ file 22 can be changed according to the needs of the operator, and the DAY_ file 22 after the storage period can be automatically deleted to efficiently use the available space of the disk 20. do.

The output format of the maintenance failure history as shown in FIG. 4 is divided into subsystems, and the software and hardware failures are classified from higher concepts to grades (CRI, MAJ, MIN), failure codes, and lower detail information. Divided. In the display part of the present invention, the effect of the maintenance can be expected to be divided into detailed information. For example, in the past, only one fault of the A5000 was generated, but in the output format as shown in FIG. As you can see, ASPP0 can identify the failure at 09:34:10. In addition, in case of hardware failure, the SDU (Serial Device Unit) can determine how the alarm occurs in STU0 and STU1, so that the failure and diagnosis of the device can be easily identified. In addition, the error generated by the alarm source and the error generated by the alarm source, and the hardware error generated by the device can be easily recognized by the operator.

Figure 5 is a flow chart for outputting the maintenance failure history according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the flowcharts of FIG. 5 with reference to FIGS. 1 and 5.

First, as described above with reference to FIG. 1, a failure message is generated and stored in the disk 20 at an hourly and daily time.

If the operator makes a MMC (man machine communication) or a periodic output request in step 501, the error processing block 10 or 203 determines the output request data time in step 503. If the output request data time discrimination result is a time-based data request, step 505 is performed.

In step 505 where the output request data time is a time-based data request, it is determined whether data to be output is stored in the buffer 15 in the failure processing block 10 or not. If the buffer 15 is stored in the buffer 15, the process proceeds to step 507, and if the data to be output is not in the buffer 15, step 521 is performed. In step 507, the failure processing block 10 controls the buffer 15 to move the contents of the buffer to the HOUR_buffer_file 21 of the disk 20 in step 509. Clear the contents stored in). Thereafter, in step 511, the error processing block 10 searches for the HOUR_buffer_file 21, extracts the corresponding error history data, and proceeds to step 541. On the other hand, if the process proceeds to step 521, the error processing block 10 searches only the HOUR_buffer_file 21 to extract the corresponding failure history data and proceeds to step 541.

In addition, in step 531 where the output request data time determination result of step 503 is determined as a one-day data request, the error processing block 10 proceeds to step 533 to search for the DAY_ file of the disk 20 to determine a corresponding error. After extracting the historical data, the flow proceeds to step 541.

In step 541, the failure processing block 10 or 203 generates a node tree as shown in FIG. 3 as described above in the sorting part of FIG. In step 543, the failure processing block 10 searches the generated node tree using the DFS method using the DFS unit 301 and the display unit 303 in the display portion of FIG. Outputs detailed history information by code and device. As an example, the output form of FIG. 4 is the same.

On the other hand, the detailed description of the present invention has been described with reference to specific embodiments, of course, various modifications are possible without departing from the scope of the invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, the present invention has an effect that the operator can easily identify the exchange failure by expressing the history and statistical function output for the failure processing data generated in the exchange in one output form instead of the different output forms.

In addition, the present invention has an effect that the operator can accurately identify the failure and diagnosis of the equipment by hardware and software by providing a history function and a statistical function for each failure source or device equipment as well as for each failure code.

Claims (5)

In the maintenance fault output method at the exchange, When the failure of the software block or hardware device occurs, the failure data storage process of classifying the failure type according to the failure code and changing the data format to the same size and storing it on the disk; If there is an operator's request and periodic output request, Depth First Search is performed for each subsystem, fault code and fault source by the operator's sort key among the pre-designated main sort keys. The data sorting process of constructing a node tree, After the node tree is configured, the history fault information output method of the exchange is performed by reading the detailed information on each sub-system, fault code, and fault source by reading through the D.S. The method of claim 1, The disk is composed of an hourly buffer file and a daily file, and when data of a specified size of the hourly buffer file occurs, the failure data stored in the daily file is transferred to the daily file to generate a maintenance fault. Output method. The method of claim 2, The daily file is a maintenance failure output method of the exchange, characterized in that for deleting a stored data after a predetermined period of time. The method of claim 3, The pre-specified main sort key is a subsystem number, fault code, date, fault on / off key, characterized in that the maintenance failure output method. The method of claim 4, wherein When the display process is performed, the display format is divided into sub-systems, and then the software and hardware faults are divided into grades, fault codes, and lower detail information. How to print the details.