KR100206472B1 - Error manage & recover method of switching system - Google Patents

Abstract

end. The technical field to which the invention described in the claims belongs:

System failure management and recovery method in electronic switchboard

I. The technical problem the invention is trying to solve:

It enables the system to quickly recover from system failures such as hardware and software failures that may occur at the electronic switchboard.

All. The gist of the solution of the invention:

It detects and stores system failures such as hardware and software failures that can occur at all electronic switchboards, and analyzes the system failure history and recovers the system failures quickly.

la. Important uses of the invention:

Electronic exchanger maintenance

Description

System failure management and recovery method in electronic switchboard

TECHNICAL FIELD The present invention relates to an electrical exchanger, and more particularly, to a method for performing system failure management and recovery of an electrical exchanger.

There are about 200 call routines of the user program provided by the general operating system (Operating System) of the electronic switching system. If the user programmer misuses the OS, the OS handles the normal processing. You will not be able to perform the action. In this case, the OS notifies the user programmer of the error. However, if the system crashes due to a hardware or software error while the system is running, the OS does not store the information about the error itself.

Therefore, in the prior art, due to hardware or software problems during the operation of the switching system, the failure of the system is difficult to grasp because the system does not store information on the system failure when the system is restarted. As a result, there is a problem that it is difficult to quickly fail over.

Accordingly, an object of the present invention is to provide a method for quickly recovering system failures such as hardware and software failures that may occur in an electronic switch.

It is another object of the present invention to provide a method for detecting hardware and software failures that may occur in an electronic switchgear, performing a quick recovery process, and notifying an operator of a system failure through a user port.

In accordance with the above object, the present invention can detect and store system failures such as hardware and software failures that may occur in the electronic switchboard, and then analyze the failure details of the system to quickly recover the failure of the system. I aim to make it.

1 is a block diagram for functionally explaining system failure management and recovery in an electronic switch according to an embodiment of the present invention.

2 is a block diagram of OS managers configured for fault detection and output and fault management and recovery according to an embodiment of the present invention.

FIG. 3 is a flowchart illustrating an operation of the process manager 22 of FIG. 2 for checking a process abort fault.

4 is a configuration diagram of a memory map for collecting and storing faults according to an exemplary embodiment of the present invention.

5 is a configuration diagram of a memory map for recovering from a failure according to an embodiment of the present invention.

FIG. 6 illustrates an embodiment of memory area allocation for fault collection storage and recovery; FIG.

7 is a view for explaining a method for managing and recovering disability information according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the same elements in the figures are denoted by the same numerals wherever possible. In addition, detailed descriptions of well-known functions and configurations that may unnecessarily obscure the subject matter of the present invention will be omitted.

The OS of the electronic switch according to the embodiment of the present invention is a collection of various functions (i.e., fault detection function, fault management function, fault recovery function, and fault output function) within 20 blocks of FIG. To provide. Referring to FIG. 1, when a user program for driving a specific function is driven by driving a system, the user program unit 2 detects a generated failure in the OS and notifies the failure detection function unit 4. The fault detection unit 4 detects a fault generated while various managers of the OS perform various functions, and informs the fault management function 6, the fault recovery unit 8, and the fault output unit 10, respectively. The fault management function unit 6 receives the fault information, analyzes the content of the fault information into detailed fault information, and stores the data in a memory that does not change even when the processor is restarted. The detailed fault information stored in the memory is used by the failback function unit 8 when performing fault recovery. The fault recovery function unit 8 performs the fault recovery function according to the fault level by referring to the detailed fault information stored in the memory of the fault management function unit 6. The fault output function unit 10 outputs a message to the operator port so that the operator can view the generated fault information. This allows the operator to take quick action on system failures.

FIG. 2 is a block diagram illustrating OS managers that perform the functions described with reference to FIG. 1. The OS managers of FIG. 2 include eight managers except for process manager 22, that is, an IPC manager 24, a memory manager 26, and an I / O manager. 28, a duplication manager 30, an exception manager 32, a time manager 34, a file manager 36 and a failure manager 38.

Among the managers of FIG. 2, each of the process manager 22, the IPC manager 24, the memory manager 26, the I / O manager, the redundant manager 30, the exception manager 32, the time manager 24, and the file manager 26 are each the fault detection unit 4 of FIG. 1. Perform the function of and the function of fault output function unit 10 together. Among the managers of FIG. 2, the fault manager 38 performs the functions of the fault management function unit 6 and the fault management recovery function unit 8 of FIG. 1.

A schematic operation of each of the managers 22 to 36 in FIG. 2 that performs the fault detection and fault output functions will be described below. The process manager 22 performs general management of each manager, the IPC manager 24 performs internal and external communication management of sending and receiving message information, and the memory manager 26 integrates and manages memories. The I / O manager 28 manages MMC (Man Machine Communication) processing operations, and the duplication manager 30 manages operation / standby state control of the redundant system. In addition, the exception manager 32 performs interrupt processing related management, and the time manager 34 performs management related to the current system time. The file manager 36 manages the HDD (Hard Disk Drive) and the MTU (Magnetic Tape Unit).

The OS of the present invention implemented with the management functions as shown in FIGS. 1 and 2 is easy to detect problems of the control system hardware and the user program due to its nature, and systematically collects various failures and performs appropriate software recovery with the collected contents. In addition, the recovered results can be forwarded to the operator in detail.

Referring back to FIG. 2, eight managers 22-36, including process manager 22, report all types of OS failures caused by an event to failure manager 38. The fault manager 38 collects and stores the reported faults of each manager by type and stores and manages the fault information according to the manager's request. After the failure and failure information of the failure manager 38 is collected and stored, the failure manager 38 starts the recovery process corresponding to the failure. On the other hand, the managers that have failed generate the facts such as Problem, Reason, Action, and Information to the operator as soon as the failure manager 38 starts the recovery process. At this time, the failure occurrence and the processing result delivered to the operator are first processed to be considered important in terms of service of the control system.

Hereinafter, a description will be given of several types of operations for detecting and recovering the faults of the fault manager 38 and the fault manager 38.

(1) In Line Check

In-line checks are performed at all managers 22-36 in FIG. The OS of the TDX exchange provides about 140 primitives to the user and performs normal functions through many procedure calls between 0S. Most of these user primitives or the OS's own procedures require a service through parameter passing and start performing the service. Therefore, if the error of the parameter to be passed is not detected immediately, it can have a serious effect on the down time of the system. In this respect, parameter checks (input parameter validation, index validation of critical data, validation before using address pointers) are performed, focusing on those that can have a serious impact on user primitives and OS procedures.

(2) Obstacles when calling system primitives

The failure in calling the system primitive is checked anywhere in the managers 22-36 of FIG. The causes of failure are as follows. Primitives provided by the current OS can be classified into three types: user primitives, system primitives, and database primitives. These primitives are further divided into several functions, each of which is assigned a specific number, which is called a direct number. The user primitive can perform the desired primitive by putting the directive number in the d0 register and performing trap 1, and the system primitive can perform the desired primitive by putting the directive number in the d0 register and performing trap 0, Database primitives can perform the desired primitives by placing a directive number in the d0 register and performing trap 2. However, there is a limited number of directives in each group, and this fault occurs when the user program is out of this range due to misuse of the user program, or when the primitive execution is requested by an unassigned directive.

The treatment method at this time is as follows. In the operating system, each trap handler checks whether the number requested by the user program is out of the range provided by the user program, and executes the corresponding primitive when the number is provided. Or an unassigned primitive is passed an error value.

(3) parameter error failure

The parameter error fault is also checked anywhere in the managers 22-36 of FIG. The causes of failure are as follows. Among various primitives provided by the OS, it is necessary to pass various values to the user program after executing the primitive. In this case, the user program must allocate memory in its own area or in advance, and pass the address of this memory to the OS as a designated parameter of the primitive. However, this error occurs when the value of the parameter outside the address area of the user program is passed to the OS due to the error of the user program.

The treatment method at this time is as follows. The processing routines of each primitive in the OS need the memory address of the user program among the necessary parameters and check whether the parameter value exists in the address area of the user program.

(4) Process abort failure handling

The process abbot check is performed in process manager 22 of the managers of FIG. 3 is a flowchart illustrating an operation of the process manager 22 for checking a process abbot failure. Referring to FIG. 3, the process abort may occur in an outmost process corresponding to a higher process or may occur in a child process corresponding to a lower process.

In the case of outmost process abbott, all processors of the block are aborted and the outmost is recreated, and the fact is reported to fault manager 34. Next, in the case of a child process abort, it only aborts the child process and signals this fact to the block out-most process. In addition, if self-processing is possible, after the failure of the process abbot, this fact is reported to the failure manager 38 so that the failure history can be stored.

(5) Bus error fault handling

The process abort failure check is performed in the exception manager 32 of the managers of FIG. The causes of failure are as follows. If the memory limit exceeds the currently available memory due to a bug in the user program or OS code, it is triggered to the software from the CPU by the trigger of the memory management unit (MMU) inside the central processing unit (CPU). This may cause software data errors, memory failures, and so on. This is the case when a long bus or short bus error exception occurs.

The treatment method at this time is as follows. In case of OS area, check whether the bus error location is OS area or user program area in the bus error handler of the OS. If the OS area is not read-modify-write cycle, it will be transferred to the standby state after changing. In the case of the Read-Modify-Write cycle, the bus error is caused by an MMU fault and the bus error is handled in the same way as stack grow. If it is possible to recover by software, it can be restored and run normally. If not, it sends a fault message to the user program and aborts the user program.

(6) file / filesystem full check

A file / filesystem full message means, for example, that 300 megabytes of disk space is full and no more disk space can be allocated to the user. Check this in file manager 36.

(7) I / O device open error check

An error occurs when the user program opens to use a device that does not exist in the system. The I / O manager 28 of the managers of FIG. 2 checks this.

(8) IPC / IPC queue pool fault check

The failure may be caused by user programs sending excessive IPC messages, exhausting IPC queues initially allocated by some other cause (e.g., a bug in the OS code), or corrupting the IPC queues by abnormal performance. Occurs when the above free queue cannot be allocated. This fault check checks this in the IPC manager 24 of the managers of FIG.

(9) check for memory write violations

This occurs when the write prohibition area of the memory is written, which is checked by the memory manager 26 of the managers of FIG. 2.

(10) Check the cause of time / timetable pool

The creation of a timetable pool occurs when a time job uses all of the timetables without timing out. That is, no table can be used for the free list linked list. In this case, the time manager 34 of the managers of FIG. 2 checks this.

When a failure of the same kind as in the above examples occurs, the failure manager 38 of FIG. 2 that performs the failure management function and the failure recovery function, receives the failure information, analyzes the contents thereof, makes detailed failure information, and stores the data even when the processor is restarted. It is stored and stored in a memory that does not change, and when performing a fault recovery function, it performs a fault recovery function according to a fault level by referring to detailed fault information stored in the memory.

4 is a memory map configuration diagram for collecting and storing fault fault information implemented in the memory of the fault manager 38. The buffer area 40 stores the number of fault occurrences of each OS manager, and detailed fault data of each OS manager. It has a storage buffer area 50 and a primary and secondary recovery flag information buffer area 60 for each OS manager.

Among the abbreviations in buffer areas 40, 50, and 60 of FIG. 4, PM is process manager 22, MM is memory manager 26, IM is IPC manager 24, TM is time manager 34, FS is file manager 36, and IO is I / I. It should be understood that O manager 28, EM stands for egress manager 32, and DM stands for redundant manager 30. Based on this understanding, looking at the contents displayed in the buffer area 40 that stores the number of failures of each OS manager of FIG. 4, for example, PM_fcntr [150] is the fault occupancy counter table of the process manager 22. Means that there are 150 rooms. In the buffer area 50 of FIG. 4, for example, PM_finform [150] [10] means that there are 150 fault information tables of the Process Manager 22 and 10 detailed information rooms of each room. In addition, in the buffer area 60 of FIG. 4, for example, PM_rhis [150] means that there are 150 rooms of a fault recovery history table of the process manager 22.

FIG. 5 is a diagram of a memory map for fault recovery implemented in the memory of the fault manager 38, and has fault recovery table frtble [] for all managers 22 to 36 of FIG. Each fault recovery table frtbl [] contains information such as fault code, fault level, primary recovery routine data, secondary recovery routine data, and so on.

FIG. 6 is a diagram illustrating an embodiment of memory area allocation for fault collection storage and recovery, in which an address is assigned to each buffer area and a table.

FIG. 7 is a diagram for describing a method for managing and restoring failure information performed by the failure manager 38 of FIG. 2 according to an exemplary embodiment of the present invention.

Now, if any of the above types of faults occur in any of the managers 22 to 36 in Fig. 2, the fault manager 38 in Fig. 2 is notified of the fault. The failure manager 38 determines in step 100 of FIG. 7 whether the failure information is a fault code belonging to each manager, and proceeds to step 102 only when the fault code belongs to each manager. In step 102, the failure information is received and the contents are analyzed and detailed failure information suitable for various management groups, that is, the number of failure occurrences for each management unit, detailed data information for each management unit, and primary for each management unit as mentioned in FIG. The second recovery flag information is created and stored in the corresponding management table among the buffer areas 40, 50, and 60 shown in FIG. In addition, detailed failure recovery information such as a fault code, a fault level, a primary recovery routine, and a secondary recovery routine is stored in the corresponding recovery table as shown in FIG. 5.

Thereafter, the failure manager 38 performs a failure recovery function according to the failure level by referring to detailed failure recovery information stored in the fault recovery table frtbl [] of FIG. 5. At the same time as the failure recovery function is performed, each manager that has failed generates a problem, reason, action, and information to the operator through the operator port, for example, printer, PC screen, CRT, etc.

The failover function is performed by the operations of steps 106 through 112 of FIG. 7. First, in step 106 of FIG. 7, the failure manager 38 determines the first fault recovery by referring to the presence or absence of the first recovery flag of the corresponding fault recovery table rhis [150] in the buffer area 60 of FIG. 4. If the recovery flag is set, go to step 108. In step 108, the fault recovery is performed by using the data of the primary recovery routine in the corresponding fault recovery table frtbl [] of FIG. 5, and in step 110, the buffer area 60 of FIG. Set the secondary recovery flag of the corresponding fault recovery history in rhis [150].

On the other hand, if the fault primary flag is not set in the determination of step 106 of FIG. 7, it is confirmed that the fault secondary flag is set and the process proceeds to step 112. In step 112, the failure recovery is performed by using data of the secondary recovery routine in the corresponding fault recovery table frtbl [] of FIG.

On the other hand, the operator knows the failure occurrence sent by each manager that failed while the failover function is being performed through the printer, PC screen, and CRT.

In the present invention described above, by analyzing the fault systematically, collecting it using a specific memory, performing appropriate software recovery according to the type of the fault, and implementing various fault managers that can deliver the result of the fault to the operator in detail. Improve the ability to tolerate failures and communicate the results of internal treatments to operators in detail. In addition, all information about faults is stored in a specific memory that cannot be cleared even if the processor is restarted. Then, the fault information is analyzed and the information is updated quickly for system problems. And action can be taken.

In the above description of the present invention, specific embodiments have been described, but various modifications can be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be defined by the described embodiments, but should be defined by the equivalents of the claims and the claims.

As described above, the present invention immediately detects the failures occurring in the exchange system and allows them to be recovered within the minimum system loss range before they affect the system, and the operator can immediately recover through the failure collection and output function. It has the advantage of being able to understand the state of the system and cope with it.

Claims (6)

A system failure management and recovery method in an electronic switch having a plurality of managers for detecting and outputting a system failure and managing and recovering the failure, Detecting a failure caused by a software or hardware failure in the system by using a detection manager; Analyzing the faults detected by the corresponding detecting manager to make detailed fault management and recovery information for each type and storing them in a memory for fault management and fault recovery; And when the detailed information of each type is stored in the memory, performing a recovery process by referring to the stored detailed failure recovery information and outputting the generated failure information to an operator. The method of claim 1, wherein the detection manager is Process manager for general management of each manager, IPC manager for internal and external communication management for sending and receiving message information, memory manager for integrating memories, I / O manager for managing MMC (Man Machine Communication) processing operation, redundancy Redundancy manager that manages the operation / standby state control of the old system, Eception manager that performs interrupt-related management, Time manager that performs management related to the current system time, HDD (Hard Disk Drive), Magnetic Tape Unit (MTU) Method comprising a file manager for performing management for driving. The memory of claim 1, wherein the memory for fault management and fault recovery is A fault management memory unit including a buffer area for storing the number of failures of each manager, a fault data storage buffer area for each manager, and a primary and secondary recovery flag information buffer area for each manager; Method comprising a failover memory section having a fault recovery table for all managers. 4. The method of claim 3, wherein the fault recovery table includes information such as a fault code, fault level, primary recovery routine data, secondary recovery routine data, and the like. 4. The method of claim 3, wherein the buffer areas have tables for each manager. 6. The method of claim 5, wherein the tables have 150 rooms.