KR100396031B1 - Method for diagnostic automatic in mobile switch center - Google Patents

Abstract

The present invention writes a program according to the grammar suggested by the TDL (Test Description Language), translates through a compiler to obtain the execution code, and then automatically performs an exchange test using an emulator. The present invention relates to a switch automatic diagnosis method for performing the present invention. In the present invention, a tester writes a program in accordance with a TDL (Test Description Language) syntax and inputs a test procedure. It converts it into a file and sends it to the emulator, reads the execution code file from the emulator, stores pattern information, execution code, and procedure information for each part, and executes a runthread routine that processes only the execution code. Auto diagnosis.

In addition, when the diagnosis result received data is message output data, the output message is classified by token, and then a PRN (Printout Reference Number) is extracted, and whether the extracted PRN exists in the pattern information area is checked, and the extracted PRN is If present in the pattern information area, data is extracted using the extraction information recorded in the pattern information, a procedure ID registered in the pattern information is extracted, and a waiting run thread is activated.

Description

Method for diagnostic automatic in mobile switch center}

The present invention relates to an automatic diagnosis of an exchange (especially a mobile communication exchange (MSC)), and in particular, a program is written according to a grammar suggested by a test description language (TDL) and translated by a compiler. The present invention relates to a method for automatically diagnosing an exchanger to automatically perform an exchange test using an emulator after acquiring a code.

In the above, TDL is a language designed to input test procedures, ie, man-machine communication (MMC) commands, analyze output messages, process them, and reprocess them. It consists of a GLOBAL part that declares a prototype of a procedure, an MMC part that describes an MMC instruction, an EXECUTE part that can describe an execution statement, and a Procedure Declaration part.

The compiler also refers to a program for translating a program recorded in a high level language into an assembler language or a machine language. The high level languages include PL / 1, CHILL, COBOL, FORTRAN, ALGOL, and the like.

In general, in order to verify general functions in an exchange (especially a mobile communication exchange), a tester directly inputs a man-machine communication (MMC) command through several steps and analyzes the output message to determine the state of the exchange.

Therefore, there was a problem that the verification procedure was complicated. Also, if the verification procedure was simple, the same procedure had to be repeated several times.

Accordingly, the present invention has been proposed to solve various problems that occur when verifying the function of the conventional exchange as described above,

An object of the present invention is to write a program in accordance with the grammar suggested by the TDL (Test Description Language), translate through a compiler to obtain the execution code and then perform an exchange test using an emulator. The present invention provides a method for automatically diagnosing exchanges to be performed automatically.

The present invention for achieving the above object,

The tester writes the test procedure in accordance with the TDL (Test Description Language) grammar, obtains the execution code through the compiler, and automatically executes the test using the emulator to save the human and time resources required for functional verification. do.

For this purpose, the "exchange automatic diagnostic method" of the present invention,

In the state in which the tester writes and inputs a test procedure in accordance with TDL (Test Description Language) syntax, when the automatic diagnosis starts, acquiring the execution code from the compiler, making it into a file, and transmitting it to the emulator;

Reading an execution code file in the emulator, storing pattern information, execution code, and procedure information for each part, and executing a runthread routine that processes only the execution code;

If the received signal after the run thread execution is a signal (BatchMsgToClientSig) transmitted from the ATMP processor to the client, it is checked whether the received data is the command check result data, and if the result is the command check result, the command Performing an operation corresponding to a test result;

If the received data is not the command check result data, it is determined whether the received data is message output data. If the received data is the message output data, the output message is classified by token and then a printout reference number (PRN). Extracting c);

Checking whether the extracted PRN exists in the pattern information area, and extracting data using the extraction information recorded in the pattern information when the extracted PRN exists in the pattern information area;

A procedure ID registered in the pattern information is extracted, and a step of activating a waiting run thread is executed to automatically diagnose an exchange.

1 is a conceptual diagram conceptually showing a switch automatic diagnosis method according to the present invention,

2 is a flowchart illustrating a switch automatic diagnosis method according to the present invention;

3 is a flowchart illustrating a detailed flow of a "RunThread" routine in FIG. 3,

FIG. 4 is a flowchart illustrating a process of processing the execution code analyzed in FIG. 3 when it is a JSR (Jump Sub Routine).

<Explanation of symbols for the main parts of the drawings>

100 ..... Exchange Auto Diagnostics

110 ..... Test procedure input

120 ..... TDL Translation

130 ..... emulator

200 ..... Exchanger

210 ..... Man-Machine Subsystem

Hereinafter, a preferred embodiment of the present invention according to the technical spirit as described above will be described in detail with reference to the accompanying drawings.

1 is a conceptual diagram conceptually showing a switch automatic diagnosis method.

Reference numeral 100 denotes an exchange automatic diagnosis section for automatically testing the function of the exchange, and reference numeral 200 denotes the exchange.

Here, the switch automatic diagnosis unit 100 translates a test procedure input unit 110 for receiving a test procedure program written by a user according to the TDL grammar, and a program inputted from the test procedure input unit 110 to a TDL compiler to perform an execution code. And an emulator 130 for automatically testing the exchanger 200 according to the obtained TDL translation unit 120 and the execution code obtained by the TDL translation unit 120.

In addition, the switch 200 interfaces the data with the switch automatic diagnosis unit 100 and tests the function of each block according to an input command and transmits the result data to the switch automatic diagnosis unit 100. Man-Machine Subsystem) 210.

Referring briefly to the concept of the present invention with reference to FIG. 1, first, a user writes a test procedure program according to the TDL grammar, and the test procedure written by the user in the test procedure input unit 110 in the switch automatic diagnosis unit 100. Get the program.

Then, the TDL translation unit 120 translates the received test procedure program to obtain a performance code.

The file structure of the execution code obtained by the TDL translation unit 120 is shown in Table 1 below.

Executable Code File Structure Pattern Information Instruction Procedure Information Constant string information

In [Table 1], the pattern information includes information on a printout reference number (PRN), a form of extraction, an object to be extracted, and an id of a procedure to be called after extraction of a message to be extracted from the contents defined in the pattern part. Indicates.

Next, Instruction represents the actual execution code. Procedure information indicates default library information, programmer-defined procedure name, procedure ID, instruction start address, and constant string information. Indicates information about strings between double quotes (").

Meanwhile, when acquiring the execution code as described above, the emulator 130 automatically tests the switch 200 through the data interface with the MMS 210 in the switch 200, and analyzes the result data.

Here, an example of testing the exchanger 200 using the actual execution code in the emulator 130 and outputting the result is as follows.

Ex) To check the status of I / O port, "DIS-IO-PORT;" Enters a command and extracts the port number and status from the output message.

Test file contents

PATTERN {

PRN: = MO501;

TYPE: = FIELD, FIELDLN;

PROCEDURE: = M0501_PROC;

FIELD: = "LOC", "=", ptn_Loc;

FIELDLN: = ("PORT", ptn_Port), ("STS", ptn_Sts);

}

EXECUTE {

ExeMmcCommand ("DIS-IO-PORT;");

printf ("\ n Test End");

}

M0501_PROC: PROC ()

DCL i INT;

DCL csLoc STRING;

DCL csPort, csSts STRING ARRAY [20];

GetPatternData (ptn_Loc, csLoc);

printf ("\ n Location =% s", csLoc);

DO FOR (i: = 0; i <20; i +: = 1)

IF GetPatternData (ptn_Port, csPort [i]) <0 THEN

BREAK;

FI;

GetPatternData (ptn_Sts, csSts [i]);

% s ", csPort [i}, csSts [i]);

OD;

END;

Contents of the executable

P P_START 0 / * PATTERN Info * /

P P_PRN M0501

P P_TYPE 11

P P_PROCEDURE 0 LOC 0

P P_FIELD 0 = 0

P P_FIELD 0 ptn_Loc 1

P P_FIELDLN PORT ptn_Port

P P_FIELDLN STS ptn_Sts

P P_END

I 26 -1 0 11

L 0 1

I 2 32 0 13 / * Code for ExeMmcCommand ("DIS-IO-PORT;") * /

I 1 1 0 13

I 27 0 0 13

I 30 0 0 13

I 2 45 0 15 / * printf ("\ nTest End"); * /

I 1 1 0 15

I 27 1 0 15

I 26 -1 0 16

S 00

I 2 0 0 22

I 7 4 1 1

I 2 1 0 25 / * GetPatternData (ptn_Loc, csLoc); * /

I 9 4 1 25

I 1 2 0 25

I 27 4 0 25

I 30 0 0 25

I 2 56 0 27 / * printf ("\ n Location =% s", csLoc); * /

I 3 4 1 27

I 1 2 0 27

I 27 1 0 27

I 1 0 0 29

I 5 0 1 29

I 26 26 0 29 / * DO FOR * /

I 26 0 0 29

I 26 0 0 29

I 26 26 0 29

I 3 0 1 29

I 1 20 0 29

I 17 0 0 29

I 25 23 0 29

I 26 24 0 29

L 25 31

I 1 1 0 29

I 38 19 0 29

I 5 0 1 29

/ * Omit * /

... ... ...

... ... ...

F ExeMmcCommand 0 -1 / * Information about the default library * /

F printf 0 -1

.............

.............

F IsMsgCompleted 0 -1

F sleep 0 -1

F M0501_PROC 1 9 / * Procedure information for M0501_PROC * /

S 1 168

C 84 / * Information about constsnt strings * /

0: ptn_Loc_0: ptn_Port_0: ptn_Sts_DIS_IO_PORT; _

Test End_

Location =% s_

% s_

Next, the emulator 130 reads the execution code file as described above, stores information for each part, starts the RunThread processing only the execution code, and waits for a signal from the RunThread and the MMS 210. When receiving a request to execute a command from the RunThread, the command is loaded into a signal (BatchMsgToClientSig) for transmitting a signal from an ATMP processor to a client and sent to the MMS 210. When a response is received, the waiting RunThread is activated. Allow you to do the following: When the output message arrives from the MMS 210, the output message is divided into tokens (Token: one string separated by a string delimiter), and a PRN (Printout Reference Number) of the message is extracted and the PRN registered in the pattern information. In the case of the registered PRN, the data is extracted using the extraction information recorded in the pattern information, and the procedure ID to be called is extracted from the pattern information to activate the waiting RunThread. When RunThread executes all execution codes and sends a ThreadEnd signal, it releases the memory allocated to each part and ends it.

2 is a flowchart illustrating an automatic diagnosis process in the emulator as described above.

As shown therein, in step S101, the execution code file is read to store pattern information, execution code, and procedure information for each part, and in step S102, a runthread routine for processing only the execution code is executed.

In step S103, a signal from the run thread and the MMS 210 is waited for.

In addition, in step S104, it is determined whether the received signal is BatchMsgToClientSig. As a result, if the received signal is not BatchMsgToClientSig, it is determined in step S114 whether the received signal is a command execution request from the run thread.

As a result, if the received data is a command execution request, in step S115, the command is loaded on the BatchMsgToClientSig and transmitted to the MMS 210, and when a response is received, the waiting run thread is activated to proceed with the next task.

If the received signal is not a command execution request, it is checked in step S116 whether the received signal is run thread end data. As a result, if the received signal is run thread end data, the memory allocated to each part in step S117 is deleted. Release and exit.

On the other hand, if the received signal of the check result of step S104 is BatchMsgToClientSig, in step S105 it is checked whether the received data is the command check result data, and if the received data is the result of the command check result in step S106 corresponding to the command check result Perform the action.

In contrast, when the received data is not the command check result data, it is determined in step S107 whether the received data is message output data. As a result, when the received data is message output data, in step S108, the output message is classified by token, and then a PRN (Printout Reference Number) is extracted.

Thereafter, in step S109, it is checked whether the extracted PRN exists in the pattern information area. If the extracted PRN exists in the pattern information area, data is extracted using the extraction information recorded in the pattern information in step S110.

In addition, in step S111, a procedure ID registered in the pattern information is extracted, and a waiting run thread is activated.

If the extracted PRN does not exist in the pattern information area, go to step S112 to check whether the message output is completed. If the message output is completed, the MMC transmission count is decreased in step S113, and the signal input waits. The process moves to step S103.

On the other hand, the content to be tested by the tester is converted into execution code, stored in the execution code file, assigned to a global variable called InstTbl by the emulator, and processed by RunThread.

3 is a flowchart illustrating an execution code processing process in which the Runthread is included in InstTbl.

As shown therein, the execution code pointer and the MMC transfer counter are initialized in step S201, and in step S202 it is checked whether the execution code pointer IP is less than zero.

As a result, when the execution code pointer IP is larger than zero, it is checked in step S203 whether the MMC transmission count value is larger than zero. If the MMC transmission count value is less than zero as a result of the check, the thread termination message is transmitted to the emulator in step S204.

On the contrary, if the MMC transmission count is greater than zero, the output message is awaited in step S205, the execution code pointer is stored in step S206, and the procedure is searched through the procedure ID in step S207.

Then, if the procedure is searched or if the execution code pointer IP is less than 0 as a result of the determination in step S202, the execution code pointer is increased by 1 and set to the next execution code (Next IP).

In step S209, the type of execution code is analyzed, and in step S210, a test routine is executed by executing a thread corresponding to the analyzed execution code. When the thread for the execution code ends, the execution code pointer is set to the next execution code pointer (Next IP) in step S211, and the process returns to step S202.

On the other hand, after analyzing the type of the execution code, if the execution code is JSR (Jump Sub Routine) processes the JSR (Jump Sub Routine) through the process as shown in FIG.

As shown therein, in step S301, it is checked whether the execution code is a code (ExeMmcCommand) for performing MMC. When the check result execution code is a code for executing MMC (ExeMmcCommand), the command string transmitted to the parameter in step S302 is transmitted to the emulator.

In step S303, the device waits for the emulator to be activated.

After the emulator sends a command to the MMS 210, and receives the result to activate the run thread, it is checked whether an error has occurred in the command sent in step S304. As a result, if an error occurs in the transmitted command, the process returns to the first step. Otherwise, if there is no error in the transmitted command, the command transmission count is increased by 1 in step S305, and the process waits for an output message to be received in step S306.

In addition, when the received message arrives in step S307, the execution code pointer is stored, and the procedure is searched through the procedure ID in step S308. Then, when the procedure is found, it processes the executable code.

That is, if the emulator classifies the output message received by token, extracts the pattern data, and activates the run thread, the run thread stores the execution code pointer that is currently in progress and executes the procedure code through the procedure ID passed by the emulator. Assign the start address to the executable code pointer so that the executable code of the procedure can be processed. Also, when the procedure returns, the stored executable code pointer is fetched so that the work before the jump to the procedure can continue.

The run thread waits without terminating if there is an output message to arrive even though all the execution code has been processed, and when activated, the procedure of the message can be processed.

On the other hand, if the result execution code of step S301 is not a code for executing MMC (ExeMmcCommand), it is checked in step S309 whether the execution code is another default library (LIB), and as a result, if the execution code is another default library, In step S310 the default library is stored. On the other hand, if the execution code is not another default library, the execution code pointer is stored in step S311, and the process returns to the first step.

The runthread performs an operation corresponding to the op-code of the execution code. For example, if you have a statement with "nValue: = nValue + 10;" and this statement is translated to the following code, Runthread adds 10 to the value of nValue and stores it back in nValue:

LDC 10 0 1: push constant 10 to value stack

LDV 10 20 1: Pushes the value of the variable where the offset is 20 from the base address of the procedure with block ID 10 to the value stack.

ADD 0 0 1: Pop twice in value stack, add the value and push it back to value stack

STV 10 20 1: Pop in the value stack and store the value at offset 20 at the base address of the procedure with block ID 10.

The runthread transmits the command string passed as a parameter to the emulator 130 when the op-code is a JSR (Jump Sub Routine) while the execution code is processed, and operand1 representing the procedure ID is ExeMmcCommand, and the emulator 130 Wait until is activated.

When the emulator 130 transmits a command to the MMS 210 and receives the result, and activates Runthread, Runthread checks whether the transmitted command has an error and waits for an output message if there is no error.

After that, if the emulator classifies the output message by token, extracts the pattern data, and activates the runthread, the runthread stores the currently executing execution code pointer and starts the execution code of the procedure through the procedure ID passed by the emulator. By assigning an address to the execution code pointer, the procedure's execution code can be processed. When the procedure returns, the stored execution code pointer is retrieved so that the work before the jump to the procedure can continue.

The Runthread waits without terminating if there is an output message to arrive even though all execution codes have been processed, and when activated, the procedure of the message can be processed.

On the other hand, TDL is a language designed to program the functional test procedure of the exchange (entering MMC command and analyzing the result message and proceeding to the next test according to the result). It consists of a global part that declares global variables and procedures, an MMC part that describes MMC instructions, an EXECUTE section that describes an execution statement, and a procedure declaration section.

Here, the pattern part declares which part of the message to extract as data and which procedure to call after extraction. The syntax is as follows.

<pattern_part> :: = 'PATTERN' '{'

<ptn_type_dcl>

<ptn_prn_dcl>

[<ptn_procedure_dcl>]

{<ptn_field_dcl>}

[<ptn_fieldln_dcl>]

'}'

<ptn_type_dcl>

:: = 'TYPE' ': =' (['FIELD'] {'FIELD'] {',' 'FIELDLN'} │'NONE ')', '

<ptn_prn_dcl> :: = 'PRN' ': =' <prn> {',' <prn>} ','

<ptn_procedure_dcl> :: = 'PROCEDURE' ': =' <ident> ','

<ptn_field_dcl> :: = 'FIELD' ': =' (<string> │ <ident>)

{',' (<string> │ <ident>)} ','

<ptn_fieldln_dcl> :: = 'FIELDLN' ': =' '(' <string> ', <ident>') '

{',' '(' <string> ',' <ident> ')'} ','

<prn> :: = ('A'│'F'│'S'│'M'│'P') <digit> <digit> <digit> <digit>

In addition, the type TYPE is a part of declaring a pattern form of extracted data, and may declare “FIELD”, “FIELDLN”, or “NONE”. If "FIELD" is declared, FIELD Part may appear later. If "FIELDLN" is declared, FIELDLN Part may appear later. "NONE" means no data extraction by pattern. The following is an example declaration.

TYPE: = FIELD;

TYPE: = FIELD, FIELDLN;

TYPE: = FIELD, FIELDLN, FIELDLN;

TYPE: = NONE;

In addition, PRN is a part that declares the print-out reference number of the message to be extracted.

PRN: = M0100;

PRN: = M0351, M0352;

PRN: = P0001;

In addition, a procedure is a part of declaring a procedure to be called after a corresponding message (declared in the PRN) is output.

PATTERN {

.......

PROCEDURE: = M0353_PROC;

}

.....

M0353_PROC: PROC ()

/ * Describe the handling of message M0353 * /

END;

Also, the field is the part that declares to extract some of the specific strings as data in each line of the output message. An example of declaring a field to extract "OK" from "RESULT = OK" as data in each line of the output message is as follows. (The value of ptn_Result can be retrieved using GetPatternData () library).

FIELD: = "RESULT", "=", ptn_Result;

In addition, FIELDLN is a part that declares a pattern in order to extract data as the location of a specific string when dividing a message into columns.

The following is an example of describing the FIELDLN Part to extract the underlined part as data.

MOKDONG_SSP 1999-03-04 14:34:37 THU ON rsh

M6610 DISPLAY SWITCH NETWORK LINK

ASS HWY CLIA-A CLIA-B TSW-A TSW-B LLIA-A LLIA-B

ASP00 00 STD-BY ACTIVE ACTIVE STD-BY STD-BY ACTIVE

ASP01 01 STD-BY ACTIVE STD-BY ACTIVE STD-BY ACTIVE

ASP02 02 STD-BY ACTIVE STD-BY ACTIVE STD-BY ACTIVE

ASP03 03 ACTIVE STD-BY ACTIVE STD-BY ACTIVE STD-BY

ASP04 04 STD-BY ACTIVE ****** ****** ****** ******

ASP05 05 STD-BY ACTIVE ****** ****** ****** ******

ASP06 06 STD-BY ACTIVE ****** ****** ****** ******

COMPLETED

FIELDLN: = ("ASS", ptn_AssNum), ("CLIA-B", ptn_C: iaB);

When the FIELDLN part is described in this way, data at the same position as "ASS" is stored in ptn_AssNu, and data at the same position as "CLIA-B" is stored in ptn_CliaB. If strings that are the reference point of data extraction such as "ASS" and "CLIA-B" are output over several lines, FIELDLN should be declared in the type part as many lines as the number of lines. Here is an example:

MOKDONG_SSP 1999-03-04 14:34:37 THU ON rsh

Mxxxx FIELDLN SAMPLE DATA

Field_A Field_B Field_C Field_D

Field_E Field_F

Data_A1 Data_B1 Data_C1 Data_D1

Data_E1 Data_F1

Data_A2 Data_B2 Data_C2 Data_D2

Data_E2 Data_F2

COMPLETED

TYPE: = FIELDLN, FIELDLN;

FIELDLN: = ("Field_A", ptn_FieldA), ("Field_F", ptn_FieldF);

Since "Field_A" and "Field_F" were printed over two lines, you can see that FIELDLN appears twice in the type.

Next, looking at the string delimiters ('', '＼t', '＼n', '=', '/'), the output message is divided into strings by the string delimiters, and the strings After the match is analyzed, it is determined whether to save the data. The following is a list of strings by output.

-"RESULT = OK"

==> string: "RESULT", "=", "OK"

-"LOCATION = ASP00 / SIDE = A"

==> String: "LOCATION", "=", "ASP00", "/", "SIDE", "=", "A"

-"RSLT = ASP00 (SIDE: A)"

==> String: "RSLT", "=", "ASP00 (SIDE: A)"

In addition, the GLOBAL part declares the prototype of global constants, global variables, and procedures. The syntax is as follows:

<global_part> :: = 'GLOBAL' '{'

{(<syn_dcl> │ <var_dcl> │ <procedure_def>)}

'}'

<syn_dcl> :: = 'SYN' <ident> ': = "<arithmetic_expression>'; '

<var_dcl> :: = 'DCL' <ident> {',' <ident>} <var_type> [<array_dcl>] ','

<var_type> :: = 'INT'│'STRING'

<array_dcl> :: = 'ARRAY' {'[' <arithmetic_expression> ']'} 1

<procedure_def>

:: = <ident> ', `` PROC' '(' [<parameter_lists_def>] ')' ['(' <var_type> ')'] ','

<parameter_lists_def> :: = <parameter_list> {',' <parameter_list>}

<parameter_list> :: = [<ident> {',' <ident>}] <var_type> ['LOC']

Here, SYN is a part of declaring a constant variable, and the values that can be assigned to the variable are integers, strings, constant variables, and expressions (the formula may include constant variables).

SYNg_cnMaxAsp: = 32;

SYNg_cnMaxCmd: = 100;

SYNg_csDisIoPortCmd: = "DIS-IO-PORT;";

SYNg_cnMaxLoopCnt: = g_cnMaxAsp / 16;

DCL is a part that declares a variable. It can be declared as an integer or string type and can also be declared as an array of up to 5 dimensions.

* integer type: Integer value between -214783648 and 2147483647

* string type: string surrounded by double quote (") ex)" word "," 124 ",

* The index of the array is from 0 to array size-1.

DCLg_nStartAspNo, g_nEndAspNo INT;

DCLg_sCmdName STRING ARRAY [g_cnMaxAsp] [g_cnMaxCmd];

Programmer-implemented procedures must specify parameter types and return types in the GLOBAL section. At this time, the name of the parameter can be omitted. If there is no return value, the return type can also be omitted.

AddString: PROC (first STRING, second STRING) (STRING);

AddString: PROC (first, second STRING) (STRING);

AddString: PROC (STRING, STRING) (STRING);

The above statements are the same statement that defines that the AddString procedure takes two string type parameters and converts a string type value.

Also, MMC Part is a part that directly describes the MMC instruction to be executed.

PATTERN {

.....

}

GLOBAL {

.....

}

DIS_IO_PORT; / * MMC part * /

DIS_PRCS_STS: HMP; / * MMCpart * /

In addition, Execution Part is a part that can describe Execution statement. The syntax is as follows.

<exec_part> :: = 'EXXCUTE' '{'

{<statements>}

Here is an example:

PATTERN {

.....

}

GLOBAL {

.....

}

(1) EXECUTE {

g_nStartAspNo: = 0;

(2) DIS-IO-PORT;

(3) DIS-PRCS-STS: HMP;

(4) EXECUTE {

g_sCmdName [0] [0]: = "DIS_SN_STS:" + g_nStartAspNo;

g_sCmdName [0] [1]: = "," + g_nEndAspNo + ",";

}

(4) in order.

Also, the Procedure Declaration Part declares a procedure. The syntax is as follows:

<procedure_dcl> :: = <ident>

':' 'PROC' '(' [<parameter_lists_dcl>] ')' ['(<var_type>') ']

{(<syn_dcl> │ <var_dcl>)}

{<statements>}

'END' [<ident>] ';'

<parameter_lists_dcl> :: = <parameter_list_dcl> {',' <parameter_list_dcl>}

<parameter_list_dcl> :: = <ident> {',' <ident>} <var_type> ['LOC']

Yes)

AddStrmstring: PROC (first STRING, second STRING) (STRING)

DCL sRetValueSTRING;

sRetValue: = first + second;

RETURN (sRetValue);

END AddString

Call by value and call by reference can be used as the parameter passing method of the procedure. When "LOC" is declared after the parameter type, it means call by reference and if there is only a parameter type, call by value.

* In case of Call by value, since the value of the actual parameter is copied to the formal parameter, the actual parameter does not change even if the formal parameter is changed.

EXECUTE {

g_nFirst: = 10;

g_nSecond: = 20;

Some Func (g_nFirst, g_nSecond);

printf ("'n g_nFirst =% d, g_nSecond =% d", g_nFirst, g_nSecond);

}

SomeFunc: PROC (nFirst, nSecond INT)

nFirst: = 30;

nSecond: = 40;

printf ("'n nFirst =% d, nSecond =% d', nFirst, nSecond);

END;

The above execution result is as follows.

nFirst = 30, nSecond = 40

g_nFirst = 10, g_nSecond = 20

* In the case of a call by reference, the formal parameter is another name of the actual parameter.

EXECUTE {

g_nFirst: = 10;

g_nSecond: = 20;

Some Func (g_nFirst, g_nSecond);

printf ("'n g_nFirst =% d, g_nSecond =% d", g_nFirst, g_nSecond);

}

SomeFunc: PROC (nFirst, nSecond INT Loc)

nFirst: = 30;

nSecond: = 40;

printf ("'n nFirst =% d, nSecond =% d", nFirst, nSecond);

END;

The above execution result is as follows.

nFirst = 30, nSecond = 40

g_nFirst = 30, g_nSecond = 40

Next, statement represents the execution statement that can be used in TDL. The syntax is as follows.

<statements> :: = {<statement>}

<statement>

:: = <assignment_st> │ <call_st> │ <loop_st> │ <if_st> │ <control_st> │ <null_st>

<assignment_st>

:: = <ident> {'[' <expression> ']'} <assign_operator> <expression> ';'

<assign_operator> :: = [('+' │ '-' │ '*' │ '/' │ '%')] ': ='

<call_st> :: = <ident> '(' [<actual_para_lists>] ')' ';'

<loop_st> :: = <do_for_loop> │ <do_while_loop>

<if_st> :: = 'IF' <expression> 'THEN' <statements>

{'ELSIF' <statements>}

{'ELSE' <statements>}

'FI' ';'

<control_st> :: = ('BREAK'│'continue'│'RETURN'│'STOP') ';'

<null_st> :: = ';'

<actual_para_lists> :: = <expression> {',' <expression>}

<do_for_loop>

:: = 'DO''FOR' '(' [<do_for_init> ',' [<expression>] ',' [<do_for_last>] ')' <statements>

'OD' ';'

<do_while_loop> :: = 'DO' 'WHILE' '(' <expression> ')' <statements>

'OD'

<do_for_init> :: = <assignment_st> {',' <assignment_st>}

<do_for_last> :: = <assignment_st> {',' <assignment_st>}

<expression> :: = <algebra_exp>

<algebra_exp> :: = <relational_exp> ('OR'│'AND') <relational_exp> │

'NOT' <relational_exp> │

<relational_exp>

<relational_exp> :: = <arithmetic_exp> ('>' │ '> =' │ '<' │ '<=' │ '=' │ '/ =')

<arithmetic_exp> │ <airthmetic_exp>

<arithmetic_exp> :: = <value> ('+' │ '-' │ '*' │ '/' │ '%') <value> │ '-' <value> │

<value>

<value> :: = <ident> {'[' <expression> ']'} │

<digits> │

<string> │

<call_st> │

'(' <expression> ')'

In this case, the Assignment statement indicates the assignment of a value to a variable.

g_nStartAspNo: = 10;

g_sCmdName [0] [1]: = "DIS-SN-STS: 1,10;"

g_sCmdName [0] [2]: = AddString ';'

g_nStartAspNo +: = 10; ==> g_nStartAspNo: = g_nStartAspNo + 10;

g_nEndAspNo%: = 5; ==> g_nEndAspNo: = g_nEndAspNo% 5;

The Call statement indicates that the procedure is called. For example:

AddString (g_sCmdName [0] [0], g_sCmdName [0] [1]);

GetPatternData (ptn_AspNum, g_sCmdName [0] [3]);

Loop statement is a statement that repeats a given section. There are DO-FOR loop and DO-WHILE loop.

The DO-FOR Loop processes the initialization process before entering the loop and repeats the loop body and the last action while the given condition is true.

nTotal: = 0;

DO FOR ((1) nIndx: = 1; (2) nIndx <= 10; (4) nIndx +: = 1)

(3) n Total +: = n Indx;

OD:

printf ("\ n Total =% d", nTotal);

(2) ....

The DO-WHILE loop repeats the loop body if the given condition is true.

nTotal: = 0;

nIndx: = 1;

DO WHILE ((1) nIndx <= 10)

(2) n Total +: = n Indx;

(3) n Indx +: = 1;

OD;

printf ("\ n Total =% d", nTotal);

(3) .....

Also, IF statement is a statement to change the processing contents according to conditions.

nEvenTotal: = 0;

nOddTotal: = 0;

DO FOR (nIndx: = 1; nIndx <= 10; nIndx +: = 1)

IF (1) nIndx% 2 = 0 THEN

(2) nEvenTotal +: = nIndx;

ELSE

(3) nOddTotal +: = nIndx;

FI;

OD;

printf ("＼n Even Total =% d, Odd Total =% d", nEvenTotal, nOddTotal);

The above example is a code that calculates the sum of even and odd numbers from 1 to 10. If nIndx is divided by 2 and the remainder is 0, it executes (2), otherwise it executes (3).

IF nSum <50 THEN

sGrade: = "F";

ELSIF nSum <60 THEN / * 50 <= nSum <60 * /

sGrade: = "E";

ELSIF nSum <70 THEN / * 60 <= nSum <70 * /

sGrade: = "D";

ELSIF nSum <80 THEN / * 70 <= nSum <80 * /

sGrade: = "C";

ELSIF nSum <90 THEN / * 80 <= nSum <90 * /

sGrade: = "B";

ELSIF / * nSum> = 90 * /

sGrade: = "A";

FI;

The above example is the code to get sGrade according to the value of nSum.

Next, the Control statement is used to control the execution position, such as moving control within the loop to the last execution of the loop, or moving control to where the procedure was called from within the procedure.

"BREAK" is a control statement that transfers control out of a loop.

DO FOR (nIndx: = 1; nIndx <= 100; nIndx +: = 1)

nTotal +: = n Indx;

IF nTotal> 100 THEN

BREAK; / * If nTotal is greater than 100, we leave the loop

FI;

OD;

DO FOR (i: = 0; i <10; i +: = 1)

DO FOR (j: = 0; j <10; j +: = 1)

IF g_nInformTb [i] [j] <0 THEN

BREAK; / * If g_nInformTb1 [i] [j] is less than 0, transfer control to point # below. * /

FI;

OD;

# printf ("\ n j =% d", j);

IF j <10 THEN

BREAK; / * If j is less than 10, transfer control to point @ * /

FI;

OD;

@ printf ("\ n i =% d", i);

"CONTINUE" is a statement that transfers control to the last part of the loop, and transfers control to the last action part in the case of a DO-FOR loop and to the condition part in the case of DO-WHILE.

DO FOR (i: = 0; i <100; #i +; = 1)

IF i% 2 = 0 THEN

CONTINUE; / * i divided by 2 transfers control to # when the remainder is zero. * /

FI;

nTotal +: = i;

OD;

i: = 0;

DO WHILE (@ i <100)

IF i% 2 = 0 THEN

i +: = 1;

CONTINUE; / * Transfer the control to # if i divided by 2 and the remainder is 0. * /

FI;

nTotal +: = i;

i +: = 2;

OD;

"RETURN" transfers control to where the procedure was called from within the procedure.

EXECUTE {

g_nTotal1: = SumFunc (50);

g_nTotal2: = SumFunc (200); / * g_nTotal2 will have -1 * /

}

SomeFunc: PROC (nMax INT) (INT)

DCL indx INT;

DCL nTotal INT;

IF nMax> = 100 THEN

RETURN-1;

FI;

nTotal: = 0;

DO FOR (indx: = 0; indx <nMax; indx +: = 1)

nTotal +: = g_nArray [indx];

OD;

RETURN (nTotal)

END Some Func;

"STOP" is a statement that terminates all executions.

On the other hand, operators that can be used in TDL statement are as follows.

Assignment operator (: =)

Logical operators (AND, OR, NOT) where AND is true if both operands are true, false otherwise, OR is false if both operands are false, otherwise true, NOT is false if the operand is true, and the operand is False indicates that it is true.

Relational operators (>,> =, <, <=, =, / =) where> operator is true if left operand is greater than right operand,> = operator is true if left operand is greater than or equal to right operand, <operator is True if left operand is less than right operand, <= true if left operand is less than or equal to right operand, = operand is true if left operand and right operand are equal, / = operand is true if left operand and right operand are not equal Indicates.

Arithmetic operator (+,-, *, /,%) where + operator indicates that if both are of type INT, add string if both are of type STRING, and converts INT type to string if only one of them is STRING type .

Yes)

12 +13 => 25

"This" + "is" => "This is"

123+ "sample" => "123 sample"

"text" +456 => "text456"

12 + 13 + "book" => "25book"

In addition, the-operator indicates that if two operands are subtracted, and if one, the operand is multiplied by -1.

Yes)

10-5 => 5

-(10 + 5) => -15

And the * operator represents multiplication.

Yes)

2 * 3 => 6

The / operator represents division ("Devide by zero" error occurs if the number of jets is zero).

Yes)

2/3 => 0

4/3 => 1

2/0 => Devide by zero error

The% operator represents the remainder.

Yes)

2% 3 => 2

4% 3 => 1

3% 3 => 0

Where the *, /, and% operators take precedence over the + and-operators.

In addition, the order of precedence for each operator is parenthesis "()"> arithmetic operator> relational operator> logical operator> assignment operator.

Next, TDL library is as follows.

1) ExeMmcCommand (sCmdString STRING) (INT): Sends sCmdString (command string) to MMS (Man-Machine Subsystem) for execution. If there is a transfer failure and an error on sCmdString, it returns a value less than zero.

Example 1)

ExeMmcCommand ("DIS-PRCS-STS: HMP;");

Example 2)

g_csCmdString: = "DID-PRCS-STS" + ":" + "HMP;";

ExeMmcCommand (g_csCmdString);

2) printf (sFormatString STRING, *): Formats parameters using sFormatString and prints them to the screen.

Yes)

g_csCmdString: = "DIS-IO-PORT";

printf ("'n This is a sample =% d,% s", 1234, g_csCmdString);

=> "This is a sample = 1234, DIS-IO-PORT" is displayed on the screen.

3) sprintf (sMsgString STRINGLOC, sFormatString STRING, *): Format parameters using sFormatString and assign it to sMsgStrinG.

Yes)

sSorStr: = "HMP";

sprintf (g_csCmdString, "DIS-PRCS-STS:% s;", sSorStr);

=> g_csCmdString contains "DIS-PRCS-STS: HMP;"

4) fprintf (sFileName STRING, sFormatString STRING, *) (INT) Formats parameters using sFormatString and writes them to the file pointed to by sFileName. On failure, it returns a value less than zero (the '' character in the string is used to represent special codes ('\ n', '\ t', ...), so use the directory separator "\". It should be marked with '＼＼' to indicate.

Yes)

fprintf ("c: \ Temp＼＼MyResult.log", "\ n !! Error:% d", nErrorCode);

=> If nErrorCode is -1, "＼ !! Error: -1" is added to the end line of "c: \ Temp \ MyResult.log" file.

5) GetPatternData (sPatternString PTNDATA, sData STRING LOC) (INT): Allocate the data located in sPatternString among the extracted data after message output to sData. If there is no data, it returns a value less than zero.

6) RewindPatternData (sPatternString PTNDATA): Returns the position of the data pointed to by sPatternString among the extracted data of the output message for the first time.

7) atoi (sMsgSTRING) (INT): convert sMsG to Integer and return.

Yes)

nValue: = atoi ("12345");

=> nValue stores the number 12345.

8) StrLength (sMsg STRING) (INT): Returns the length of sMsg.

Yes)

nLen: = StrLength ("12345");

=> 5 is stored in nLen.

9) StrRight (sMsg STRING, nLen INT) (STRING): Returns nLen characters from the right side of sMsg.

Yes)

sNum: = StrRight ("ASP01", 2);

=> "01" is stored in sNum.

10) StrLeft (sMsg STRING, nLen INT) (STRING): Returns nLen characters from the left side of sMsg.

Yes)

sPrc: = StrLeft ("HMP-A", 3);

=> sPrc stores "HMP".

11) StrMiddle (sSource STRING, nPos INT, nLen INT) (STRING): Returns nLen strings from nPos position of sSource string.

Yes)

sMiddle: = StrMiddle ("12345", 1, 2);

=> In sMiddle, "12345" is stored in two strings "23" from 1st position.

12) StrFind (sSource STRING, sTarget STRING) (INT): Search sSource string to see if it contains sTarget string and return its position (value indicating string position starts from 0 and -1 if no sTarget string exists) Is returned).

Yes)

nPos: = StrFind ("12345", "34");

=> nPos stores the first position 2 of "12345" to "34 '.

13) GetPrn () (STRING): Returns the Print-out Reference Number of the printed message. => GetPrn must be used when the procedure declared in PATTERN is called.

14) WriteOutputMsg (sFileName STRING) (INT): Save the output message to the file pointed to by sFileName. If the save fails, it returns a value less than zero. => WriteOutputMsg must be used when the procedure declared in PATTREN is called.

15) GetMmcFailCrn () (INT): When MMC Execution Fail occurs (when there is no response from MMC processing application), the command number is returned. If execution is normal, -1 is returned.

16) MakePseudoMsg (nPrn INT): Creates a Pxxxx (xxxx is nPrn) message corresponding to nPrn. If Pxxxx is declared in the PRN item of the pattern part and the procedure name is declared in the procedure item, the procedure is called.

17) eprintf (sFormatStringSTRING, *) Formats parameters using sFormatString and prints them to the error window display => The error window can only be opened using eprintf or OutputMsgToErr.

Yes)

eprintf ("\ n !! ERROR Invalid ASP status =% d", rErrorCode);

18) OutputMsgToErr (): Outputs the MMC output message to the error window screen. => OutputMgToErR must be used when the procedure declared in PATTERN is called (the error window can only be opened using eprintf or OutputMsgToErr).

19) SetMmcWaitFlag (nFlag INT): Specifies whether to wait for execution result when executing MMC command through ExeMmcCommand (). If nFlag is not 0, it waits until the execution result is received (by default ExeMmcCommand () waits until the execution result is received).

Yes)

EXECUTE {

/ * Execute DIS-IO-PORT; and wait for an output message * /

ExeMmcCommand ("DIS-IO-PORT;");

SetMmcWaitFlag (FALSE);

/ * Do not wait for the result message when executing ExeMmcCommand () afterwards.

ExeMmcCommand ("DIS-PRC-STS;"); / * Just execute and return immediately * /

}

20) GetToken (nLine INT, nNth INT, sString STRING LOC) (INT): Assign the nNtH th string of nLine of MMC output message to sString and return the length of the string (Line starts from 1, nLine and nNth If no string exists for the location of-, -1 is returned).

21) GetMsgLineCount () (INT): Returns the number of lines in the MMC output message => GetMsgLineCount should be used when the procedure declared in PATTERN is called.

Yes)

PATTERN {

PRN: = M6612;

TYPE: = NONE;

PROCEDURE: = RSLT_PROC;

}

.....

RSLT_PROC: PROC ()

DCL sStr STRING;

DCL nLen, i INT;

DCL nLineCnt INT;

DO FOR (i: = 1; i <= nLineCnt; i +: = 1)

nLineCnt: = GetMsgLineCount ();

nLen: = GetToKen (i, 1, sStr);

printf ("\ n FIRST STRING =% s, LEN =% d", sStr, nLen);

OD;

END;

=> Print the first string in each line of the output message.

22) IsMsgCompleted () (INT): Returns whether the MMC output message is closed. 1 is returned if the output message ends with "COMPLETED", or 0 if the output message ends with "CONTINUED". => IsMsgCompleted must be used when the procedure declared in PATTREN is called.

Yes)

PATTERN {

PRN: = M0100;

TYPE: = NONE;

PROCEDURE: = RSLT_PROC;

}

......

RSLT_PROC: PROC ()

/ * Other Processing * /

IF IsMsgCompleted () THEN

printf ("Message = COMPLETED");

ELSE

printf ("Message = CONTINUTED,");

FI;

END;

If the test file is as above and the following message is displayed, message = CONTINUED, Message = CONTINUED, Message = COMPLETED is displayed on the screen.

KTF_PCX 1990-01-07 09:21:10 SUN ON PORT 24

M0100 EXAMPLE OUTPUT MESSAGE

RESULT = NOK

CONTINUDE

KTF_PCX 1990-01-07 09:21:10 SUN ON PORT 24

M0100 EXAMPLE OUTPUT MESSAGE

RESULT = NOK

CONTINUED

KTF_PCX 1990-01-07 09:21:10 SUN ON PORT 24

M0100 EXAMPLE OUTPUT MESSAGE

RESULT = OK

COMPLETED

23) sleep (nSec INT) (INT): Sleeps by nSec in seconds. On failure, -1 is returned.

Yes)

sleep (10); / * Wait 10 seconds * /

According to the above-described "exchange automatic diagnostic method" of the present invention, it is possible to batch process the operator commands (MMC) that require various kinds of repetitive execution required for the diagnosis of the exchange system by an automated tool. There is this.

In addition, there is an advantage that provides the operator with the cause of the failure by automatically analyzing the batch processed results.

In addition, the above advantages have the advantage of minimizing the human, time, and economic waste of installing, checking and stabilizing the system, and also improving the quality of the exchange system.

Claims (7)

In the automatic diagnosis method of the exchanger, In the state in which the tester writes and inputs a test procedure in accordance with TDL (Test Description Language) syntax, when the automatic diagnosis starts, acquiring the execution code from the compiler, making it into a file, and transmitting it to the emulator; Reading an execution code file in the emulator, storing pattern information, execution code, and procedure information for each part, and executing a runthread routine that processes only the execution code; When the received signal is a signal (BatchMsgToClientSig) for transmitting a signal from the ATMP to the client after executing the run thread, it is checked whether the received data is the command check result data, and the received data is the command check result. If the step of performing an operation corresponding to the command check result; If the received data is not the command check result data, it is determined whether the received data is message output data. If the received data is the message output data, the output message is classified by token and then a printout reference number (PRN). Extracting c); Checking whether the extracted PRN exists in the pattern information area, and extracting data using the extraction information recorded in the pattern information when the extracted PRN exists in the pattern information area; And extracting a procedure ID registered in the pattern information and activating a waiting run thread. 2. The method of claim 1, further comprising: checking whether message output is complete when the extracted PRN does not exist in a pattern information area; And when the output of the check result message is completed, reducing the MMC transmission count and switching to a signal input standby state. The method of claim 1, further comprising: determining whether the received signal is a request for execution of a command from a run thread when the received signal is not a signal (BatchMsgToClientSig) for transmitting a signal from an ATMP to a client; If it is determined that the received data is a command execution request, putting the command on the signal BatchMsgToClientSig to the MMS and activating a waiting run thread when a response is received; If the received signal is not a command execution request, check whether the received signal is run thread termination data, and if the received signal is run thread termination data, release the memory allocated to each part and then terminate. Exchange automatic diagnosis method characterized in that it comprises a further. The method of claim 1, wherein the run thread routine to be executed, Initializing the execution code pointer and the MMC transmission counter and checking whether the execution code pointer (IP) is less than zero in the waiting state; and if the execution code pointer is greater than zero as a result of checking the execution code pointer, the MMC transmission count Checking whether the value is greater than 0, transmitting a thread termination message to the emulator if the MMC transmission count value is less than zero, and waiting for an output message if the MMC transmission count is greater than zero. And storing the execution code pointer when the output message is received, searching for the procedure through a procedure ID, and when the procedure is searched or the execution code pointer IP is less than zero. Incrementing the execution code pointer by 1 to set the next execution code (Next IP); analyzing the type of the execution code; Executing a test routine by executing a thread corresponding to the executed execution code, and when the thread for the execution code ends, setting the execution code pointer to the next execution code pointer (Next IP) and searching for the execution code pointer. Switch automatic diagnosis method characterized in that the step consisting of moving to the step. The method of claim 4, wherein after analyzing the type of the execution code, when the execution code is a jump subroutine (JSR), Checking whether the execution code is a code for executing MMC (ExeMmcCommand); and if the check result code is an code for executing MMC (ExeMmcCommand), transmitting the command string passed as a parameter to the emulator Waiting for the emulator to be activated, checking if an error has occurred in the transmitted command, returning to the first step if an error occurs in the transmitted command, and transmitting the command If there is no error, increasing the instruction transmission count by 1, waiting for the output message to be received, storing the execution code pointer when the received message arrives, searching for the procedure by the procedure ID, And when the procedure is found, controlling to process the execution code. Auto diagnosis method. The method as claimed in claim 5, further comprising: checking whether the execution code is another default library (LIB) if the execution code is not ExeMmcCommand for performing the MMC. Is another default library, and if the execution code is not another default library, the step of storing the execution code pointer and moving to the first step is further included. Way. The method of claim 5, wherein the controlling of the execution code in the searched procedure comprises: classifying the received output message for each token, extracting pattern data, and activating a run thread; The thread stores the currently executing execution pointer and assigns the execution code start address of the procedure to the execution code pointer through the procedure ID passed by the emulator, so that the execution code of the procedure can be processed. And returning the stored execution code pointer to control the operation before the jump to the procedure.