JP2002319940A - Information sharing system and information sharing method, and program for executing the method - Google Patents

Abstract

(57) [Summary] [Problem] Database of know-how and a series of protocol flows
The stored phenomenon is collated with the stored information in the DB and used for dealing with the occurred phenomenon. SOLUTION: When monitor data at the time of failure is input from a monitor data input function 1 to a DB construction function 2, data of an analysis result by the DB construction function 2 is recorded in an analysis result DB3. Further, data is input from the analysis result DB 3 to the DB collating function 4, collated with past data recorded in the abnormal phenomenon DB 6, and if a similar phenomenon exists, it is dealt with according to a predetermined measure. If a similar phenomenon does not exist, the test scenario automatic generation function 8 creates a scenario for the reproduction test, collects the countermeasures after the analysis, records it in the analysis result DB 3, and accumulates it as know-how. Further, data is input to the analysis function 5 from the analysis result DB 3 and is visually displayed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to an information sharing system for sharing information stored in a database.
In particular, the present invention relates to an information sharing system for accumulating and sharing failure information generated at a site or the like in a database and performing an early response when a failure occurs based on the accumulated information.

[0002]

2. Description of the Related Art Generally, know-how and the like are stored personally, and in order for other people to use the know-how, a method of listening to information or working together is a general method such as a master. It has been done. Therefore, when a failure occurs at a site or the like, a person in charge who has experienced in the past responds or responds by hearing information from the person in charge who has experienced it. Alternatively, based on an invoice document such as a daily report, a failure which has occurred while acquiring past failure information is dealt with.

[0003]

However, if there is no person who has experienced before acquiring past information, the know-how possessed by that person generally disappears. Therefore, past failure cases must be dealt with as new phenomena, and as a result, early response at the time of failure occurrence becomes impossible. Also, the know-how accumulated by the person in charge may be limited to the person in charge who can use it, or if the know-how is inherited, the continuity of the existing information may be lost and the same or similar response may be repeated. As a result, the response may be delayed.

The present invention has been made in view of such circumstances, and has as its object to accumulate know-how and a flow of a series of protocols in a database, and to collate the occurred phenomenon with information accumulated in the database. Accordingly, it is an object of the present invention to provide an information sharing system that can appropriately extract and use desired information.

[0005]

In order to solve the above-mentioned problems, an information sharing system according to the present invention is an information sharing system for sharing and effectively using information stored in a database. Using the flow of the generated protocol as a search key, the database is checked against the past information by the check function of the database. If the information does not exist in the database, create and analyze a scenario that reproduces the information,
It is characterized in that it is stored in a database as new information.

That is, according to the information sharing system of the present invention, first, protocol data of information (ie, a phenomenon) generated at a site is input. Here, the protocol data is ISDN (Integrated Services Digital Network).
k) and data such as IP (Internet Protocol).
Then, it is checked whether a similar phenomenon has occurred in the past. At this time, a series of flows of the protocol in which the phenomenon occurred is used as a search key of the database. If a similar phenomenon exists in the database in the search result, a measure is taken according to a predetermined measure. On the other hand, if a similar phenomenon does not exist, a scenario for a reproduction test for reproducing the phenomenon is created and analyzed, and new coping methods are collectively registered in a database and accumulated as new know-how. In this way, the search key of the protocol in which the phenomenon occurred, the procedure of the reproduction test scenario, and the procedure of the coping method are stored as one item in the database, so that it can be used immediately when the phenomenon occurs again to cope with the situation immediately. It can be performed.

[0007] Further, when the information sharing system of the present invention is applied to a high-performance protocol tester, a specific configuration is as follows.
A monitor data input function for inputting monitor data of generated failure information, and monitor data input by the monitor data input function are analyzed according to items such as time, a partner terminal, and normal / abnormal of an incoming / outgoing call, and a list is displayed. A database construction function, an analysis result database that stores monitor data input by the monitor data input function and data on past fault information, and a fault that occurred this time using search keys such as sequence patterns, line transmission capability, and reasons for line disconnection A database collation function for collating whether the monitor data relating to the information matches the data relating to the past failure information, and a call included in the data in order to easily discriminate the failure information generated this time from the past failure information. An analysis function that visually displays the status sequence and information on past failure information An abnormal phenomenon database that stores data to be stored, a test scenario database that stores test scenarios for failure information reproduction tests and basic function confirmation tests, and a test scenario for reproduction tests automatically based on information from monitor data. It is characterized in that it has a test scenario automatic generation function for generating automatically and a pseudo-terminal function for performing a reproduction test and a degress test by performing a continuous test by combining various test scenarios constructed in each database.

That is, the information sharing system of the present invention,
In other words, according to the high-performance protocol tester, the know-how accumulated in the individual is stored in a database, so that the information so far can be continued even if the person in charge changes. Therefore, it is possible to collate whether or not a past case exists at the time of reoccurrence of a failure phenomenon, and if so, take immediate action based on the experience of the past case. In addition, a new failure mode in which no past case exists can be stored as a new asset in the database, and can be used for future failure phenomena.

Further, in the information sharing system of the present invention, that is, the high-performance protocol tester, in the comparison result of the database collation function, the monitor data relating to the failure information generated this time does not match the data relating to the past failure information. At this time, the test scenario automatic generation function automatically generates a test scenario for the reproduction test from the monitor data, saves the test scenario in the analysis result database, transmits the test scenario to the pseudo terminal function, and reproduces the test or degrades the pseudo terminal function. It is characterized by performing a test. That is, according to the high-performance protocol tester of the present invention, a newly generated failure mode is stored as a new asset in the database, and can be used for future failure phenomena.

The high-performance protocol tester of the present invention installs a database construction function, a database collation function, and an analysis function on a personal computer, and executes IPA (Integer).
rnet Protocol Address) analysis tool. Further, the high-performance protocol tester of the present invention includes an IPA analysis tool, an IPA terminal for extracting failure information of the exchange, a common database server including a database for storing data from the IPA terminal, an abnormal phenomenon database, and a test scenario database. A LAN is constructed, and the IPA analysis tool analyzes the failure information of the exchange at a remote location. That is, in the related art, a person in charge of performing a failure analysis at a place where a workstation (WS) in which an IPA terminal is incorporated or a remote analysis using a paper base such as a facsimile (FAX) is used. The analysis can be performed on a personal computer in an office by using a suitable IPA analysis tool.

Further, the information sharing method of the present invention is an information sharing method for sharing information stored in a database and making effective use of the information. The procedure for collating with past information by the collation function, and in the search result, when similar information exists in the database, the procedure for coping according to a predetermined coping method;
When similar information does not exist in the database, the method includes a step of creating and analyzing a scenario for reproducing the information, and then storing the scenario in the database as new information.

A specific information sharing method when the information sharing method of the present invention is applied to a high-performance protocol tester is an information sharing method in which failure information stored in a database is shared and used effectively. A procedure in which monitor data of failure information is input to a database construction function from a monitor data input function, a procedure in which data of an analysis result by the database construction function is recorded in an analysis result database, and an analysis result database. The procedure in which data is input to the database collation function and collated with past data recorded in the abnormal phenomenon database.If the input failure information monitor data is the same as the past failure information data, The data is input to the analysis function from the analysis result database and the visual If the displayed procedure and the input failure information monitor data are different from the past failure information data, the test scenario automatic generation function automatically generates a scenario for the reproduction test, and summarizes the countermeasures after analysis. The procedure for recording in the analysis result database and the created test scenario are transmitted to the pseudo terminal function.
Executing a continuous test in combination with the information from the test scenario database and visually displaying the test results on an analysis function.

Further, the present invention can provide a program for realizing the information sharing method in the above invention. The program referred to here is information stored in a recording medium, read by a computer system, and transmitted to another computer system by a transmission medium or a transmission wave in the transmission medium. A transmission medium for transmitting a program is a medium having a function of transmitting information, such as a network such as the Internet or a communication line such as a telephone line.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The embodiments of the information sharing system according to the present invention will be described below with reference to the drawings. In the following embodiment, failure information is stored in a database (hereinafter, abbreviated as DB).
A "database construction function of a high-performance protocol tester" for realizing an information sharing system capable of performing an early response based on the accumulated information of the database will be described.

As an outline of the "database construction function of the advanced protocol tester", first, protocol data of an abnormal phenomenon that has occurred in the field is input to the database construction function. The protocol data is ISDN (Integrat
ed Services Digital Network) and IP (Internet Prot)
ocol). Then, whether or not the same phenomenon has occurred in the past is checked by the DB checking function. At this time, a series of flows of the protocol in which the phenomenon occurred is used as a DB search key. Here, when a similar phenomenon exists in the DB in the search result, a measure is taken according to a predetermined measure. On the other hand, if a similar phenomenon does not exist, a scenario for a reproduction test is created and analyzed, and new coping methods are collectively registered in the DB and accumulated as new know-how. In this way, the search key of the protocol in which the phenomenon occurred, the procedure of the reproduction test scenario, and the procedure of the coping method are stored as one item in the DB, so that coping with the reoccurrence of the phenomenon is promptly performed. be able to.

First, an outline of a system for realizing the "database construction function of the advanced protocol tester" will be described. The system that realizes the "database construction function of the advanced protocol tester" receives monitor data from a protocol analyzer, etc., and converts the analysis results into a DB to compare with past failure data and analyze failure locations. Functions for easily realizing
This is an integrated debug system that has a function of performing a degrade test at the time of network system development using a test scenario and a pseudo terminal function, and can quickly remove a failure or the like. Hereinafter, the information sharing system of the present invention that implements the "database construction function of a high-performance protocol tester" is simply referred to as a "high-performance protocol tester."

FIG. 1 is a configuration diagram of an advanced protocol tester according to an embodiment of the present invention. This advanced protocol tester is composed of various functions and various databases. That is, the high-performance protocol tester of the present invention includes a monitor data input function 1, a DB construction function 2, an analysis result DB3, a DB collation function 4, an analysis function 5, an abnormal phenomenon DB 6, a test scenario DB 7, a test scenario automatic generation function 8, A pseudo terminal function 9 is provided.

The monitor data input function 1 is a function for inputting monitor data of an analyzer such as an IPA using a flexible disk (hereinafter abbreviated as FD). DB
The construction function 2 converts the monitor data input by the monitor data input function 1 into the time, the partner terminal, and the normal / incoming / outgoing call.
It has a function to analyze and display a list based on items such as abnormalities. The analysis result DB 3 records all data input by the monitor data input function 1. The DB collation function 4 has a function of collating whether or not the current data matches a past abnormal phenomenon using a sequence pattern, a line transmission capability, a line disconnection reason, or the like as a search key.

The analysis function 5 has a function of visually displaying a call state sequence included in data so that an abnormal part can be easily determined. Abnormal phenomenon DB
Numeral 6 stores past abnormal phenomenon data, which is extracted by the DB collation function 4 and searched / retrieved with the current data.
It has a function to perform collation. Test scenario DB7 is
Test scenarios for reproduction tests and basic function confirmation tests are recorded. The test scenario automatic generation function 8 has a function of automatically generating a test scenario for a reproduction test from monitor data. The pseudo terminal function 9 has a function of performing a reproduction test or a degress test by performing a continuous test by combining various test scenarios constructed in each DB.

In the system configuration diagram shown in FIG. 1, a one-way arrow indicates a data input direction, and a two-way arrow indicates a state where data is referred to each other. That is, when the monitor data of the failure is input from the monitor data input function 1 to the DB construction function 2, the data of the analysis result by the DB construction function 2 is recorded in the analysis result DB3. Further, data is input from the analysis result DB 3 to the DB collating function 4, collated with past data recorded in the abnormal phenomenon DB 6, and if a similar phenomenon exists, it is dealt with according to a predetermined measure. Further, data is input to the analysis function 5 from the analysis result DB 3 and is visually displayed. On the other hand, if the same phenomenon does not exist, the test scenario automatic generation function 8 automatically generates a scenario for the reproduction test, collects the countermeasure methods after the analysis, records it in the analysis result DB 3, and accumulates it as know-how. This test scenario is transmitted to the pseudo terminal function 9. Thereby, the pseudo terminal function 9 executes a continuous test or the like in combination with the information from the test scenario DB 7, and causes the analysis function 5 to visually display the test result.

Next, each function and each DB in the advanced debug system of FIG. 1 will be described in detail. First,
The monitor data input function 1 will be described. FIG. 2 is a main screen displayed by the monitor data input function. That is, as shown in FIG. 2, a "database construction function of a high-performance protocol tester" menu screen is displayed as a main screen of the high-performance debug system, and when an "input monitor data" button on the main screen is pressed, the figure shown in FIG. A standard file selection dialog for selecting monitor data to be input to the DB construction function 2 shown in FIG. Here, monitor data of a protocol analyzer such as IPA or ISDN PROTOCOL ANALYZER is input to the DB construction function 2 by a recording medium such as a flexible disk (FD).

Next, the DB construction function 2 of FIG. 1 will be described. FIG. 3 is a screen of an analysis result by the DB construction function. That is, the data input by pressing the “input monitor data” button from the menu screen of FIG. 2 is analyzed by the DB construction function 2 and displayed in a list as shown in FIG. At this time, the following information is displayed on the analysis result screen. That is, the header portion is a portion for displaying the common information of the input monitor data, the line number of the terminal itself (monitored line) is displayed in the "line number", and the line is monitored in the "monitor period". The period is displayed.

Next, the list display section is a section for decomposing input data for each call and displaying a list of information for each call. It is also possible to select (highlight) one or more calls with the mouse. That is, the serial number of the call is displayed in “No.”, and the start date and time of the call is displayed in “Month / Date and Time”. The "party terminal" displays the line number of the partner terminal, and the "outgoing / incoming" displays the call direction (calling / destination). "Normal / abnormal" indicates the state of the call (normal / abnormal call), and "abnormal cause" indicates the cause of the abnormality if the call state is abnormal.

In the DB analysis function 2, "normal / abnormal"
With regard to the determination method and the “cause of abnormality”, the following are determined to be abnormal calls. First, "incomplete call"
"Response" after detecting the layer 3 message "call setup"
It is assumed that “disconnect”, “release”, and “release complete” are detected earlier than before. Next, “abnormal reason display” is a completed call, but it is assumed that “disconnection”, “release”, and “release complete” having a reason display other than normal disconnection are detected. In addition, the reason display of the disconnection message of "incomplete call" and "error reason display" is displayed in the item of the cause of the error in the list display section.

Next, the statistical data section is a section for displaying the statistical data of all the calls in the input data for each terminal. That is, the serial number of the terminal is displayed in “No.”,
In the “partner terminal”, the number of the partner terminal is displayed. The “number of outgoing calls” indicates the number of outgoing calls to the corresponding terminal, and the “outgoing abnormalities” indicates the number of outgoing calls having an abnormal call state. The “number of incoming calls” displays the number of incoming calls to the corresponding partner terminal, and the “abnormal incoming calls” displays the number of calls with abnormal call status among the number of incoming calls.

Further, the analysis result screen shown in FIG. 3 has the following function buttons. That is, the [data collation] button is used to select one or more calls with the mouse from the data displayed on the list display section, and then press this button to display a DB with the abnormal phenomenon DB for the selected call.
A collation function is implemented. Subsequent operations will be described in the DB collation function described later. When the [Analysis] button is used to select one call from the data displayed on the list display unit with the mouse and then press this button, an analysis function for the selected call is performed. Subsequent operations will be described later in the analysis function. The [Close] button closes the analysis result screen. At this time, D
Data not registered in B is discarded.

The user performs the following operation on the analysis result screen shown in FIG. First, it is checked whether or not the current phenomenon has been registered as an abnormal phenomenon in the past. At this time, the call information (one or more calls) to be collated is selected from the list display screen with the mouse. Then, by pressing the [Data collation] button on the screen in the selected state, the function of DB collation with the abnormal phenomenon DB 6 in FIG. 1 is performed. Subsequent operations will be described later with a DB collation function. Next, in order to determine the abnormal part of the current phenomenon, the call state and the sequence are visually displayed using the analysis function 5 of FIG. At this time, call information (one or more calls) to be collated is selected from the list display on the analysis result screen of FIG. 3 with the mouse. By pressing the [Analyze] button on the screen in the selected state,
Analysis function 5 is performed. Subsequent operations will be described in the analysis function described later.

Next, the analysis result DB 3 of FIG. 1 will be described. Data registered by the DB construction function 2 is registered in the analysis result DB3. The data registered in the analysis result DB 3 can be browsed by pressing the [Browse Analysis Result Database] button from the menu screen of FIG. FIG. 4 is an item table registered in the analysis result DB. That is, the following items are recorded in the analysis result DB for each registered data.

1) The “analysis DB identification number” is the analysis result D
The identification number of the data of B, which is automatically given at the time of registration. The rule of the identification number will be described later. 2) “Consecutive designation” is a value for identifying the number of the number of mouth calls and is automatically given at the time of registration. The rule of continuous designation will be described later. 3) “Name” is the name of the data, and can be freely set by the user at the time of registration. 4) The "own terminal number" is the telephone number of the own terminal (monitored line). 5) "Other party terminal number" is the telephone number of the other party terminal. 6) “Destination type” indicates the call direction (outgoing / incoming). 7) "Call status" indicates the call status (normal / abnormal). The method of determining the call status (normal / abnormal) has been described in the DB construction function 2 described above.

8) "Start time" is a call start time (call setting transmission / reception time). 9) “Call setting (transmission capability)” is the transmission capability of the layer 3 message “call setting”. 10) "Call setup (lower layer)" is the lower layer consistency of the layer 3 message call setup. 11) "call setup (higher layer)" is the higher layer consistency of the layer 3 message call setup. 12) “Reason display” is a layer 3 message “Disconnect”
This is a reason display of “release” and “release complete”. 13) The “sequence pattern” is a sequence pattern that is automatically assigned at the time of registration from a pattern registered in advance. The details of the sequence pattern will be described later. 14) "Call data" is sequence data cut out in units of one call. 15) "All monitor data" is monitor data including all calls.

First, an identification number is automatically assigned when the analysis result DB 3 is registered. This identification number is a number for identifying the call data registered in the analysis result DB3. The format of the identification number is expressed as follows. Analysis result DB identification number XX-XXX-XXX-XXXX-XXXXXX Each item and function are as follows. Header: Analysis result DB header (01) Call direction: Calling side 0 / Destination side 1 Disconnecting direction: Disconnecting from terminal 0 / Disconnecting from network 1 Reason display: Disconnection reason display value Sequence pattern: Call sequence pattern Serial number : Serial number Here, by incorporating information such as “call direction” and “disconnection direction” into the identification number, a search at the time of DB collation described later can be efficiently performed. The details of the DB collation will be described later with reference to a DB collation function.

Next, the continuous designation automatically given when the analysis result DB 3 is registered will be described. Analysis result DB3
, One data is created for one call. In the case where an abnormal phenomenon occurs due to continuous execution of multiple calls, the above identification number is the same, and it is one data by setting the number of the caller in the number of callouts in the item designated consecutively Recognize The designation of the continuous designation is automatically performed at the time of registration. The format of the continuous specification is shown as follows. The items and functions are as follows. Call sequence number: The corresponding data specifies the number of a continuous call group. Total number of calls: Indicates the total number of consecutive call groups.

Next, a sequence pattern will be described. The sequence pattern is obtained by patterning and classifying various call sequences and assigning identification numbers. For example, a sequence when “call setup” and “release complete” are performed between the own terminal and the network is defined as a sequence pattern “001-001” regardless of the content of the information element. Similarly, by registering a sequence pattern that can occur in advance, it is possible to efficiently perform a search by the DB collation function described later. When data of a new sequence pattern that has not been registered occurs, it is additionally registered as a new sequence pattern.

Next, the DB collating function 4 shown in FIG. 1 will be described. When one or more calls are selected on the screen (FIG. 3) of the analysis result by the DB construction function 2 and the [Data collation] button is pressed, the data collation by the DB collation function 4 is similar to the past abnormal phenomenon DB 6. Automatically collates if it contains any item. Abnormal phenomenon D as a result of DB collation
When a similar item is detected in B6, a screen of the collation result shown in FIG. 5 is displayed. That is, FIG. 5 is a screen of the collation result when similar data is detected. Also,
As a result of the DB collation, when it is determined that there is no similar item in the abnormal phenomenon DB 6 and the data is new data, a collation result screen shown in FIG. 6 is displayed. That is, FIG. 6 shows a screen of the comparison result in a case where similar data is not detected and is new data.

The following information is displayed on the comparison result screens shown in FIGS. First, the basic information section is a part for displaying basic information of data, and the “abnormal phenomenon DB identification number” is an identification number in the abnormal phenomenon DB 6 and is automatically given at the time of registration. In addition, regarding the law of the identification number,
This is the same as the rule of the identification number described in the analysis result DB described above. However, the header part of the identification number is “abnormal phenomenon DB header (02)”. “Continuous designation” is a value for identifying the number of the call of which caller, and is automatically given at the time of registration. For the rule of continuous designation, see the analysis result D described above.
This is the same as the rule of continuous designation described in B. In addition, "month / date / time" indicates the start date and time of the call, and "own terminal" indicates the line number of the own terminal (monitored line). For "other party terminal", the line number of the other party terminal is displayed, for "outgoing / incoming", the call direction (originating / receiving side) is displayed, and for "normal / abnormal", the call status (normal call / abnormal call). Is displayed.

Next, the collation location part displays an item collated by the DB collation function with the data of the abnormal phenomenon DB.
The “transmission capability” is the transmission capability of the layer 3 message “call setting”, and the “lower layer” is the lower layer consistency of the layer 3 message “call setting”. "Higher layer" is the higher layer consistency of the layer 3 message "call setup",
“Reason for disconnection” is a reason display for the layer 3 messages “disconnect”, “release”, and “release complete”, and “sequence pattern” is a sequence pattern automatically given from a pre-registered pattern at the time of registration. Note that the sequence pattern is the same as the sequence pattern described in the analysis result DB described above.

Next, the test scenario section is a section for displaying the information of the corresponding test scenario DB, and the "test group" is a test group in the test scenario DB. The group created by the user can be registered in. The “reproduction test scenario name” is a file name of a test scenario for a reproduction test at the time of an abnormal phenomenon. In the case of new registration, a corresponding test scenario can be easily created by a test scenario automatic generation function or the like.

The screen of the comparison result in FIGS. 5 and 6 has the following function buttons. That is, the [Analysis] button performs an analysis function on the target data. The subsequent operation will be described in detail in the analysis function 5 described later. [Scenario generation] button performs the test scenario automatic generation function on the target new data. The subsequent operation will be described in detail in the test scenario automatic generation function 8. [Corrective action] button displays [Corrective action] when similar data is detected in the abnormal phenomenon DB in the target data. In this case, it can be linked to a word processing document or the like. [Register] button registers the target new data in the abnormal phenomenon DB. The [Delete] button deletes the target data. If similar data is detected on the abnormal phenomenon DB as a result of matching the target data,
A confirmation screen for selecting which of the old and new data to delete is displayed.

Further, the check result screen has the following check boxes. That is, the check box name is "□ Automatically delete new data if similar data is detected in the future." Patterns with high frequency such as normal calls are detected by matching each time. In order to save time, it is added as a function for automatically deleting new data.

Next, a method of operating the comparison result screen shown in FIGS. 5 and 6 will be described. First, as a result of DB collation, if a similar item is detected in the abnormal phenomenon DB 6, detailed information is confirmed using an analysis function. In addition, this abnormal phenomenon is dealt with by referring to a method of dealing with similar detected data. Further, an analysis function is performed by pressing an [analysis] button. Subsequent operations will be described in “analysis function 5”. Also, as a result of the analysis, when it is clear that the data is the same, the [Delete] button is pressed to delete either the new or old data. Furthermore, the user presses the [Response] button to view the remedies for this phenomenon, and actually implement the remedies.

Next, as a result of the DB comparison, if it is determined that there is no similar item in the abnormal phenomenon DB and the data is new data, a test scenario for a reproduction test is created, and then the abnormal phenomenon DB is created.
Register the data in 6. In this case, the cause of the abnormality is determined by the analysis function 5, the pseudo terminal function 9, and the like, and the coping method is written in the abnormal phenomenon DB 6. At this time, a [Create Scenario] button is pressed to create a test scenario for a reproduction test.
The subsequent operation will be described in “Test scenario automatic generation function 8”. Further, the user clicks the [Registration] button to display the abnormal phenomenon DB6.
Register data in. Then, the cause of the abnormal phenomenon is determined using the analysis function 5 and the pseudo terminal function 9. Subsequent operations will be described in “analysis function 5” and “pseudo terminal function 9”. Further, the user presses a [method] button to register the countermeasure in the abnormal phenomenon DB. The format of the coping method is not specified. That is, the function of only providing an area for storing data of commercially available word processing software in the DB is provided.

Next, the analysis function 5 shown in FIG. 1 will be described. The analysis function 5 is a function for visually indicating a call state, a sequence, and the like, so that an abnormal part can be easily determined. First, FIG.
The analysis function is activated by pressing the [activation of analysis function] button on the menu screen of the main screen of FIG. 3 or the [analysis] button of the analysis result screen of FIG. 3 or the comparison result screen of FIGS. 5 and 6. To display the initial screen.

Next, a file is designated from the initial screen of the analysis function. That is, by selecting “File” → “Open” from the menu of the initial screen, the file specification screen is displayed, and the monitor data of the protocol analyzer to be analyzed is specified. Note that when the file is started from the [Analysis] button on the analysis result screen of FIG. 3 and the comparison result screen of FIGS. 5 and 6, the file is automatically started with the file specified.

Next, the display function will be described. In the sequence display, when a file input is designated, a protocol sequence is displayed on a screen. In the call state display, when "display"->"display call state" is designated by the menu, the call state of the protocol sequence is displayed. Log information display
By specifying “Display” → “Display log information” on the menu, the log information of the corresponding message is displayed. In the signal detail display, by specifying “display” → “display detailed information” from the menu, detailed information of the selected signal is displayed. For highlighting, by selecting “display” → “emphasis” from the menu, a highlight designation screen is displayed for a specific item in the sequence display. Here, a desired item is checked from the highlighting menu and highlighted.

Next, a description will be given of a file addition designation. If there is a vacancy in the currently displayed line, a new sequence can be read for that line and the combined sequence can be displayed. To create a synthesized sequence, select "File" → "Add". Here, a combined sequence of up to four lines can be displayed.

Next, the filtering function will be described. By specifying "Filtering" from the menu, specific message information is extracted and displayed from the items displayed in sequence. That is, the following eight items are displayed. (1) Message type When filtering by message type, it is possible to specify all message types, individual message type classification (call setting / communication / disconnection / other), and arbitrary hexadecimal code input specification as the message type specification method. is there. (2) Call number When filtering by a call number, a call number and a generation category (terminal generation / network generation / both-side generation) are specified. (3) Calling number When filtering by calling number, specify the calling number. At the time of number designation, fixed number designation and use of a wild card are possible. (4) Source sub address When filtering by source sub address, A
Specify FI and sub-address information. (5) Called number When filtering by called number, specify the called number. Note that when specifying a number, it is possible to specify a fixed number and use a wild card. (6) Destination subaddress When filtering by destination subaddress, A
Specify FI and sub-address information. (7) Reason display When filtering by reason display, specify the value of the reason display. At this time, an arbitrary value can be input. (8) Diagnosis reason When filtering by diagnosis reason, specify the reason type and value.

As for the printing function, when printing the contents of the screen, select "File"->"Print" from the menu. As a result, all information on the call state, the sequence display, and the log information is output as a screen image. To end this processing, select “File” → “End” from the menu, and the screen is erased after the selection.

Next, the abnormal phenomenon DB 6 shown in FIG. 1 will be described. In the abnormal phenomenon DB 6, data registered by the collation function is registered. The data registered in the abnormal phenomenon DB 6 can be browsed by pressing an “abnormal phenomenon database reference” button from the menu screen in the main screen of FIG. Note that the abnormal phenomenon DB 6 records items as shown in FIG. 7 for each piece of registration data. FIG. 7 shows the registered contents of the abnormal phenomenon DB. That is, a) “abnormal phenomenon DB identification number” is an identification number of data of the abnormal phenomenon DB, and is automatically given at the time of registration.
Note that the rule of the identification number is described in the analysis result DB3 described above.
As described above. However, the header part of the identification number is “abnormal phenomenon DB header (02)”. b) "Consecutive designation" is a value for identifying the number of the call of which caller, and is automatically given at the time of registration. The rule of the continuous designation is as described in the continuous designation of the analysis result DB3. c) “Name” is the name of the data and can be freely set by the user at the time of registration. d) The “own terminal number” is the telephone number of the own terminal (monitored line). e) "Other party terminal number" is the telephone number of the other party terminal. f) “Departure / arrival type” is the call direction (outgoing / incoming). g) “Call status” is the status of the call (normal / abnormal).
The method for determining the call state (normal / abnormal) is as described in the description of the screen of the DB construction function 2 described above.

H) "Start time" is a call start time (call setting transmission / reception time). i) “Call setting (transmission capability)” is the transmission capability of the layer 3 message “call setting”. j) "call setup (lower layer)" is the lower layer consistency of the layer 3 message call setup. k) "call setup (higher layer)" is the higher layer consistency of the layer 3 message call setup. l) "Reason display" is a layer 3 message "Disconnect",
It is a reason display of "release" and "release complete". m) The “sequence pattern” is a sequence pattern automatically given from a pre-registered pattern at the time of registration. The sequence pattern is as described in the above-mentioned sequence pattern of the analysis result DB3. n) "Call data" is sequence data cut out in units of one call. o) "All monitor data" is monitor data including all calls. p) “Test group” is a test group in the test scenario DB. q) “Reproduction test scenario” is a file name of a test scenario for a reproduction test at the time of an abnormal phenomenon. r) The "response method file" is a file in which a response method for an abnormal phenomenon is described, and provides an area for storing data of commercially available word processing software. s) The “automatic deletion check box flag” is a function for automatically omitting new data in order to save the trouble of matching each time for a frequently-used pattern such as a normal call. Box] status. The data recorded in the items d) to o) are inherited from the analysis result DB3. A) ~
Abnormal phenomenon DB6 only for items c) and p) to s)
It is created anew when it is registered in.

Next, the registered contents of the test scenario DB 7 will be described. The test scenario DB 7 has an abnormal phenomenon DB
6 and a test scenario group for confirming basic functions at the time of developing a node system are registered. The data registered in the test scenario DB 7 can be browsed by pressing a “browse test scenario database” button from the menu screen. Further, the following items are recorded in the test scenario DB 7 for each registered data. In the case of cooperation with the abnormal phenomenon DB 6, a "test setting file" is automatically created based on the "reproduction test scenario" file and the "continuous designation" value. The “test group” is a test group in the test scenario DB 7 and is classified for each basic function confirmation and abnormal phenomenon. The "test setting file" is a test item setting file for a continuous test of the pseudo terminal function, in which file names and order of test scenarios to be combined are recorded. The “test scenario” is a file name of the test scenario, and a plurality of registrations corresponding to the names registered in the test setting file are possible. “Test result” records a log of a test result performed using the pseudo terminal function.

Next, the classification of the test groups will be described. The test groups already registered in the test scenario DB 7 from the beginning are as follows. "Layer 3 conformance" confirms the basic operation of the exchange by transmitting a layer 3 message in each call state. “1 Call Through” confirms the normality of a series of call flows from call setup to release completion. “Additional service” confirms that various additional services start normally. “Layer 2 conformance” confirms the basic operation of the exchange by transmitting a layer 2 message in each state. Note that the user can freely register test scenarios that fall into the categories other than the above as test groups.

Next, the test scenario automatic generation function 8 in FIG. 1 will be described. Test scenario automatic generation function 8
Is a function for automatically generating a test scenario for a reproduction test from monitor data. First, when starting up,
Open the main screen of the test scenario, and press the [Start Test Scenario Automatic Generation Function] button on the menu screen, or press the [Generate Scenario] button on the comparison result screen shown in FIGS. The generation function 8 is activated and an initial screen is displayed. Next, regarding the automatic generation of a test scenario, first, monitor data is input. In other words, by selecting “File” → “Scenario generation” from the menu of the initial screen, the scenario specification file specification screen is displayed, and the monitor data of the protocol analyzer to be analyzed is specified. When the file is started from the [Scenario generation] button on the collation result screen, the file is automatically started with the file specified.

Next, with regard to generation of a test scenario, when a file input is designated, a test scenario is automatically generated. Then, a test scenario file is opened from the generated test scenario. At this time, by selecting “File” → “Open File” from the menu, a test scenario file designation screen is displayed, and a test scenario file (extension PRD) is designated. If an error occurs during the automatic generation of the test scenario, information is added to the part where the error has occurred.

As for the setting of the reception level, when "option" → "various settings" is selected, the setting of the reception level and the setting of the embedding of the timing command can be performed.
In the “reception level setting”, the level of the reception collation function can be set. Therefore, by setting the reception level on this screen, the user can change the verification level of the received message in the automatically generated test scenario. The relationship between the reception level and the collation of the received message is as follows. Reception level 1: Not collated (default). Reception level 2: Check the message type. Reception level 3: Checks all information other than TEI and call number. As for the setting of the timing command, selecting “option” → “various settings” enables setting of the reception level and setting of embedding of the timing command.
Here, in the “timing condition”, it is possible to select whether to embed a timing command in a scenario.

Next, the edit display and editing of the test scenario file will be described. Regarding the display of files, the test scenario automatic generation function 8 can display and edit a plurality of test scenario files. Also,
Regarding file editing, the displayed window can be freely edited. Here, the functions of “edit” → “copy”, “cut”, and “paste” can be used. To save a file, go to “File” →
When "Save file" is selected, the edited test scenario file can be saved. When printing a file, selecting “File” → “Print” allows the contents of the currently selected window to be output to the printer. "File" for scenario synthesis
→ If you select "Synthesis", one scenario can be created from multiple files. Here, it is possible to create a combined sequence for up to four lines. Further, since the transmission timing can be adjusted in milliseconds at the time of synthesis, fine adjustment can be performed. To end the process, select “File” → “Exit” from the menu.
If you select, the screen will be erased after the selection.

Next, the pseudo terminal function 9 in FIG. 1 will be described. Advanced protocol tester (simulated terminal function)
Is ISDN (Integrated Services Digital Network)
k) At the user / network interface, a pseudo call is generated by combining various test scenarios constructed in the test scenario DB 7, and an overload test by a protocol test and a simultaneous test from a plurality of lines, or a reproduction test at the time of failure occurrence, etc. Is a control program for performing the following. The functional outline of the advanced protocol tester (pseudo terminal function) is shown below.

(1) Edit function of continuous test group An actual line number is assigned to a terminal number in a test scenario, a plurality of test scenarios, "initialization", "timer",
This is a function that combines functions such as "repeat" and saves them as a group for continuous testing. (2) Test (pseudo call generation) function
This function generates a pseudo call on the SDN line. The advanced protocol tester can simulate up to four terminals in one test, and can execute three tests in parallel at the same time. (3) Test history storage function This is a function to record the history of test results in the above-described continuous test on a screen and in a database. When an expected message specified in the test scenario is not received during the test, or when a message different from the content of the specified information element is received, an error log is stored in the test result.

Next, the activation of the pseudo terminal function 9 will be described. In the main screen shown in FIG. 2, by pressing a “pseudo terminal function start” button on the menu screen,
The pseudo terminal function is activated, and a menu screen of the advanced protocol tester as shown in FIG. 8 is displayed. The advanced protocol tester can perform a test using up to four lines in one test per ISDN board. Since three ISDN boards are mounted on the high-performance protocol tester, it is necessary to first select which test machine (board) is to be used for the test. Therefore, a tester (board) is selected by selecting an empty board from the menu screen. The following information is displayed in the board list on the menu screen of the high-performance protocol tester shown in FIG. That is, the boards 1 to 3 are displayed in the “board” column, and the current usage status of the corresponding board is displayed as “used / empty” in the “usage status” column.

The procedure for selecting a tester (board) is as follows. From the board list, check that the usage status of the tester (board) you want to use is [empty]. Note that “in use” is displayed when the test is already being used in another test. The tester (boards 1 to 3) to be used is selected in the board selection field. When the [Test Setting] button is pressed, a test list screen of the tester (board) specified in the board selection field is displayed.
When the [Setting] button is pressed on the menu screen of FIG. 2, the test list screen of the test machine (board) specified in the board selection field is displayed. FIG. 9 is an example of a test list screen in the pseudo terminal function.

At this time, the following information is displayed in the test list on the test list screen. That is, the display of “test” indicates a test registered by [new test].
The “status” display shows the current status of the corresponding test (ie, in use / finished / item setting / history display / standby). The test list screen has the following buttons. [Line Settings] button: Makes settings such as line numbers. [New test] button: Register a new test. [Open test] button: Opens an already registered test. [Setting] button: Sets the test items. [Start] button: Starts the test. [History display] button: Displays the test results. [Delete] button: Deletes the registered test. [Exit] button: Exits the test list screen.

Next, setting of a line will be described. First, when the [line setting] button is selected on the test list screen in FIG. 9, a line setting screen in the high-performance protocol tester as shown in FIG. 10 is displayed. The following information is displayed in the line setting list on the line setting screen. In the “line”, a line or the like mounted on the ISDN board currently selected by the advanced protocol tester is displayed. FIG. 11 shows the types of lines that can be set. The "usage status" displays the current status of the corresponding line. For example, xxx indicates “used / empty”. Here, xxx is the test name. "Telephone number" displays the telephone number of the corresponding line.

The line types in the advanced protocol tester shown in FIG. 11 are “line 1”, “line 2”,
“Line 3” and “Line 4” respectively correspond to lines 1, 2, 3, and 4 of the selected board (# 1, # 2,
# 3, # 4). The “external terminal 1”, “external terminal 2”, “external terminal 3”, and “external terminal 4” are external terminals 1, 2, 3, and 4 (以外 in the test scenario), respectively, other than the advanced protocol tester. D, ＠E, ＠
F, $ G), and can be specified only for the called number. Furthermore, “Destination number 1”, “Destination number 2”,
“Destination number 3” and “Destination number 4” respectively correspond to terminals 1, 2, 3, 4 (S
TA :, STB :, STC :, STD :) are numbers 1, 2, 3, and 4 for fixedly replacing the called numbers.

The line setting screen shown in FIG. 10 has the following buttons and input fields. [Telephone number] displays the telephone number currently set for the line selected from the list. The input of the telephone number is also performed from this input field. [Setting] validates the telephone number entered in the telephone number input field. The activated telephone numbers are displayed in a list. [Insert called number] is not specified by @,
If the test scenario included a phone number directly,
This function assigns the telephone numbers described in the scenario to the called numbers 1 to 4, and is enabled by checking the check box. [OK] enables the items set on the line setting screen and closes the screen. [Cancel] invalidates the items set on the line setting screen and closes the screen. [Update] updates the line setting status to the latest status.

Next, the procedure for setting the line will be described.
That is, a telephone number is set to a line in the following procedure. Check that the usage status of the line you want to set from the line list is [Free]. Note that, when already being used in another test, [used in xxx] (xxx is the test name) is displayed. Also, it is not possible to change the setting of the [in use] line. Select the line to set the telephone number in the line selection field. The telephone number corresponding to the selected line is displayed in the telephone number input field. By rewriting the telephone number input field, a new telephone number corresponding to the line can be input. After entering the phone number, press the [Settings] button to enable the settings. The activated phone numbers will be listed. After setting the telephone numbers of all the lines, press the [OK] button to validate the items set on the line setting screen and close the screen.

Next, the new test will be described. When the [New Test] button is selected on the test list screen in FIG. 9, a screen for inputting a test name is displayed. Here, when the test name is input and the [Save] button is pressed, a new test item setting screen corresponding to the test name is displayed. Next, when opening a test, selecting the [Open test] button on the test list screen displays a dialog for selecting a test setting file (* BPR). Here, when the test setting file is selected and the [Open] button is pressed, the selected test is displayed in the test list.

Next, setting of test items will be described.
FIG. 12 shows a line type test item setting screen in the advanced protocol tester. When a test is selected from the list on the test list screen and the [SET] button is pressed, a test item setting screen for the selected test is displayed as shown in FIG. At this time, the following information is displayed on the test item setting screen of FIG. [Test item list] displays test items added from [Select test file] or [Select insert function]. The items registered here are written in the test setting file. [Select Test File] displays a list of test files (PRD) in the specified directory. A test file can be additionally inserted into the [test item list] by dragging and dropping with the mouse or selecting and then pressing the [add] button. [Confirmation of test file] is the test file (PR) selected with the mouse in [Test item list] and [Select test file].
Display the contents of D). [Insert function selection] registers [Initialize], [Timer], and [Repeat] functions that are frequently used during the test. Insert function with mouse drag &
By dropping or pressing each button, it can be additionally inserted in [test item list]. [Used line]
Indicates telephone numbers for the terminals 1 to 4 and the external terminals 1 to 4. The phone number must be registered on the line setting screen in advance.

The test item setting screen shown in FIG. 12 has the following buttons. [↑] [↓] moves the test file or insertion function selection of the selected test item list up or down. [Delete] deletes the selected test file or insertion function selection from the test item list. [Browse] displays a list view for selecting a directory where the test file is stored. The directory selected here is displayed in the directory column on the left. [add to]
Inserts the selected test file into the test item list. Note that additional insertion by dragging and dropping with a mouse is also possible. [Initialize] has a function of initializing the ISDN board. Therefore, when the button is pressed, it is additionally inserted into the test item list. In addition, drag &
Additional insertion by drop is also possible. [Timer] is a timer function for providing a waiting time between tests. Press the button to insert it into the test item list. Note that additional insertion by dragging and dropping with a mouse is also possible.
[Repeat] is a function for returning the processing to the top of the test item list. Therefore, when the button is pressed, it is additionally inserted into the test item list. Note that additional insertion by dragging and dropping with a mouse is also possible. [Setting] enables the items set on the test item setting screen and closes the screen. [Cancel] invalidates the items set on the test item setting screen and closes the screen.

Further, the [Setting] menu on the test item setting screen in FIG. 12 has the following items. [Timer value setting] sets various timer values used in the system.
[Test option]-[Request ID for each test]
If checked, TEI assignment is performed for each test. If there is no check, the TEI is assigned only once when the first test registered in the test item setting is performed. still,
Default is unchecked. [Test option]
-[Save normal history] saves the history of successfully completed tests when checked. If there is no check, save only the history of the test that ended abnormally. The default is unchecked. [Close] invalidates the items set on the test item setting screen and closes the screen.

When "Timer value setting" is selected in the "Setting" menu, the following items are displayed on the timer setting screen. [Network clear timer] sets a standby time until the next test scenario is executed when a test is abnormal.
[MSG reception timer] sets a timeout period for receiving a message from the network. [Inter-scenario timer]
Automatically insert wait time between test scenarios.

Next, the procedure for setting the test items will be described. The procedure for setting the test items is as follows. It is confirmed that the telephone numbers registered on the line setting screen are displayed on the terminals 1 to 4 and the external devices 1 to 4 of [Selection of used line]. Click the [Browse] button in [Select test file] to move to the directory where the test file is saved,
A list of subordinate test files (PRD) is displayed. When a test file in the list is selected with a mouse, the contents of the test file (PRD) are displayed in the display field of [Confirmation of test file]. In the “insertion function selection”, [initialization], [timer], and [repetition] functions that are frequently used during the test are registered. The test file and insertion function can be additionally inserted into the [test item list] by dragging and dropping or selecting with the mouse and pressing the [Add] button. The test registered in the test item list is the test setting file (BP
R). After setting the necessary test items, press the [Setting] button to enable the set items and close the test item setting screen.

Next, the procedure for starting the test will be described. Check that the status of all tests is [Standby] on the test list screen. If another test has already been performed, the status of the relevant test is displayed as "running". At this time, if you select a test in standby and press the [Start] button, an error is displayed. On the test list screen, select the test you want to execute from the list and press the [Start] button to display the test start confirmation screen. Here, when the [OK] button is pressed, a screen of a test history corresponding to the test is displayed. In addition, the status of the corresponding test in the test item list is displayed as [in progress].
Thereafter, the test results are confirmed in accordance with the description of the history display described below.

Next, the history display will be described. When a test is selected from the list on the test list screen of FIG. 9 and the [Start] or [History display] button is pressed, a screen of a test history corresponding to the selected test is displayed. At this time, the following information is displayed on the test history screen for both the monitor screen and the viewer screen. The drawing of the screen of the test history is omitted. The [Monitor] tab switches to the screen of the test history (monitor). The [Viewer] tab switches to the screen of the test history (viewer). When the [History Display] button is pressed to display the test history screen, only the [Viewer] tab is displayed at the upper left of the test history screen and cannot be switched to [Monitor].

[Test item list] displays a list of test files (PRD) and insertion functions set in the test item setting. If the test is [in progress], the item currently being tested is highlighted. [Test result] is [List of test items]
Is displayed for each test file. The four-digit number on the right side of the test file name is a counter indicating the week of this test.
For example: (Test result file) (Result) (Meaning) TEST01_0001 OK 1st week test TEST01 completed normally TEST02_0001 NG 1st week test TEST02 abnormally finished TEST03_0001 OK 1st week test TEST03 completed normally Test shown in this column The result file (TRD format) is stored in a folder created for each test. The test result file can be set to “Save all test histories” or “Save only in case of abnormal termination” depending on the value set in the [Test Option] menu on the test item setting screen. .

The test history screen has the following menus common to the monitor screen and the viewer screen.
[External Viewer] sets an external program for analyzing the test result file. When the menu is selected, the external viewer setting screen is displayed. Double-click the test result file name displayed in [Test Result] on the test history screen (viewer) to start the set program. [Close] closes the test history screen. When the test is [Running], the test history screen cannot be closed. The test must be terminated with the [Exit] button.

Next, the screen of the test history (monitor) (not shown) will be described. When the [Monitor] tab is selected on the test history screen where the test is [Running], the test history (monitor) screen is displayed. The following items are displayed on the screen of the test history (monitor). [Monitor display area]
Displays the test result (TRD) of the test currently being executed in real time. The monitor can select the display of [Details] and [Simple] by the button of [Display mode]. [Layer mode display] displays the layer mode of the test currently being executed.

The test history screen (monitor) has the following buttons. [Pause] suspends the test when the test of the test file currently being executed ends. The paused test can be restarted from the next test file by pressing the [Resume] button. [Resume]
Resumes the test that was paused by the Pause button. Resume is performed from the test following the last test performed at the time of suspension. [Repeat Cancel] temporarily negates the effect of [Repeat] described in the test scenario in the test file. If this button is pressed during the repetition processing, the process moves to the next test item after the test of the current test file is completed. [End] ends all tests when the test of the test file currently being executed ends. The display mode [detail] switches the display mode of the test result displayed in the [monitor display area] to the detailed display. The display mode [simple] switches the display mode of the test result displayed in the [monitor display area] to the simple display. [Close] closes the test history screen. When the test is [executing], the screen of the test history cannot be closed. End the test with the [End] button.

Next, the screen of the test history (viewer) (not shown) will be described. Select a test from the list on the test list screen in Fig. 9 and press the [History Display] button, or click [Viewer] on the test history screen when the test is [Running].
When a tab is selected, a screen of a test history (viewer) is displayed. The following information is displayed on this test history screen (viewer). The [Viewer Display Area] contains the test file (PR
D) and [Test Result] The contents of the test result file (TRD) are displayed. When a test result file is saved in the [Test Option] menu on the test item setting screen, only the set results are displayed. The test history screen (viewer) has the following buttons. [update]
Updates the test results to the latest state. [Close]
Close the test history screen.

Next, test deletion will be described. The procedure for deleting a test is as follows. Check that the status of the test you want to delete on the test list screen is [Standby]. If another test has already been performed, the status of the relevant test is displayed as "running". Tests in progress cannot be deleted. On the test list screen, select the test you want to delete from the list and press the [Delete] button to display the confirmation screen.
When the [OK] button is pressed, the selected test is deleted from the list. The test folder and data are not actually deleted, but the test folder and data remain.
You can register again with the button.

Next, the procedure for terminating the test list screen will be described. The procedure for closing the test list screen is shown below. Check that the status of all tests is [Standby] on the test list screen. If another test has already been performed, the status of the relevant test is displayed as "running". If there is a test of [Running], an error is displayed when the [End] button is pressed. When the [Exit] button is pressed on the test list screen, the test list screen is terminated and the process returns to the advanced protocol tester menu screen.

Next, the termination of the advanced protocol tester will be described. The procedure for terminating the advanced protocol tester is shown below. All testing machines (boards) in the board list on the menu screen
Confirm that the usage status of is "free". If a test is running, the status of the board will be displayed as "in use". If there is an [in use] test,
An error message is displayed when the [End] button is pressed. When the [Exit] button is pressed on the menu screen, the menu screen is closed and the advanced protocol tester ends.

Next, the end of the test will be described. The running test ends when the following conditions are reached. That is, the normal end is any of the following cases. When all set test items are completed. In the test where the insertion function [Repeat] is set, the user clicks [Cancel Repeat] on the test history (monitor) screen.
When all test items except [Repeat] are completed after pressing the button. When the currently running test ends after the user presses the [End] button on the test history (monitor) screen.

Next, the conditions of the test result NG will be described. The conditions of the test result NG of the advanced protocol tester are shown below. Reception message timeout This NG occurs when the intelligent protocol tester cannot receive the message expected to be received in the test scenario. However, the content of the message does not matter regardless of whether the message is not received. For example, there is a case where after the “call setting” is transmitted, the test scenario expects to receive “call setting reception” but does not actually receive it. Received message collation error This NG occurs when the result of collation between the data content of the message actually received from the network by the advanced protocol tester and the data content of the message expected to be received in the test scenario does not match. For example, there is a case where after the “call setting” is transmitted, the test scenario expects to receive the “call setting reception” but actually receives the “response”.

Next, the operating environment of the system in the advanced protocol tester of the present invention will be described. The components that make up this system consist of hardware and software. First, the hardware components will be described. The hardware consists of a personal computer, a display, and an ISDN board for a high-performance protocol tester. The personal computer has an ISDN board of a high-performance protocol tester and control software installed. IS
A commercially available AT compatible machine equipped with three slots of an A (Industrial Standard Architecture) bus is used exclusively for a high-performance protocol tester.

The ISDN board for a high-performance protocol tester is a board for performing ISDN call control in the high-performance protocol tester. Attach the ISA bus connector on the side to the ISA bus of the personal computer. By connecting the ISDN basic interface cable from the ISDN network to the front ISDN basic interface connector, the network can be used as a pseudo terminal. The board can be connected to four lines. Since the advanced protocol tester can mount three ISDN boards, it is possible to perform a call control test using a maximum of 12 pseudo terminals.

Next, the software will be described. The contents of the installation disk (CD-ROM) of the advanced protocol tester system are as follows. High-performance protocol tester (database construction function) program-System integration menu-Three databases (analysis result DB, abnormal phenomenon D)
B, test scenario DB) DB construction function: Analyzes monitor data and displays a list. -DB browsing function: accesses three databases. -DB collation function: collate with past abnormal phenomenon data. High function protocol tester (pseudo terminal function) program ・ Pseudo call generation function by test scenario ・ Test scenario selection function ・ Sequence error and message error detection function ・ Maximum 3 tests simultaneous execution function with 1 test 4 lines Automatic analysis function program ・ Existing Automatic analysis function of monitor data of protocol analyzer of sequence ・ Display function of sequence and call status Automatic generation function program ・ Function to automatically create test scenario from monitor data of existing protocol analyzer Test scenario creation / edit program ・ New test scenario Ability to create and modify existing test scenarios In addition, the accessories include an operation manual that describes the operation method of this system and a manual about the test scenario registered in advance in the test scenario DB. Test scenarios for test scenario DB A.

Next, an example of the operation environment of the present system will be described. The operating environment of the high-performance protocol tester is as follows: model is AT compatible, CPU is Intel (R) P
entiumII (registered trademark) equivalent or more, memory is 128 MB,
HDD has 20MB free space except OS, OS is Micros
oft (registered trademark) Windows (registered trademark) 95/98, the screen size is 800 x 600 or more, and the others are expansion card slots x 3 compatible with ISA. Also, IS
As the DN line, ISDN of the advanced protocol tester
The board can accommodate four ISDN basic lines with one board. Further, as a condition of the connection line of the high-performance protocol tester, the line interface is ISD.
N basic line, layer 1 is activated on a call basis and always activated, layer 2 is PP, P-MP, depending on the type of test scenario used. Layer 3 is capable of supporting additional services, and operates only according to a scenario.

Next, a description will be given of a usage image of a system using the high-performance protocol tester according to the present invention. FIG. 13 is a conceptual diagram of the use of a high-performance protocol tester as an auxiliary function for analyzing a failure location. For example, the exchange 11 is connected to the IPA terminal 12 at 113 centers nationwide. Now, at a certain center, exchange 11
When the abnormal phenomenon occurs, the IPA terminal 12 acquires the failure monitor data. Then, data is transmitted from the IPA terminal 12 to the high-performance protocol tester 13 in the analysis section. Then, the advanced protocol tester 13 checks the received monitor data against past abnormal phenomena.
Then, the advanced protocol tester 13 performs a reproduction test using the test scenario automatic generation function and the pseudo terminal function,
Identify the abnormal location by the analysis function. Further, this abnormal data is registered as an asset in the abnormal phenomenon database. Thereby, it can be used as collation data of the abnormal phenomenon after the next time.

FIG. 14 is a conceptual diagram of using a high-performance protocol tester as a test terminal when developing a node system. In the case of this usage example, the advanced protocol tester 23 managed by the development department performs a basic function and a degrade test on the exchange 21 by using the test scenario DB and the pseudo terminal function. The processing method when an abnormal phenomenon occurs is the same as in the case of FIG.

Further, by enhancing the network function of the system using the high-performance protocol tester of the present invention, an analysis assisting function can be cut out and used as an IPA analysis tool. FIG. 15 shows an application example of a system in which an IPA analysis tool is cut out from a high-performance protocol tester according to the present invention. The exchange 31 is connected to the IPA terminal 32 at 113 centers nationwide.
Also, from the IPA terminal 32 to the common database server 33
And the IPA analysis tool 34 are connected by a LAN. The common database server 33 uses the IPA
It has a data DB, an abnormal phenomenon DB, and a test scenario DB. Further, the IPA analysis tool 34 is constituted by an existing personal computer.

First, from among the high-performance protocol testers,
Only the DB construction function, the DB collation function, and the analysis function are taken out and distributed as packaged software to persons in charge of analyzing IPA data nationwide. Then, each person in charge installs the received package software on a personal computer that is normally used. Since a board or the like is unnecessary because it does not include the pseudo terminal function, it can be used in a normal notebook personal computer.

In the system constructed as described above, when an abnormal phenomenon occurs in the exchange 31 at a certain center, the IPA terminal 32 acquires failure monitor data when an abnormality occurs. Then, from the IPA terminal 32, the I
The PA data is transmitted to the common database server 33 and the IPA analysis tool 34. Furthermore, IPA analysis tool 3
4 is a common database server 3 by the DB collation function
3 and the IPA data. By using the IPA analysis tool 34, a person in charge of performing a failure analysis at a place where a WS with an IPA terminal is installed or a remote analysis based on a paper such as a facsimile can be used. The analysis can be performed on a personal computer in the office.

The embodiment described above is an example for explaining the present invention, and the present invention is not limited to the above embodiment, and various modifications are possible within the scope of the invention. is there. That is, in the above-mentioned use example, the use mode in the case where an abnormal phenomenon occurs in the exchange has been described. can do.

[0093]

As described above, according to the information sharing system of the present invention, that is, the advanced protocol tester, the person in charge can be changed by making the know-how accumulated in the individual into a database. Even the previous information can be continued. Therefore, at the time of the re-occurrence of the failure phenomenon, it is checked whether or not a past case exists,
If it does, it can take immediate action based on the experience of past cases. In addition, a new failure mode in which no past case exists can be stored as a new asset in the database, and can be used for future failure phenomena.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a high-performance protocol tester according to an embodiment of the present invention.

FIG. 2 is a main screen displayed by a monitor data input function.

FIG. 3 is a screen of an analysis result by a DB construction function.

FIG. 4 shows registration contents registered in an analysis result DB.

FIG. 5 is a screen of a collation result when similar data is detected.

FIG. 6 is a comparison result screen when similar data is not detected and is new data.

FIG. 7 shows registration contents registered in the abnormal phenomenon DB.

FIG. 8 is a menu screen of a high-performance protocol tester.

FIG. 9 is a test list screen of the high-performance protocol tester.

FIG. 10 is a line setting screen in the high-performance protocol tester.

FIG. 11 is a table showing types of lines in a high-performance protocol tester.

FIG. 12 shows a line type test item setting screen in the high-performance protocol tester.

FIG. 13 is a conceptual diagram of using a high-performance protocol tester as an auxiliary function for analyzing a failure location.

FIG. 14 is a conceptual diagram of using a high-performance protocol tester as a test terminal when developing a node system.

FIG. 15 is an application example of a system in which an IPA analysis tool is cut out from a high-performance protocol tester.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Monitor data input function 2 DB construction function 3 Analysis result DB 4 DB collation function 5 Analysis function 6 Abnormal phenomenon DB 7 Test scenario DB 8 Test scenario automatic generation function 9 Pseudo terminal function 11, 21, 31 Exchanger 12, 32 IPA terminal 13 , 23 Advanced Protocol Tester 33 Common Database Server 34 IPA Analysis Tool

Continued on the front page F term (reference) 5B075 KK07 ND03 ND23 ND35 NK02 NK43 PP02 PP12 PP22 PQ02 PQ36 PQ46 QM08 UU40 5K030 GA11 HA08 HC01 HC02 KA01 KA07 KA13 MC07

Claims (8)

[Claims] 1. An information sharing system for effectively using information stored in a database by sharing information stored in a database, wherein a flow of an information generation protocol is used as a search key to compare with past information by a database matching function. In the search results, if the same information exists in the database, take a measure according to a predetermined countermeasure, and if the same information does not exist in the database, create and analyze a scenario that reproduces the information. And information stored in the database as new information. 2. A monitor data input function for inputting monitor data of generated failure information, and the monitor data input by the monitor data input function are analyzed by items such as time, a partner terminal, and a normal / abnormal call. A database construction function for displaying a list, an analysis result database for storing monitor data input by the monitor data input function and data relating to past failure information, and searching for a sequence pattern, a line transmission capability, a line disconnection reason, and the like. A database matching function that uses the key as a key to check whether the monitor data related to the fault information that occurred this time matches the data related to past fault information, and to easily distinguish between the fault information that occurred this time and the past failure information Analyzer that visually displays the call state sequence contained in the data An abnormal phenomenon database that stores data on past failure information; a test scenario database that stores test scenarios for a failure information reproduction test and a basic function confirmation test; and a reproduction based on information from the monitor data. A test scenario automatic generation function for automatically generating a test scenario for a test; The information sharing system according to claim 1, further comprising: 3. When the monitor data relating to the fault information generated this time does not match the data relating to past failure information in the collation result of the database collation function, the test scenario automatic generation function reproduces the monitor data from the monitor data. A test scenario for a test is automatically generated and stored in the analysis result database, and the test scenario is transmitted to the pseudo terminal function so that the pseudo terminal function performs a reproduction test and a degress test. The information sharing system according to claim 2. 4. The information sharing system according to claim 2, wherein the database construction function, the database collation function, and the analysis function are installed on a personal computer to construct an IPA analysis tool. 5. A LAN comprising the IPA analysis tool, an IPA terminal for extracting fault information of the exchange, and a common database server including a database for storing data from the IPA terminal, the abnormal phenomenon database, and the test scenario database. The information sharing system according to any one of claims 2 to 4, wherein the IPA analysis tool analyzes failure information of the exchange at a remote location. 6. An information sharing method for sharing information stored in a database and effectively using the information, wherein a flow of a protocol for generating information is used as a search key to compare with past information by a database matching function. And, in the search result, when the same information is present in the database, a procedure to cope according to a predetermined coping method; and, in the search result, when the same information does not exist in the database, A procedure for creating and analyzing a scenario to be reproduced and then storing it as new information in the database. 7. An information sharing method for sharing failure information stored in a database and effectively using the failure information, comprising: inputting monitor data of the failure information to a database construction function from a monitor data input function; A procedure in which the data of the analysis result by the database construction function is recorded in the analysis result database; and In the case where the input failure information monitor data is the same as the past failure information data, a measure is taken according to a predetermined measure, and the data is inputted from the analysis result database to the analysis function and displayed visually. Procedure and the input failure information monitor data is different from the past failure information data. In this case, the test scenario automatic generation function automatically generates a scenario for the reproduction test, collects the countermeasures after analysis and records it in the analysis result database, and transmits the created test scenario to the pseudo terminal function. A terminal function for executing a continuous test in combination with information from a test scenario database and visually displaying test results on an analysis function. 8. A program for executing an information sharing method for sharing and effectively utilizing information stored in a database, wherein a flow of an information generation protocol is used as a search key, and a past process is performed by a database matching function. A procedure for collating with information, a procedure for coping according to a predetermined coping method when similar information is present in the database in the search result, and a procedure for coping with similar information in the database in the search result. Is a program for executing a method of information sharing including a step of creating and analyzing a scenario for reproducing information and then storing the scenario as new information in the database.