JP3432832B2 - Communication service specification verification method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for verifying a communication service specification for creating a service program in a communication system. Communication services realized by exchanges or intelligent networks are becoming more diversified and complicated.
It is expected to increase with the introduction of SDN. For this reason, it is desired that a service program for communication service control can be generated quickly and easily. The service program is created based on the communication service specification. For this reason, it is desirable to be able to quickly and easily find a specification error in the verification stage of the communication service specification.

[0002]

2. Description of the Related Art As shown in FIG. 10, an intelligent network for connecting a computer to an exchange and performing an advanced communication service includes a service switching node 1, a service control node 2, and a large number of telephone terminals 3. , 4 ... The service switching node 1 has a number of switches 1a, 1b,
., Each exchange has a communication path circuit NW, a central processing unit CCP, a subscriber circuit (not shown), a trunk, and the like. The service control node 2 has a computer configuration and can exchange data with each exchange, and includes a processing unit CPU, a storage unit MM for storing a service program SVP, and a database DB. In such an intelligent network, the calling subscriber A
When there is a call with a special number, the calling exchange 1a notifies the special number to the processing unit CPU of the service control node 2, and the processing unit CPU analyzes the special number input according to the service program SVP. If free dial service, transfer service, etc. are requested by the special number, the telephone number of the called subscriber B is obtained from the database DB, and the analysis result (telephone number, etc.) is transmitted to the originating exchange. 1a, and the service switching node 1 establishes a normal path.

The creation of a service program in such an intelligent network is performed as follows with reference to FIG. That is, the user (service developer) first creates a service specification SSPC in which the specification of the service is described in the service management system 5 using the specification editor SPED. Next, verification for ensuring that the service specification SSPC is correct is performed, and after verification, the service specification SSPC is converted into an executable service program SVP. The service program SVP is loaded on the service control node 2 and used for actual service execution.

[0004]

Conventionally, verification of service specifications has mainly been performed by human manual checks.
Humans can verify even expressions that are not formal languages such as natural languages, and can perform advanced verification including not only logical errors but also semantic errors. However, verification by humans takes time, and errors are often missed.

For this reason, it is desired that a machine read a service specification described in a formal language and verify the service specification automatically. However, there is a problem that it is difficult to detect all errors included in the specification by a simple mechanical method. This is because whether or not a description part in a service specification is incorrect is not determined solely by that part, but depends on the relationship with other parts of the specification.
This is because errors include those that present logical contradiction and those that have semantic inadequacy, and there are various types of errors.

Accordingly, an object of the present invention is to provide a communication service specification verification method capable of automatically, quickly and easily verifying a service specification. Another object of the present invention is to provide a communication service specification verification method capable of flexibly detecting various errors by performing error detection according to various rules.

[0007]

FIG. 1 is a diagram illustrating the principle of the present invention. 11 is a communication service specification storage unit for storing the communication service specification SSPC, and 12 is a verification processing program V
A verification processing unit for verifying the communication service specification based on the RFP; 13 a storage unit for storing an error detection rule ERRL; 14 a data SVD indicating the current service execution state
This is a service execution state storage unit that stores T.

[0008]

One or more error detection rules ERRL for detecting an error in a specification on condition of data indicating a service execution state for each description element of the communication service specification SPPC in advance.
Is set in the error detection rule storage unit 13. Then, when verifying the communication service specification SPPC, the verification processing unit 12 reads the description element of the communication service specification from the communication service specification storage unit 11 as a verification target based on the verification processing program VRFP, and checks all the elements corresponding to the verification target description element. The data SVDT indicating the current service execution state is checked against the error detection rule to check whether there is an error.
If an error exists, an error detection is output. If no error exists, a communication service simulation is performed based on the verification target description element, and data indicating the current service execution state in the service execution state storage unit 14. SVD
After rewriting T, the following description element of the communication service specification is read as a verification target to verify the communication service specification. In this way, the service specification can be automatically verified, and error detection can be flexibly performed by setting various error detection rules. or,
By reflecting the result of the processing performed in the part before the verification target description element in the content of the data indicating the service execution state, the verification can be performed only from the content and the verification target description element, and each verification target description can be verified. It is not necessary to check the previous processing content for each element, and the processing cost can be reduced .

In addition, a simulation rule for determining the next service execution state is set in advance for each description element of the communication service specification on the basis of data indicating the service execution state, and each simulation rule of the verification target description element is set. By comparing the data indicating the current service execution state with the data indicating the next service execution state, it is possible to easily simulate the communication service.

Further, for each description element of the service communication specification,
Set one or more validity detection rules to detect the validity of the specification based on the service execution status, and check the validity by checking the current service execution status against all the validity detection rules corresponding to the element to be verified However, if no match is found with any of the validity detection rules, it is determined that there is an error. If the number of error detection rules for detecting specification errors becomes enormous, the number of rules can be reduced. Can be faster.

[0011]

DESCRIPTION OF THE PREFERRED EMBODIMENTS (a) Hardware Configuration FIG. 2 is a hardware configuration diagram of a system for realizing a communication service specification verification method according to the present invention, 21 is a processing device, 22 stores various programs, rules and other data. A storage device, 23 is an input / output device, and 24 is a bus. Each unit is configured to be able to exchange data via the bus.

The storage device 22 includes a RAM, a ROM, a hard disk, and the like, and stores predetermined programs, rules, and data in each storage element. 22
a is a service specification storage unit that stores a service specification SSPC; 22b is an error detection rule storage unit that stores an error detection rule ERRL described by a production rule “IF to THEN”; and 22c is a verification using an error detection rule. A storage unit for storing an inference control program PRP for inferring an error of a target description element, a storage unit 22d for storing a service simulator program SSMP for executing a service simulation, and a work storage unit 22e for storing data SVDT indicating a service execution state. It is.

Service simulator program SSMP
Refers to the service specification SSPC and the data SVDT indicating the service execution state, simulates the operation of each description element of the service specification, and writes the result to the work storage unit 22e as the data SVDT indicating the service execution state. The inference control program PRP performs a verification process by applying the error detection rule ERRL to the data SVDT indicating the service execution state and the description element of the service specification SSPC. Output to The service simulator program SSMP and the inference control program PRP are executed alternately, and the verification of each element of the service specification proceeds sequentially.

(B) Software Configuration FIG. 3 is a software configuration diagram for realizing the communication service specification verification method according to the present invention, and the same parts as those in FIG. 2 are denoted by the same reference numerals. SSPC is a communication service specification in which a communication service operation is decomposed for each element, and each element is described in a formal language.

ERRL is an error detection rule described by a production rule of the format “IF-THEN-”, and is set for each description element constituting a communication service specification. Each of the error detection rules E1-1, E1-2,... Is described so that specification errors can be inferred on the condition of the description element and the data indicating the service execution state. A detection rule is associated.

The SMRL is a service simulation rule described by a production rule of the format "IF-THEN-", and is set for each description element constituting a communication service specification. Each service simulation rule S1-1, S1-2,... Is described so that data indicating the next service execution state can be inferred on condition of the description element and data indicating the service execution state.
One or more service simulation rules are associated with one description element.

VRFP is a verification processing program, which is a combination of the service simulator program SSMP and the inference control program PRP shown in FIG.
At the time of executing the service simulation, the service simulation is executed based on the description element of the specification using the service simulation rule SMRL, and the data indicating the service execution state is rewritten.
Using the error detection rule ERRL, an error in the specification is detected based on the data indicating the service execution state and the description element of the specification. A work storage unit 22e includes data SVDT indicating a service execution state, a specification description element SEL to be verified, and the like.

[0018] Communication Service Specification 4 is a part specific example of a communication service specifications SSC, U
Part of the PT (Universal Personal Telecommunication) service. The UPT service is a function for calling using a number (personal number) assigned to an individual. When a special number "662" of the UPT service is dialed, the service program instructs the caller to input a personal number by an announcement. This service checks the validity of the input personal number, and if it is valid, converts the personal number into the TEL number of the called party and sends it to the exchange to establish a communication path.

The UPT service specification shown in FIG. 4 is described from a state where the handset is lifted (off-hook state).
It is composed of specification description elements such as state, event, operation, and judgment. In FIG. 4, the elliptical shape means a state, the rectangular shape means an operation, the right end cut shape part means an event, and the both ends mountain shape means a judgment. Also, "c
"s1" means the first service switching node, and "leg0" means the 0th telephone terminal. In FIG. 4, SE1
Is an input number waiting state, SE2 is an event indicating that the special number "662" has been dialed, SE3 is an operation of playing an announcement PSI (a message prompting dial input of a personal billing number PSI), and SE4 is an input PSI (number). ), SE5 is waiting for number input, SE
6 is an event indicating that the number "&x" has been dialed, SE7 is an operation for turning off the announcement, SE8 checks whether the received number "&x" is valid or invalid as the PSI, and sets the result to r. Action to return (r
= PASS, r = ERROR if invalid) SE9 r = PAS
Judgment of whether S (or r = ERROR), SE10 is an operation to play an announcement PTN (a message urging a dial input of a personal number PTN), SE11 is an operation to read an input PTN (personal number), and SE12 is a number input wait. ... These service specifications are described as follows and stored in the storage device.

[0020] csl: Collecting Info SE1 number (csl, leg0,662) SE2 announcement (csl, leg0, PSI) SE3 cllect-user-information (csl, leg0) SE4 col: Collecting Info SE5 number (csl, leg0, & x) SE6 announcement (csl, leg0, Off) SE7 authorization (PSI, x, & r) SE8 r = PASS (or r = ERROR) SE9 announcement (csl, leg0, PIN) SE10 cllect-user-information (csl, leg0) SE11 csl: Collecting Info SE12 ・ ・ ・ ・ ・ ・ ・ ・ ・

Service Simulation Rule FIG. 5 is an example of the service simulation rule SMRL. The service simulation rule SMRL is
Every description element of communication service specification (SSPC), service execution
Condition data (SVDT) as a condition
And it became a state, or according to the description element event
Or after the action or judgment was made,
This defines the service execution state. (a) is a specification description element is the "state: csl: Collecting Info" is a service simulation rules in the case of, when this specification description element has been read, that is, the specification description required
Assuming that the state is in accordance with the element, the “state data” in the data SVDT indicating the current service execution state is “csl:
Collecting Info ”.

(B) shows a case where the specification description element is "event: num
ber (csl, leg0, & * ) "is a service simulation rules in the case of, when this specification description element has been read, to
That is , the event that occurred according to this description element
When was, the current service execution state is "csl: Collecting Info
And the announcement = PSI, the “input data” in the data SVDT indicating the current service execution state is changed to “P”.
This means that "SI input completed" and "* = input number". In addition, "Event: number (csl, leg0, &
In the case of “*)”, the service simulation rule is not limited to one, and is variously described. For example, “if state = csl: Collecting Info and announcement = PTN then input = PTN input completed, * = input number” is described. In this service simulation rule, the specification description element is "event: number (csl, leg0, &*)" while waiting for the input of the personal number PTN.
In the case of, "input data" is set to "PTN input completed" and "* = input number".

The error detection Rules Figure 6 is an example of an error detection rule 22b. (a) is an error detection rule when the specification element is “event: off-hook (csl, leg0)”. When this specification element is read, the current service execution state is “csl: Collecting Info”. If it is, it means an error (off-hook is impossible). This is because it is erroneous that the off-hook is already described and the off-hook is described despite the number input waiting state. Note that the specification description element is "Event: off-hook (cs
In the case of “l, leg0)”, not only one error detection rule but a large number are described.

(B) is an error detection rule in which the specification description element is “judgment”. In the service specification SE9 of FIG. 4, the current service execution state is "PSI authorization", and r @ PAS
If S and r ≠ ERROR, it means an error. It should be noted that this error detection rule can be described as a rule if state indicating validity = PSI authorization and r = PASS then valid if state = PSI authorization and r = ERROR then valid.

In (c), when the specification description element is “operation: announcement:
(csl, leg0, PSI) "is an error detection rule. If the data indicating the current service execution state is" input = PSI input completed "when this specification element is read, it is an error Means This is the entered PSI
This is because it is not possible to announce a message that prompts the user to enter a password. However, depending on the operation, twice PS
If it is conceivable to input I, a step such as “error (input redundancy ?, 0.5)” is described and the possibility of error or validity is 0.5. It can also be represented by a value or a continuous value.

[0026] Data view 7 illustrating a service execution state is an example of a data SVDT indicating the service execution state, the data SVDT indicating the service execution state data, "status data", "connection data", "variable data", There are "input data", "property data", etc., and the processing result of the service executed before the description element to be verified,
Data indicating the state is held. FIG. 7 shows the service execution state data when the specification description element SSE12 of FIG. 4 is read. That is, (1) csl: Collecting I
nfo (PTN number waiting state), (2) telephone terminal and announcement (PTN) are connected, (3) input variable (PIS
No.) x =＝, r = PASS, and (4) PSI is shown to have been input.

(C) Error Verification Processing FIG. 8 is a flowchart of the verification processing program VRFP of the present invention. In the verification process, first, the work storage unit 22
The contents of e are initialized (step 101). Next, it is determined whether the verification process has been completed for all the elements of the service specification SSPC (step 102). If completed, the verification result of “no error detected” is output to the input / output device (step 103). The verification processing ends.

However, if not completed, one specification description element is read from the service specification SSPC as an object to be verified and written into the work storage 22e (step 104).
Thereafter, it is determined whether or not all error detection rules set corresponding to the specification description element to be verified have been referred to (step 105). If not, the remaining error detection rules ERRL are read, and It is checked whether the data indicating the current service execution state matches the detection rule (step 106). If the data does not match (failure), the process returns to step 105. However, if the verification is successful (success), it is determined whether or not an error is described after "then" of the error detection rule (step 107).
Is output to the input / output device (step 108), and the verification processing ends.

If it is determined in step 107 that the error is not found after "then" of the error detection rule, data indicating the property of the specification described after "then" is changed to the service execution state. Write to the indicated data SDVT (Step 108), Step 10
Return to 5. It should be noted that a rule is provided for writing the data indicating the property of the specification to the data SVDT indicating the service execution state on condition that the description element of the service specification and the data indicating the service execution state are used as conditions. By providing a rule in the error detection rule that detects specification errors based on the relationship between data that indicates the nature of the specification, the accuracy of error detection can be improved, and more flexible error detection can be performed. Become.

When the application of all the error detection rules is completed without detecting an error, the service simulation rules SMRL set corresponding to the specification description elements to be detected are sequentially read out, and the current service rule is set in the simulation rule. It is checked whether the data indicating the execution state is collated (step 109). It should be noted that there is a service simulation rule that always matches.

If a simulation rule to be collated is found, the contents of the data SVDT indicating the service execution state are rewritten according to the description after "then" of the rule (step 110), the process returns to step 102, and the subsequent processes are repeated. If an error is detected, the error is corrected and the verification process is performed again from the beginning.

The above is the case where the verification process is performed based on the error detection rule. However, the verification process can be performed based on the validity rule (for example, see FIG. 6D). FIG. 9 is a flowchart of the verification processing program VRFP in such a case. Steps 101 to 104, 1
09 to 110 are the same as those in FIG.

When one specification description element is read as an object to be verified and written in the work storage unit 22e, it is determined whether or not all validity detection rules set corresponding to the specification description element have been referred to (step 201). If it is not referred to, the remaining validity detection rules are read, and it is checked whether or not the data indicating the current service execution state matches the validity detection rules.
Check if the data matches the data indicating the service execution status
Check (step 202), if not collated (match) , return to step 201.

If no match is found with any of the validity detection rules, the verification result of "error detection" is output to the input / output device (step 203), and the verification processing ends. However, if any one of the validity detection rules is checked, step 109
And rewrites the data indicating the service execution state.

The present invention has been described with reference to the embodiments.
The present invention can be variously modified in accordance with the gist of the present invention described in the claims, and the present invention does not exclude these.

[0036]

According to the present invention, an error detection rule for detecting an error in a specification is set in advance for each description element of a communication service specification on the basis of data indicating a service execution state. upon verification of specifications, test
Current service for error detection rules according to the description element of the certificate
Check the execution status data for errors.
If there is an error, error detection is output and
If the service is not present, the current service
Since the data indicating the line status is rewritten and the following description elements of the communication service specification are read to verify the communication service specification, the service specification can be automatically verified and various error detections can be performed. By setting rules, error detection can be performed flexibly.

Further, according to the present invention, the result of the processing performed in the part before the description element to be verified can be reflected in the contents of the data indicating the service execution state. The verification can be performed only from the element, and it is not necessary to check the previous processing content for each verification target element, and the processing cost can be reduced .

According to the present invention, data indicating a service execution state is previously defined for each description element of a communication service specification.
Sumire to determine the next service execution state as
Option rules, and respond to the description elements to be verified.
The current service execution status is indicated in the
Since the data is configured to be compared, the data indicating the next service execution state can be easily inferred,
It is possible to easily simulate a communication service.

Further, according to the present invention, data indicating a service execution state is set as a condition for each description element of the service communication specification.
Rules to detect the validity of the specification
The current support is set in the validity detection rule according to the element to be verified.
The error detection rule that detects specification errors is configured because the data indicating the service execution status is checked for correctness, and if no match is found with any of the validity detection rules, it is determined that an error exists. When the number of rules becomes large, the number of rules can be reduced by appropriately using the validity detection rules, and the error detection speed can be increased.

[Brief description of the drawings]

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

FIG. 2 is a hardware configuration diagram of the present invention.

FIG. 3 is a software configuration diagram of the present invention.

FIG. 4 is a diagram illustrating a specific example of a communication service specification;

FIG. 5 is a diagram illustrating an example of a service simulation rule.

FIG. 6 is a table illustrating an example of an error detection rule.

FIG. 7 is a table illustrating an example of data indicating a service execution state;

FIG. 8 is a flowchart of a verification process according to the present invention.

FIG. 9 is a flowchart of another verification process of the present invention.

FIG. 10 is a configuration diagram of an intelligent network.

FIG. 11 is a schematic explanatory diagram from development to execution of a communication service.

[Explanation of symbols]

11. Communication service specification storage unit 12. Verification processing unit 13. Error detection rule storage unit 14. Service execution state storage unit SSPC ... communication service specification ERRL error detection rule SVDT: Data indicating service execution status VRFP ... Detection processing program

Claims (2)

(57) [Claims] A predetermined service in a communication system is provided.
Communication service for creating a service program to be executed
The verification method as bis specifications in advance, for each description element of the communication service specification (SSPC), service
Specification error, subject to data (SVDT) that indicates the execution status of the application
One or more error detection rules (ERRL) to detect errors
And each description element of the communication service specification (SSPC)
, The condition data (SVDT) indicating the service execution state
The state corresponding to the description element , or the description element
An event or action or judgment is made according to
Service that defines the service execution state after
Simulation rules (SMRL) are set, and communication service specifications are arranged in the order of description.
When one description element is used as a verification target, the verification target
Service execution status before the operation according to the description element is performed
Is acquired and stored, and when verifying a predetermined communication service specification (SSPC), the verification is performed.
Read the testimony object description elements, the total error detection corresponding to the read-out verified description elements
Data indicating the service execution status stored in the rule
Check for errors by matching over data, and outputs the error detection if there is an error, if there is an error, before corresponding to the verification description element
The service simulation rules
The next service execution status is checked by comparing the service execution status
Data (SVDT) to be acquired and stored by the data.
Rewrite the data (SVDT) indicating the service execution status
For example, thereafter, the descriptive elements of the next communication service specification and verification subject
Communication service characterized by reading and verifying
Verification method of the data specification. 2. A method for implementing a predetermined service in a communication system.
Communication service for creating service programs
In the verification method of the scan specification, in advance, for each description element of communication service specification (SSPC), service
Specification of the specification on condition that the data (SVDT)
Configure one or more validity detection rules to detect
And for each description element of the communication service specification (SSPC)
, The condition data (SVDT) indicating the service execution state
The state corresponding to the description element , or the description element
An event or action or judgment is made according to
Service that defines the service execution state after
Set the scan simulation rules (SMRL) leave, also, communication service specification which is formed by arranging the descriptive elements in the order of execution
When one of the description elements is to be verified,
The service execution status before the operation according to the predicate element is performed
The specified data is acquired and stored, and when the predetermined communication service specification (SSPC) is verified, the verification is performed.
Read the testimony object description element, validity detector corresponding to the read-out verified description elements
The conditions of the rule and the stored service execution statement
Data (SVDT) indicating the status
Check the validity and if no match is found in any of the validity detection rules
Determines that there is an error, and if any of the
If confirmed, the service corresponding to the verification description element
Services stored in the simulation rules
The data indicating the next service execution status by comparing the service execution status
Data (SVDT), and the stored service
Rewrite the data (SVDT) indicating the execution status of the
Communication service characterized by reading and verifying
Specification verification method.