JP2868032B2 - Data storage method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data storage system,
In particular, the present invention relates to a failure data storage method when logging failure data to a specific area by a program. FIG. 7 is an explanatory diagram of an industrial application field of the present invention. One application field of the present invention is, for example, a firefighting system, and FIG. 7 is a system configuration diagram of the firefighting system. In the figure, 71 is a private branch exchange, 72 is a key operation console of a fire center, 73 is a trunk (ATTC) for monitoring which key of the key operation console has been pressed, 74 is a control device (CTL), and 75 is fault information. Dump memory, 76
Is an interface package, 77 is a display board mounted with a lamp that lights up according to the location of the failure, and 78 is an external device.

In such a system, when a failure occurs in the data line between the private branch exchange 71 and the control device 74, the key operation console, or the like, the failure information is dumped to a memory 75 and is transmitted via an interface package 76. The corresponding lamp on the display board 77 is turned on.

[0003]

2. Description of the Related Art In a conventional method of logging fault data by a program, fault data is logged in a specific area (for example, an area capable of storing a maximum of eight fault data). The first failure data is overwritten, and when it reaches again, the failure data is logged in the first area.

For example, when logging failure data to a memory area capable of storing a maximum of eight data, failure data having a ninth logging count (failure error count) is stored in the first logging area and logged. . Also, 1
The seventh failure data is again written over the area in which the ninth failure data is stored and logging is performed.

When the generated fault data is checked by memory dumping, it is possible to check the fault trajectory that has occurred up to now, but it is not possible to check which fault is currently occurring, that is, which is the latest fault data. Problems arise.

[0006]

SUMMARY OF THE INVENTION A system failure is performed by dumping logged failure data into a memory and determining which failure is the latest failure among failures that have occurred up to now, what is currently occurring failure, and the like. Sometimes you need to check.
However, this cannot be confirmed by the conventional method, and it may be difficult to deal with the failure. In addition, the efficiency at the time of the system test also decreases.

An object of the present invention is to make it possible to recognize which area data is the latest event data when data corresponding to an event is sequentially stored in a plurality of areas in the order of occurrence of the event. .

[0008]

FIG. 1 is a block diagram showing the principle of the present invention. In the figure, 1 is an event receiving means,
Reference numeral 2 denotes a plurality of areas 1 in which data corresponding to the event received by the event receiving means 1 is consecutively arranged in the order of occurrence of the event.
.., 1n, and the next event after being stored in the last area overwrites the first area. And a landmark code storage control means for storing a final event identification code different from the above-mentioned code in an area next to the storage area of the generated final event. Last event identification code stored in the following area
Is overwritten by a new final event following the final event
Will be

[0009] Each of the events is preferably a fault in the communication system.

[0010]

With the conventional logging method, there is no method that can be used as a mark for confirming the newest failure, and thus the above-described problem has occurred. Therefore, in this failure data logging method, a landmark code is stored in the storage area next to the newest failure data (current failure).

[0011]

FIG. 2 is a functional block diagram of firmware in the control device 74 in FIG. 7, for example. In the figure, 21 is an L1 control processing unit, 22 is an alarm processing unit, 2
Reference numeral 3 denotes an SD processing unit. FIG. 3 is a flowchart showing the flow of processing of the fault data in the alarm processing unit 22. In FIG. 3, when the alarm processing unit 22 receives a failure event code from the L1 processing unit 21 in step 31, it determines in step 32 whether the reception is normal or not. Based on the information, it is determined in step 33 whether a failure has occurred or has been recovered,
When a failure occurs, the cause of the failure is determined in step 34, and the cause of the failure is logged in the storage area. The present invention relates to an improvement in this fault occurrence processing.
If it is a failure recovery event in step 33, step failure recovery processing is performed in the same manner as in the related art. If the event is not normally received in step 32, failure processing is performed in step 36 as in the prior art.

FIG. 4 is a diagram showing the contents of the event code transmitted from the L1 control processing unit 21 to the alarm processing unit 22. In the figure, the alarm processing unit 22 receives an event code including a code, an extension, and control information corresponding to a line. The code in the event code is for identifying the type of the event. For example, there is an instruction such as whether the event is a failure or how many seconds later the lamp process is performed. The extension is fixed to “0” in the case of an alarm. The control information includes information indicating a cause of failure (failure information) at the time of the failure event. For example, “0” indicates recovery of communication failure, “1” indicates occurrence of communication failure, and “2” indicates monitoring of line status. Program failure recovery, "3" indicates failure of line status monitoring program, "4" indicates normal loop test,
“5” indicates a loop test abnormality.

Conventionally, only such control information is identified as an even number or an odd number. If the control information is even, it means that the event has been recovered. The corresponding lamp is turned off. Only the control of turning on the lamp to be performed was performed. FIG. 5 is an explanatory diagram of a fault data processing area including a logging area according to the embodiment of the present invention. As shown in the figure, the fault data processing area includes an area recognition code, a fault type map, a fault count, a fault storage area recognition code, and eight fault storage areas. This failure data processing area exists in the memory 75 in the system of FIG.

The system of the present invention is applied to the eight fault storage areas shown in FIG. That is, a final event identification code different from all codes of data corresponding to the event is stored in the area next to the failure storage area of the final event. For example, as described above, when a fault cause that has occurred is stored in an area having a maximum storage number of eight, a landmark code (for example, “F”) is stored in the area next to the storage area.
FFF ": This code logs a data value which is considered to be stored and which is absolutely impossible at the same time when the fault data is stored.

When logging the eighth failure, which is the maximum number of storages, the mark code is "FFFF" in the first area.
F "is stored. When logging the next fault data, the fault data is stored in the first area and" FFFF "is stored in the next area. The above processing is repeated every time fault data is received. 6 is a flow chart showing the flow of the process of storing data in the fault storage area (step 34 in FIG. 3) when a fault occurs according to the embodiment of the present invention, in which step 61 is shown in FIG. A failure display event is transmitted to the SD processing unit 23 (FIG. 2) based on the control information, and the failure information is written in the failure type map in the memory 75 shown in FIG.
Then, the number of failures is counted up as in the conventional case. In step 64, the failure factor is written in the failure factor storage area (A). Finally writing mark code "FFFF" to the fault-rated Osamee rear (A + 1) in step 65.

By the above processing, by detecting the landmark code, it is known that the latest failure data is stored in the area immediately before the landmark code, and the failure data seven times before the latest failure data can also be confirmed. Therefore, the storage area may be obtained in consideration of the degree of confirmation of the trajectory of the fault that has occurred up to the present and the usage of the limited memory area. In the above description has dealt with the process of the fault data in fire system, the present invention is not limited to this but is also Hisage possible provided against the storage of any data.

[0017]

As is apparent from the above description, according to the present invention, at the time of system operation and system test, the latest failure occurrence status is confirmed, and the past failure occurrence status is confirmed from the previous dump contents. Can be easily performed.
Therefore, the efficiency of the test process can be improved.

[Brief description of the drawings]

FIG. 1 is a principle block diagram of the present invention.

FIG. 2 is a functional block diagram of firmware in a control device in FIG. 7;

FIG. 3 is a flowchart illustrating a flow of processing of failure data in an alarm processing unit.

FIG. 4 is a diagram showing the contents of an event code.

FIG. 5 is an explanatory diagram of a failure data processing area.

FIG. 6 is a flowchart showing a flow of processing for storing data in a failure storage area when a failure occurs according to an embodiment of the present invention.

FIG. 7 is an explanatory diagram of an industrial application field of the present invention.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 ... Event time means 2 ... Data storage control means 3 ... Mark code storage control means 11 ... Event data storage area 12 ... Mark data storage area

────────────────────────────────────────────────── ─── Continuation of the front page (56) References JP-A-57-152579 (JP, A) JP-A-62-47759 (JP, A) "Iwanami Information Science Dictionary" (Heisei 2-5-25) Iwanami Shoten Page 714, left column (58) Field surveyed (Int.Cl. ⁶ , DB name) G06F 11/28-11/34

Claims (2)

(57) [Claims] 1. A and event receiving hand stage, data corresponding to the event received in the event reception hand stage stored sequentially <br/> following multiple area A continuous chronological order of the events, the last area and data storage control <br/> means to so as to overwrite the first area next event after being stored in, all code with different final event identification code data corresponding to each of the event, generated final Lee <br/> mark code storage control hand stage and, is provided with a store in the next area were the final event in the following areas of the storage area of the vent
The identification code is the new last event following the last event.
A data storage method characterized by being overwritten by a client . 2. The data storage method according to claim 1, wherein each of said events is a failure in a communication system.