JP2009265996A - Inspection device, verification method and verification program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To improve verification performance for a system to be verified. <P>SOLUTION: A verification device includes: a relational database storing a state transition model representing transition among a plurality of states; a verification condition receiving means for receiving input of verification condition for the state transition model described in a CTL expression; a syntax analysis means for generating a syntactic tree including a plurality of nodes respectively associated with logical expressions by analyzing the verification condition wherein the logical expression for a parent node is defined based on the logical expression corresponding to a child node and an operator assigned to the parent node; a search sentence generating means for generating a search sentence for searching for a state satisfying the logical expression corresponding to each node of the syntactic tree; and a search execution means for searching the relational database for each search sentence in descending order of depth of node in hierarchy toward a root node from a leaf node in the syntactic tree, and thereby respectively acquiring a state corresponding to the each search sentence. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to an inspection apparatus, a verification method, and a verification program. For example, in system development including software, the present invention relates to model inspection that is one of methods for verifying correctness of specifications.

  Model checking is a method for comprehensively verifying the sufficiency of verification conditions for all states and state transitions that can be taken under a certain condition. Model checking includes a step of generating a finite state transition system from specifications and a step of verifying verification conditions described by a computational tree logical expression (CTL). In the conventional model checking, when the size of the verification target system is increased, a state explosion occurs, and the verification becomes difficult or the performance is remarkably deteriorated.

  The present invention provides a verification device, a verification method, and a verification program that can improve verification performance.

The verification apparatus as one aspect of the present invention includes:
A first relational database storing a state transition model expressing transitions between a plurality of states;
A verification condition accepting means for accepting an input of a verification condition of the state transition model described by a computational tree logic (CTL) expression;
By analyzing the verification condition input to the verification condition receiving unit, a syntax tree including a plurality of nodes each associated with a logical expression is generated, and the logical expression of the parent node is a logical expression corresponding to the child node. A parser means defined based on an expression and an operator assigned to the parent node;
A search statement for searching for a state satisfying a logical expression corresponding to each node of the syntax tree is set such that the search statement of the parent node uses an output of a logical expression corresponding to the child node of the parent node as an argument. A search statement generation means for generating;
By executing each search statement generated by the search statement generation means with respect to the first relational database in the order of nodes in the hierarchy from the leaf node to the root node in the syntax tree, Search execution means for acquiring the corresponding states as search results,
Search result output means for outputting a search result corresponding to at least a root node of the syntax tree;
Is provided.
The verification method as one aspect of the present invention includes:
Preparing a first relational database storing a state transition model expressing transitions between a plurality of states;
A verification condition receiving step for receiving an input of a verification condition of the state transition model described by a computational tree logic (CTL) expression;
By analyzing the verification condition input in the verification condition receiving step, a syntax tree including a plurality of nodes each associated with a logical expression is generated, and the logical expression of the parent node is the logical expression corresponding to the child node. A parsing step defined based on an expression and an operator assigned to the parent node;
A search statement for searching for a state satisfying a logical expression corresponding to each node of the syntax tree is set such that the search statement of the parent node uses an output of a logical expression corresponding to the child node of the parent node as an argument. A search statement generation step to generate,
By executing each search sentence generated by the search sentence generation step with respect to the first relational database in the order of nodes in the hierarchy from the leaf node to the root node in the syntax tree, each search sentence is executed. A search execution step for acquiring the states corresponding to each as a search result,
A search result output step of outputting a search result corresponding to at least a root node of the syntax tree.
A verification program as one aspect of the present invention causes a computer to execute each step of the verification method.

According to the present invention, verification performance can be improved.

First, terms used in the description of this embodiment will be defined.
(1) RDB (Relational DataBase): A database based on a relational model. In the relationship model, a relationship is defined between domains as a direct product subset of a plurality of data sets (domains). Specifically, relationships are expressed in tabular form, each column represents one domain, and each row represents a combination (ie, relationship) of elements in each domain. The relational database makes it possible to search for data by applying relational algebra (union, projection) to this relational model.

(2) FSM (Finite State Machine): A behavioral model consisting of a finite number of states and state transitions. FIG. 2 shows an example of FSM based on the OS task management function. Each circle represents one “state”, and a directed curve connecting the states represents one “state transition”. “1” and “2” such as S1 and S2 in the circle are state identifiers. “1” and “2” such as T1 and T2 of the directed curve are state transition identifiers.

  FIG. 2 shows the FSM for three tasks 1, 2, and 3. Each task has three states: an execution (RUN) state, an executable (RDY) state, and an execution waiting (WAI) state. Has one state. "RUN", "RDY", and "WAI" correspond to the variable names that make up the state. Each task has three types of operations: a spontaneous CPU yield (yield) operation, a spontaneous transition to the execution wait state (sleep), and a change of the task waiting for execution to a ready state (wakeup). API (Application Programming Interface) functions are provided. A task in the run (RUN) state selectively executes yield, sleep, and wakeup.

(3) CTL (Computational Tree Logic) expression: A logical system that describes a statement whose truth value can change over time, and is a requirement specification related to system behavior (which is a system verification condition) ) Can be described. An example of the CTL type in the case of a traffic light system is shown below.

CTL type: "Push button is lit"-> AF ("Pedestrian signal is blue")
Meaning: When the "push button lights up", it will always be "pedestrian signal is blue"
However AF = "Someday"

Definition (A) Φ :: = T | F | p | ¬Φ | Φ∨Φ | Φ∧Φ | Φ⇒Φ |
AXΦ | EXΦ | AGΦ | EGΦ | AFΦ | EFΦ | A (ΦUΦ) | E (ΦUΦ)
A (ΦWΦ) | E (ΦWΦ)
Where T: True
F: False
p: atomic term

(B) Atomic term
CTL expression without sub-logic expression (not syntactically decomposable)

(C) Logical operator
¬: not
∨: or
∧: and
⇒:
⇔: Equivalent

(D) Temporal operator
Path operators
A (All: True for all paths that branch from the current state.)
E (Exists: true on at least one of the routes that branch off from the current state)
State operators
X Φ (Next: Φ is true in the next state on the path.)
G Φ (Globally: Φ is always true in all states on the path)
F Φ (Finally: Φ becomes true at some point on the path)
Φ U Ψ (Until: Ψ is true at some point on the path, and Φ is always true until then)
Φ W Ψ (Weak until (unless): On the path (Φ U Ψ) ∨ ¬F (Ψ))

  In the following description, “operator” means a logical operator or a temporal operator.

  Below, some examples (OS task management functions) are shown to understand the definition of the CTL expression.

In the FSM of FIG. 2, a state that satisfies the following verification condition 1 (atomic term) is indicated by a bold circle in FIG.
p: = "Task1 ∈ RDY"
This means that task 1 is ready to run

Also, in the FSM of FIG. 2, an example of a state that satisfies the following verification condition 2 is as shown in FIG.
p ⇒ AF (q)
Where q: = "Task1 ∈ RUN"
This means that if task 1 is in an executable state, task 1 will be in an execution state at some point (sometime) on all routes.

Further, in the FSM of FIG. 2, an example of a state satisfying the following verification condition 3 is as shown in FIG.
p ⇒ A (p U q)
This means that if task 1 is waiting for execution,
Task 1 will be in an execution state at some point (always) on all routes.
In addition, task 1 is in an executable state until task 1 is in an execution state.

(4) A syntax tree is a CTL expression expressed in a tree structure by syntax analysis (see the left side of FIG. 8). The syntax tree includes a plurality of nodes and branches connecting the nodes. Leaf nodes are assigned T, F, or atomic terms, and nodes other than leaf nodes (non-leaf nodes) are assigned logical operators or temporal operators.

  The parent-child relationship between nodes expresses the operational relationship between each (partial) CTL expression in the CTL expression and the (logical / temporal) operator. As a result, the calculation order of the operators included in the original CTL expression is recognized as the order of tracing the nodes from the leaf node, which is the end of the syntax tree, toward the root node.

  The subtree having each node as a vertex represents a logical expression corresponding to each node. For leaf nodes, the T, F, or atomic term itself assigned to it is a logical expression.

  Hereinafter, embodiments of the present invention will be described in detail.

  FIG. 1 schematically shows a configuration of a system state inspection apparatus according to an embodiment of the present invention.

  This system state inspection device holds the FSM generated from the specifications of the system to be inspected in the relational database (RDB) 14 in advance, and searches the relational database from the verification condition (CTL expression) given from the outside ( SQL (Structured Query Language) statement) is generated, and a model check is performed by executing the generated search procedure (SQL statement) using the search function of the relational database 14. In this embodiment, the search procedure is described in SQL. However, it is sufficient that the search procedure is described in the relational database query language format and its procedural extension format, and the description language is not limited to SQL.

  The inspection target of this system state inspection apparatus is FSM, the input to the system state inspection apparatus is a verification condition (CTL type), and the output is a set of all states that satisfy the verification condition.

  In the following, the processing of this apparatus will be described, but before that, the FSM will be described in detail.

  As described above, FIG. 2 shows an example of FSM (when there are three tasks) based on the task management function of the OS. The FSM to be inspected is stored in advance in the RDB 14 of this apparatus.

  The FSM is formed from two tables, a “state table” (hereinafter “State”) and a “state transition table” (hereinafter “Trans”).

The state table records all FSM states. The state table has a “state identifier” (hereinafter referred to as “ID”) for identifying a state and “variable names” constituting the state as attributes. An example of a state table is shown below. The leftmost attribute “ID” is a state identifier, and other “RUN”, “RDY”, and “WAI” are variable names constituting the state. For example, the state 0 in the first line means RUN = {1}, RDY = {2, 3}, WAI = {}.

The state transition table records all state transitions of the FSM. The state transition table contains a “state transition identifier” (hereinafter “ID”) that identifies the state transition, a transition state identifier “transition source” (hereinafter “SRC”), and a transition destination state identifier “transition destination” (hereinafter “ DST ")," method "(hereinafter" FUN ") indicating the method (including the argument) that caused the state transition, and" return value "(hereinafter" RET ") indicating the return value of the method as attributes. An example of the state transition table is shown below. For example, the state transition 0 in the first line is a transition from the state 0 to the state 1 and is caused by the void type method “yield 1”.

  FIG. 6 is a flowchart showing the flow of overall processing by the system state inspection apparatus in FIG.

In process 1 (S101), the verification condition described in the CTL expression is acquired by the verification condition input means 11.
In process 2 (S102), the syntax analysis unit 12 analyzes the verification condition acquired by the verification condition input unit 11, and generates a syntax tree. When the verification condition “p⇒A (pUq)” (p and q are both atomic terms) is acquired, the generated syntax tree is as shown on the left side of FIG.
In process 3 (S103), a search procedure in the SQL format for verifying the verification condition is assembled based on the syntax tree generated by the syntax analysis unit 12. This processing is performed in the search procedure assembly means 13, the search sentence generation means 24 for the atomic term, the search sentence generation means 25 for the logical operator, and the search sentence generation means 26 for the temporal operator. The means 21 to 23 and 16 are not used in the first embodiment, but are used in other embodiments described later.
In process 4 (S104), the search procedure execution means 15 sequentially executes the generated search procedure (SQL format) using the relational database 14, and obtains a set of all states satisfying the verification condition as a search result.
In process 5 (S105), the inspection result output means 17 outputs the acquired inspection result (a search result table described later).

  Details of the process 3 (S103), which is a major feature of the first embodiment, will be described below.

  FIG. 7 is a flowchart showing a detailed flow of process 3 (S103) (assembly of search procedure) in FIG.

In process 3-1 (S201), the search procedure assembling means 13 creates a search plan using the syntax tree. Reads the nodes of the syntax tree from leaves to the root in order from the deepest node, and retrieves search processing information consisting of operators and argument information (child nodes of the syntax tree) for logical expressions corresponding to each node, Generate in the form of an ordered list (search plan). An example of a search plan is shown below.

The above search plan is described in tabular form. The table is composed of attributes of “SRCHID”, “logical expression”, “operator”, and “argument”. One search process is represented by one line, and the search process corresponding to SRCHID is executed in ascending order of search process ID (SRCHID) (upper part of the table).
“SRCHID” is a unique number for identifying each search process.
“Logical expression” represents a logical expression to be verified in the search process.
“Operator” represents the outermost operator included in the logical expression.
“Argument” represents SRCHID of a logical expression that is an argument of the operator. For example, search processing 2 (SRCHID2) on the third line relates to an operator AU that takes arguments p and q, and refers to the results of search processing 0 and 1 (SRCHID1, 2) as arguments. However, when the logical expression is an atomic term, the atomic term itself is described as an argument.

In process 3-2 (S202), the search procedure assembling means 13 deletes the search plan duplication process. In the search plan, the search processing information is read in order from the top, and the search processing (with the larger ID) with overlapping logical expressions is deleted. At the same time, the argument of the search process that used the deleted search process as an argument is replaced with the ID of the search process with a lower ID that overlaps with the deleted search process. This can be realized by using a general sorting algorithm. An example of a search plan after deleting duplicate processing is shown below. Since the logical expressions of SRCHID0 and 3 are duplicated, the higher-numbered SRCHID3 row is deleted.

  In process 3-3 (S203 to S211), the search procedure assembly means 13, the search sentence generation means 24 for the atomic term, the search sentence generation means 25 for the logical operator, and the search sentence generation means 26 for the temporal operator perform duplicate processing. Create a search procedure (SQL format) from the deleted search plan. In the search plan after deleting duplicate processing, the search processing information is read in order from the top, SQL statements are generated for each search processing information, and these SQL statements are arranged in the search plan order to generate a search procedure. The generated SQL sentence searches all states satisfying the logical expression specified by the search processing information, and outputs the searched state as a search result to the search result table.

More specifically, the search processing information is read in the search plan, and when the logical expression in the read search processing information is an atomic term (YES in S204), the search statement generation means 24 for the atomic term generates an SQL statement (processing 3- 3-1: S207), if it is a logical operator (YES in S205), the search statement generation means 25 for the logical operator generates an SQL statement (Process 3-3-2: S208), and if it is a temporal operator (YES in S206) The search statement generation means 26 relating to the temporal operator generates an SQL statement (processing 3-3-3: S209). A search procedure (SQL format) is created by arranging the SQL statements generated from each search processing information from the top in the generation order (processing 3-3-4: S210). The processing of S204 to S210 can be described as follows.

for (search processing information: search plan)
if (search process == atomic term)
Process 3-3-1: Search sentence generation for atomic terms
if else (search processing == logical operator)
Process 3-3-2: Search Statement Generation for Logical Operator
if else (search processing == temporal operator)
Process 3-3-3: Generating search statements for temporal operators
Process 3-3-4 Adds an SQL statement to the end of the search procedure.

  Details of processing 3-3-1 (S207), processing 3-2-2 (S208), and processing 3-3-3 (S209) will be described below.

In process 3-3-1 (S207), the search statement generation means 24 regarding the atomic term includes “atomic term” as the verification condition, “output destination information (represents“ SRCHID ”in the search result table of RDB 14)”, Is used as an input, and all states satisfying the atomic term are searched, and an SQL statement is generated to write the searched state as a search result in the search result table together with SRCHIID (search result ID). The search result table is prepared in the RDB 14 in advance. The search result ID or SRCHID in the search result table is, for example, the SRCHID assigned to the search processing information in the search plan. An SQL statement is generated according to the following generation rule. s.id represents the ID of the searched state.

Input Atomic term: p
Output destination information: OutID (SRCHID of search result table)
output:
### Start SQL statement ### * Replace p, OutID with the input value and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE p;
### SQL statement end ###

Here, the search result table (hereinafter sometimes referred to as “Result”) is a table that holds search results. “Result” has “search process ID” (“SRCHID”) for identifying each search process and “state identifier” (“STATE”, indicating the ID of State) of the search result as attributes. As a result of the search process, if multiple states are applicable, the number of rows corresponding to the number of states is added. For example, in the following Result, the search result of the search process “SRCHID = 0” is the state {0, 2, 3}.

In process 3-3-2 (S208), the search statement generation means 25 relating to the logical operator performs "reference source information (argument)" indicating the input of the logical operation and "output destination information" indicating the output destination of the logical operation result (Search result ID or SRCHID) "as input, search all the states satisfying the logical expression by the logical operator while referring to the referrer information, and use the searched state as the search result and SRCHIID (search result ID) Generate SQL statement to output to the search result table. The SQL statement is generated according to a generation rule determined for each logical operator type. Below, the production | generation rule is demonstrated. Φ and Ψ are logical expressions on which logical operators operate.

Logical operator 1: ¬Φ (negation)
input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID);
### SQL statement end ###


Logical operator 2: Φ∨Ψ (or)
input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID1)
OR
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID2);
### SQL statement end ###


Logical operator 3: Φ∧Ψ (and)
input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID1)
AND
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID2);
### SQL statement end ###


Logical operator 4: Φ⇒Ψ (if)
input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE
s.id NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID1)
OR
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID2);
### SQL statement end ###


Logical operator 5: Φ⇔Ψ (⇔)
input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE
(s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID1)
OR
s.id NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID2))
AND
(s.id NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID1)
AND
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID2))
### SQL statement end ###

  In process 3-3-3 (S209), the search statement generation means 26 relating to the temporal operator searches all states satisfying the logical expression by the temporal operator while referring to the reference source information (argument), An SQL statement is generated to output the searched state as a search result together with SRCHID (search result ID) to the search result table. Similarly to the logical operator, the temporal operator is generated according to a generation rule determined for each temporal operator type. Below, the production | generation rule is demonstrated. The rules for input and output are the same as the rules for logical operators.

However, note the following. Processing including calculation of fixed points (all except AX and EX) includes a search processing loop. There are several SQL-based procedure description systems, mainly PL / SQL. The following example is written in PL / SQL, but does not depend on it. Any system that can describe the end of a loop by a loop and a condition is acceptable.

Temporal operator 1: AXΦ
input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE
EXISTS (
SELECT * FROM Trans t
WHERE s.id = t.src
) AND (
NOT EXISTS (
SELECT * FROM Trans t
WHERE
s.id = t.src
AND
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID
)
);
### SQL statement end ###


Temporal operator 2: EXΦ
input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE EXISTS (
SELECT * FROM Trans t
WHERE
s.id = t.src
AND
t.dst IN (
SELECT r.state FROM Result r
WHERE r.srchid = InID)
);
### SQL statement end ###


Temporal operator 3: AGΦ (maximum fixed point)
input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID);

## Maximum fixed point calculation (Repeat until there is no state to be deleted)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Delete operation
DELETE FROM Result r
WHERE
r.srchid = OutID
AND
EXISTS (
SELECT * FROM Trans t
WHERE (
r.state = t.src
) AND (
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
);

# Size after deletion
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# End loop when size is same before and after deletion
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 4: EGΦ: Maximum fixed point input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID);

## Maximum fixed point calculation (Repeat until there is no state to be deleted)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Delete operation
DELETE FROM Result r
WHERE
r.srchid = OutID
AND
EXISTS (
SELECT * FROM Trans t
WHERE r.state = t.src
) AND (
NOT EXISTS (
SELECT * FROM Trans t
WHERE (
r.state = t.src
) AND (
t.dst in (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
)
)
);

# Size after deletion
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# End loop when size is same before and after deletion
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 5: AFΦ: Minimum fixed point input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID);

## Minimum fixed point calculation (Repeat until there are no additional states)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Add operation
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE (
EXISTS (
SELECT * FROM Trans t
WHERE s.id = t.src)
) AND (
NOT EXISTS (
SELECT * FROM Trans t
WHERE
s.id = t.src
AND
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 6: EFΦ: Minimum fixed point input
Reference source information: InID (corresponding to Φ)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID);

## Minimum fixed point calculation (Repeat until there are no additional states)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Add operation
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE EXISTS (
SELECT * FROM Trans t
WHERE (
t.src = s.id
) AND (
t.dst in (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 7: A (Φ U Ψ): Minimum fixed point input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID2);

## Minimum fixed point calculation (Repeat until there are no additional states)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Add operation
INSERT INTO Result
SELECT OutID, s.state FROM Result s
WHERE (
s.id = InID1
) AND (
EXISTS (
SELECT * FROM Trans t
WHERE s.id = t.src)
) AND (
NOT EXISTS (
SELECT * FROM Trans t
WHERE
s.id = t.src
AND
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 8: E (Φ U Ψ): Minimum fixed point input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID2);

## Minimum fixed point calculation (Repeat until there are no additional states)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Add operation
INSERT INTO Result
SELECT OutID, s.state FROM Result s
WHERE (
s.id = InID1
) AND (
EXISTS (
SELECT * FROM Trans t
WHERE (
t.src = s.state
) AND (
t.dst in (
SELECT r.state FROM Result r
WHERE r.srchid = OutID
)
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 9: A (Φ W Ψ): Maximum fixed point input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID1);

## Maximum fixed point calculation (Repeat until there is no state to be deleted)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Delete operation
DELETE FROM Result r
WHERE
r.srchid = OutID
AND
EXISTS (
SELECT * FROM Trans t
WHERE (
r.state = t.src
) AND (
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = OutID OR r.srchid = InID1
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###


Temporal operator 10: E (Φ W Ψ): Maximum fixed point input
Reference source information: InID1, InID2 (corresponding to Φ and Ψ, respectively)
Output destination information: OutID
output:
### Start SQL statement ### * Replace InID1, InID2, and OutID with input values and output.
INSERT INTO Result
SELECT OutID, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = InID1);

## Maximum fixed point calculation (Repeat until there is no state to be deleted)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = OutID;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Delete operation
DELETE FROM Result r
WHERE
r.srchid = OutID
AND
NOT EXISTS (
SELECT * FROM Trans t
WHERE (
r.state = t.src
) AND (
t.dst IN (
SELECT r.state FROM Result r
WHERE r.srchid = OutID OR r.srchid = InID1
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = OutID;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###
The details of the process 3 (S103) in FIG. 6 have been described above.

  Hereinafter, as a specific example, the processing flow of the first embodiment is shown assuming that the verification condition “p → A (pUq)” (p and q are both atomic terms) is given.

Step 1: Through the process 1 (S101) in FIG. 6, the following is acquired as the verification condition (CTL expression).
Verification condition "p⇒A (pUq)" (p and q are both atomic terms)

Step2: By processing 2 (S102) in FIG. 6, the verification condition is analyzed and a syntax tree is generated. Here, the syntax tree shown on the left side of FIG. 8 is generated.

Hereinafter, the search procedure is assembled by processing 3 (S103) in FIG.

Step3: When a search plan is created by process 3-1 (S201 in FIG. 7), it is as follows.

Step4: When duplicate processing in the search plan is deleted by processing 3-2 (S202 in FIG. 7), the result is as follows. The third line in the search plan obtained in process 3-1 (S201) is deleted.

  Hereinafter, a search procedure is created by the process 3-3 (S203 to S211 in FIG. 7) using the search plan after deleting the duplicate process obtained in Step 4. The right side of FIG. 8 shows the correspondence between the syntax tree and the search procedure (SQL procedure) generated in this process 3-3. Details of this process 3-3 will be described below.

Step 5: A search sentence related to the atomic term p is generated by the process 3-3-1 (S207 in FIG. 7). The output destination information is “SRCHID 0”. The generated search statement (SQL procedure 1) is shown below.
### Start SQL statement ###
INSERT INTO Result
SELECT 0, s.id FROM State s
WHERE p;
### SQL statement end ###

Step 6: A search sentence related to the atomic term q is generated by the process 3-3-1 (S207 in FIG. 7). The output destination information is “SRCHID 1”. The generated search statement (SQL procedure 2) is shown below.
### Start SQL statement ###
INSERT INTO Result
SELECT 1, s.id FROM State s
WHERE q;
### SQL statement end ###

Step 7: A search sentence related to the temporal operator AU is generated by processing 3-3-3 (S209 in FIG. 7). The output destination information is “SRCHID 2”. The generated search statement (SQL procedure 3) is shown below.
### Start SQL statement ###
INSERT INTO Result
SELECT 2, s.id FROM State s
WHERE s.id in (
SELECT r.state FROM Result r
WHERE r.srchid = 1);

## Minimum fixed point calculation (Repeat until there are no additional states)
# Current size
size = SELECT COUNT (*) FROM Result WHERE id = 2;
# Previous size
size_prev;

LOOP # Loop start
# Assign to previous size
size_prev = size;

# Add operation
INSERT INTO Result
SELECT 2, s.state FROM Result s
WHERE (
s.id = 0
) AND (
EXISTS (
SELECT * FROM Trans t
WHERE s.id = t.src)
) AND (
NOT EXISTS (
SELECT * FROM Trans t
WHERE
s.id = t.src
AND
t.dst NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = 2
)
)
);

# Size after addition
size = SELECT COUNT (*) FROM Result WHERE id = 2;

# Loop end when size is the same before and after addition
EXIT WHEN size == size_prev;

# End loop
END LOOP;
### SQL statement end ###

Step 8: Generate a search sentence related to the logical operator ⇒ by processing 3-3-2 (S208 in FIG. 7). The output destination information is “SRCHID 4”. The generated search statement (SQL procedure 4) is shown below.
### Start SQL statement ###
INSERT INTO Result
SELECT 4, s.id FROM State s
WHERE
s.id NOT IN (
SELECT r.state FROM Result r
WHERE r.srchid = 0)
OR
s.id IN (
SELECT r.state FROM Result r
WHERE r.srchid = 2);
### SQL statement end ###

Step 9: A search result table is acquired by sequentially executing the search procedure generated in process 3 (S103 in FIG. 6) in the relational database 14 by process 4 (S104 in FIG. 6). The obtained search result table is shown below.

Step 10: A search result table is output by processing 5 (S105 in FIG. 6). Since the conditions satisfying the verification condition include all the states of the FSM (state 0-15), it can be seen that the system satisfies the verification condition.

  In the description so far, the example in which the process of obtaining the search result table from the syntax tree (process 3 and process 4 in FIG. 6) is implemented by the multipath method has been shown. That is, in Example 1, after all SQL statements of each node in the syntax tree are generated, the generated SQL statements are sequentially executed. On the other hand, it is also possible to perform a one-pass method in which search procedure generation (SQL statement generation) and search processing (SQL statement execution) are repeated for each node of the syntax tree. It is not the essence of the present invention whether the multi-path method or the one-pass method is used, and the present invention can be implemented by any method.

  As described above, according to the first embodiment, the verification condition is expressed by a tree structure, a search sentence of each node is generated, and each search sentence is sequentially transmitted from the leaf node to the root node using the relational database. By performing the search, system verification with excellent verification performance is possible. In other words, relational databases that have a long track record in the industry have excellent search performance and reliability. By using such relational databases, it is expected to improve verification performance and scalability related to the scale of the verification target.

In the second embodiment, the search history can be held and searched in the relational database 14, and the equivalent logical expression (first equivalent expression) is generated as a rewrite candidate for the logical expression included in the verification condition. Alternatively, an equivalent logical expression (first equivalent expression) of the logical expression and a negative equivalent logical expression (second equivalent expression) of the logical expression are generated as rewrite candidates. If any of the logical expressions and their rewrite candidates has already been searched in the past, the search results for the logical expressions can be omitted by reusing the past search processing results. The speed can be increased. Hereinafter, the second embodiment will be described in detail.
The relational database (RDB) 14 in the second embodiment has a “search history table” (hereinafter “History”) in addition to the state table, state transition table, and search result table in the first embodiment.

History has “SRCHID” and “FORMULA” as attributes, and holds the search history (including search processing in the middle stage on the syntax tree) executed so far in the RDB 14. SRCHID is an identifier for search processing and is the same as SRCHID of Result. FORMULA represents a logical expression that is a source of search processing corresponding to SRCHID. That is, in the History, a logical expression that has been searched in the past and its SRCHID are stored. An example of History is shown below. For example, the logical expression that is the basis of the search process “SRCHID = 4” is “E (¬q W ¬q)”.

  FIG. 9 is a flowchart showing the overall processing flow according to the second embodiment.

  Most of the processing of the second embodiment is the same as that of the first embodiment. The second embodiment is different from the first embodiment in that “analysis of search history” and “generation of logical expression rewriting candidates” are additionally executed in process 3 (S303), and after process 4 (S304). In the added process 5 (S305), “save search history” is performed. Processing 1 (S301), processing 2 (S302), processing 4 (S304), and processing 6 (S306) are processing 1 (S101), processing 2 (S102), processing 4 (S104), and processing 5 (S105) in FIG. ).

First, “save search history” performed in process 5 (S305) will be described. In process 4 (S304), the search history storage unit 16 in FIG. 1 uses the identifier (SRCHID) of the search procedure (SQL format) executed by the search procedure execution unit 15 and the logical expression corresponding to the search procedure. Is stored in the History of the relational database 14.
“Save search history” is a relational database that can be incorporated as a subroutine of process 4 (S304) so that the history is saved at least every time one search procedure is executed. 14 may be used, but either of these methods may be used.

  Next, the assembly of the search procedure performed in process 3 (S303) will be described.

  FIG. 10 is a flowchart showing the flow of the search procedure assembly process performed in process 3 (S303). The difference from the first embodiment (FIG. 7) is that the process 3-0 (S212) is added to the head before the process 3-1 (S201). Therefore, in the following, description will be given focusing on this difference point. The other processing 3-1, processing 3-2, and processing 3-3 are the same as those in the first embodiment, and thus redundant description is omitted.

  FIG. 11 is a flowchart showing a flow of reusability reflection processing performed in processing 3-0 (S212).

  The search procedure assembling means 13 sequentially reads the nodes of the syntax tree from the root to the leaves (S401), and analyzes whether the logical expressions corresponding to the respective nodes have already been searched using the search history analysis means 22 (S401). Process 3-0-0: S402).

  In process 3-0-0 (S402), the search history analysis means 22 receives a logical expression and analyzes the presence / absence of the logical expression in the search history. Specifically, the input logical expression is searched by FORMULA of History of RDB14. If the history already exists (when the corresponding line is found in the History), the corresponding SRCHID (SRCHID of Result) is acquired.

  If the logical expression has been searched in the past (YES in S403), the part of the syntax tree that is a descendant of the corresponding node is deleted (processing 3-0-1: S404), and the search that has already been performed for the corresponding node The node to be referred to is updated (processing 3-0-2: S405) (see FIG. 12 described later). If the loop end condition “no node to be scanned” is satisfied, the process ends. If not, the process returns to S401.

  On the other hand, when the logical expression has not been searched in the past (NO in S403), it is determined whether or not the logical expression is an operator. When it is not an operator (NO in S406), that is, when it is an atomic term, the process proceeds to S410. If the loop end condition “no node to be scanned” is satisfied, the process ends. If not, the process returns to S401. On the other hand, when the logical expression is an operator (YES in S406), the retrieval procedure assembling means 13 uses the logical expression rewrite candidate generating means (logical expression generating means) 21 to generate a logical expression rewriting candidate ( Process 3-0-3: S407).

  In this process 3-0-3 (S407), the logical expression rewrite candidate generation means 21 receives a logical expression (here, excluding the atomic term), and from the input logical expression, a rewrite rule based on Domorgan's law. Are used to generate an equivalent logical expression (first equivalent expression) and a negative equivalent logical expression (second equivalent expression). The negative equivalent logical expression (second equivalent expression) may be generated only when the operator is different from the negative operator. The details of the rewrite rules are described in “Supplementary explanation 2: Equivalent rewrite rules for logical operations” at the end of the book. Please refer here.

  In process 3-0-4 (S408), the search history analysis means 22 is used to analyze whether the equivalent logical expression or the negative equivalent logical expression has already been searched in the past.

  If there is an equivalent logical expression that has already been searched or a negative equivalent logical expression (YES in S409), the syntax tree is updated so as to refer to the search result that has already been performed for the node (processing 3-0-1). : S404, Process 3-0-2: S405) (see FIG. 12 described later). The method of updating the syntax tree differs depending on whether an equivalent logical expression or a negative equivalent logical expression has been searched, and details thereof will be described later. If the loop end condition “no node to be scanned” is satisfied, the process ends. If not, the process returns to S401.

The processing of S401 to S10 described above can be described as follows.
loop (node <scan all nodes from top of syntax tree to leaf) {
Process 3-0-0: Analyze search history
if (if the node's logical expression has already been searched) {
Process 3-0-1: Delete all descendants on syntax tree
Process 3-0-2: Replace node logical expression with reference to "SRCHID" found in process 3-0-0
exit loop
} else {
if (node == operator) {
Process 3-0-3: Generate equivalent logical expression
Process 3-0-4: Analyze search history (with respect to generated formula)
if (if a generated logical expression already exists) {
Process 3-0-5: Delete all descendants on the syntax tree
Process 3-0-6: Replace node logical expression with reference to "SRCHID" found in process 3-0-0
exit loop
}
}
}
}

Hereinafter, as a specific example, as in the first embodiment, assuming that a verification condition “p⇒A (pUq)” (p and q are both atomic terms) is given, the operation according to the second embodiment ( In particular, treatment 3-0) is shown. The operation of the second embodiment differs depending on the state of the inspection result accumulated in the history. Here, the following two cases are given.
Case 1: A (pUq) has already been searched Case 2: E (¬pW¬q) has already been searched (A (pUq) is not searched)
In the following description, for convenience, SRCHIDs related to A (pUq) and E (¬pW¬q) are both “xx”.

Case 1: A (pUq) has been searched
Step 1: Processing 1 (S301) and processing 2 (S302) in FIG. 9 are the same as those in the first embodiment, and thus description thereof is omitted.
In the following, the search procedure is assembled in process 3 (S303).
Step 2: The search history is analyzed in process 3-0-0 (S402 in FIG. 11) in process 3-0 (S212: reflection of reusability) in FIG. Since “A (pUq)” has already been searched, SRCHIDxx is output (see the left side of FIG. 12).
Step3: In process 3-0-1 (S404) in Fig. 11, all descendants of the node corresponding to "A (pUq)" in the syntax tree are deleted (see right side of Fig. 12).
Step 4: In step 3-0-2 (S405) in FIG. 11, the node logical expression is replaced so as to refer to the search result (SRCHIDxx) in Step 3 (see the right side in FIG. 12).
Step 5: Since the process 3-1 (S201) and subsequent steps in FIG. 10 are the same as those in the first embodiment, description thereof is omitted.

Case 2: E (¬pW¬q) has been searched
Step 1: Processing 1 (S301) and processing 2 (S302) in FIG. 9 are the same as those in the first embodiment, and thus description thereof is omitted.
In the following, the search procedure is assembled in process 3 (S303).
Step 2: The search history is analyzed in process 3-0-0 (S402 in FIG. 11) in process 3-0 (S212: reflection of reusability) in FIG. Under the above assumption, it is found that “A (pUq)” is not searched.
Step3: In process 3-0-3 (S407) of FIG. 11, ¬E (¬pW¬q) is generated as an equivalent logical expression (first equivalent expression) of the logical expression, and the logical expression is negated. E (¬pW¬q) is generated as an equivalent logical expression (second equivalent expression) (see the right side of FIG. 13).
Step 4: When the search history is analyzed with respect to the generated logical expression in the process 3-0-4 (S408) in FIG. 11, “¬E (¬pW¬q)” has not been searched, but “E (¬pW¬ Since q) "has been searched, SRCHIDxx is output.
Step 5: In process 3-0-1 (S404) of FIG. 11, all descendants of the node corresponding to “A (pUq)” in the syntax tree are deleted, and the node is changed to “¬E (¬pW¬q)” Replace and add a node of “E (¬pW¬q)” as a child node of the node. If “¬E (¬pW¬q)” has already been searched, it is not necessary to add a child node.
Step 6: In the process 3-0-2 (S405) of FIG. 11, the node logical expression “E (¬pW¬q)” is replaced to refer to the search result (SRCHIDxx) of Step 4 (see the right side of FIG. 12) ).
Step 7: Since processing 3-1 (S201) and subsequent steps in FIG. 10 are the same as those in the first embodiment, description thereof is omitted.

  As described above, according to the present embodiment, it is possible to further improve performance by reusing past search results as much as possible.

  In the third embodiment, when neither the logical expression nor its rewriting candidate has been searched in the second embodiment (see S409 in FIG. 14), the processing cost of the logical expression and the rewriting candidate is set to the number of states satisfying those partial logical expressions. Analyze based on (size). The number of states satisfying the partial logical expression is acquired using the search history table and the search result table. When the partial logical expression has not been searched, a syntax tree having the partial logical expression as the root is generated, recursively processed, and thereafter this is repeated. As a result, the number of states (size) satisfying the logical expression and the partial logical expression of the rewrite candidate is obtained, and the processing cost of the logical expression and the rewrite candidate is calculated. Then, a logical expression or a rewriting candidate that minimizes the processing cost is selected and the syntax tree is updated. Hereinafter, the third embodiment will be described in detail.

  In the third embodiment, the search processing cost analysis means 23 of FIG. 1 is used. Similar to the second embodiment, the relational database has a search history table in addition to the state table, the state transition table, and the search result table.

Hereinafter, the flow of processing according to the third embodiment will be described.
Most of the processing in the third embodiment is the same as that in the second embodiment, and is different from the second embodiment in that “processing cost analysis” is additionally performed in the processing 3-0 (S212) of FIG. Therefore, the processing 3-0 will be described here focusing on the difference from the second embodiment.

  FIG. 14 is a flowchart illustrating a detailed flow of the process 3-0 according to the third embodiment. The hatched steps (S411 to S417) correspond to differences from the second embodiment. The process of step S414 corresponds to the process of the recursive control means. The processing of this flowchart can be described in detail as follows.

  Note that the processing of the present embodiment is performed only in the case of a temporal operator in step S411. In the case of a logical operator, even if rewriting is performed, the difference in processing cost is very small, and the difference in the amount of computation is very small. This is because there is no difference. On the other hand, in the case of a temporal operator, since there is an iterative process, there may be a large difference in the amount of calculation by rewriting.

In the description of the processing below, the syntax tree of the partial logical expression performed in step S414 may be generated using the syntax analysis unit 12, or may be generated using a part of the generated syntax tree. Good.

Process 3-0: Reflection of reusability <<"★" is the difference from Example 2 >>
loop (node <scan all nodes from top of syntax tree to leaf) {
Process 3-0-0: Analyze search history
if (if the node's logical expression has already been searched) {
Process 3-0-1: Delete all descendants on syntax tree
Process 3-0-2: Replace node logical expression with reference to "SRCHID" found in process 3-0-0
exit loop
} else {
if (node == operator) {
Process 3-0-3: Generate equivalent logical expression
Process 3-0-4: Analyze search history (with respect to generated formula)
if (if a generated logical expression already exists) {
Process 3-0-5: Delete all descendants on the syntax tree
Process 3-0-6: Replace node logical expression with reference to "SRCHID" found in process 3-0-0
exit loop
}

★ else {
★ if (node == temporal operator) {
★ Process 3-0-7: Analyzing the search history (of the sub-expression of the target node's logical expression) ★ if (if the logical expression has not been searched) {
★ Process 3-0-8: Search for partial logical expression ★}
★ Process 3-0-9: Use RDB Result to calculate the size of the set that satisfies the partial logical expression ★ Process 3-0-10: Type of temporal operator and input logical expression (partial logical expression ) To analyze the processing cost based on the size of the set to be searched. (Search processing cost analysis)
Process 3-0-11: Rewrites the target node to a rewrite candidate with the lowest processing cost among all rewrite candidates.
★ exit loop
★}
★}
}
}
}

Processing 3-0-8
Input: syntax tree (syntax tree rooted in sub-expression)
Output: SRCHID referring to the search result of the sub-expression
Side effects: RDB Result, History
Process Description: Recursively calls process 3-0, process 4 and process 5 in FIG. As a result, the partial logical expression search result is stored in the RDB Result, and an SRCHID that refers to it is returned.

Processing 3-0-10 (Search processing cost analysis)
Input: Temporal operator, the size of the satisfaction set of the logical expression (partial logical expression) that is input to the operator
Output: Processing cost
Person in charge: "Search processing cost analysis"
Process Description: Analyzes the processing cost based on the size of the search target set. Refer to “Supplementary explanation 1: Calculation method of temporal operator” at the end of the book for the calculation rules.

  Hereinafter, as a specific example, the operation of the third embodiment (particularly, assuming that the verification condition “p => A (pUq)” (p and q are both atomic terms) is given in the same manner as the first embodiment (particularly, Processing 3-0) will be described.

Similar to the second embodiment, the behavior of this apparatus differs depending on the FSM, verification conditions, and history (verification history) accumulation status. In this specific example, the following is assumed for FSM, verification conditions, and verification history.

FSM (inspection target)
Number of states: 16
Number of state transitions: 42
Verification history
"A (pUq)": not tested
"E (¬p W ¬q)": not tested
"p", "q": both tested
"¬p", "¬q": both tested

Step 1: Processing 1 (S301) and processing 2 (S302) in FIG. 9 are the same as those in the first embodiment, and thus description thereof is omitted.

  In the following, the search procedure is assembled in process 3 (S303).

Step2: Processing 3-0-0 (S402), 3-0-3 (S407), 3-0-4 (S408) in Fig. 14 in processing 3-0 (S212: Reflecting reusability) in Fig. 10 Since this is the same as that of the second embodiment, description thereof is omitted.

Step3: In the process 3-0-7 (S412) in Fig. 14, the search history of the partial logical expression is analyzed.

  Based on the above assumption, since the partial logical expressions “¬p” and “¬q” of “E (¬pW¬q)” have already been examined, these partial logical expressions are acquired. In addition, since “p” and “q”, which are partial logical expressions of “A (pUq)”, have already been checked, these partial logical expressions are acquired.

Step 4: In process 3-0-9 (S415) of FIG. 14, the set size of the partial logical expression is calculated.

  When the sizes of the partial logical expressions “¬p” and “¬q” are calculated based on, for example, Result, it is assumed that the number of “¬p” is one and the number of “¬q” is four. Further, when the sizes of the partial logical expressions “p” and “q” are calculated based on, for example, Result, it is assumed that “p” is 15 and “¬q” is 12. Note that (the number of states in "¬p") is equal to the total number of states-(the number of states satisfying p), and (the number of states in "¬q") is the number of states in total-(a state satisfying q Number).

Step 5: In process 3-0-10 (S416) of FIG. 14, the search processing cost is analyzed. The costs of “A (pUq)” and “E (¬p W ¬q)” are calculated as follows.

A (pUq): 7560 (= number of states satisfying p (= 15) * number of state transitions (= 42) * number of states satisfying q (= 12)
E (¬p W ¬q): 210 (= number of states satisfying ¬p (= 1) * number of state transitions (= 42) * [number of states satisfying ¬p + number of states satisfying ¬q] ( = 5))

  The two costs are compared, and it is determined that the processing cost of “E (¬p W ¬q)” is smaller. Note that the processing cost of "¬E (¬p W ¬q)" may be obtained and the processing costs of "¬E (¬p W ¬q)" and "A (pUq)" may be compared. Since the amount of computation of the operator (here "¬") is very small compared to the amount of computation of the temporal operator, it is practically sufficient to compare it with the processing cost of "E (¬p W ¬q)" is there. For this reason, in the present embodiment, a comparison is made with the processing cost of “E (¬p W ¬q)”.

Step 6: In the process 3-0-11 (S417) in FIG. 14, the node logical expression is replaced so as to refer to the one having the lowest processing cost (see the right side in FIG. 15). The details of the replacement method are as described in the second embodiment.

Step 7: Since processing 3-1 (S201) and subsequent steps in FIG. 10 are the same as those in the first embodiment, description thereof is omitted.
As described above, according to the present embodiment, by using a search result acquired in the past and rewriting a logical expression that minimizes the processing cost, verification with better performance characteristics can be performed. It can be carried out.

  Note that the system state verification apparatus according to the embodiment of the present invention described above can also be realized by using, for example, a general-purpose computer apparatus as basic hardware. That is, the units 11 to 17 and 21 to 26 in the system state verification apparatus in FIG. 1 can be realized by causing a processor mounted on the computer apparatus to execute a program. At this time, the verification apparatus may be realized by installing the above program in a computer device in advance, or may be stored in a storage medium such as a CD-ROM or distributed through the network. The program may be implemented by appropriately installing it in a computer device.

[Supplementary explanation 1: Temporal operator calculation method]
The mathematical calculation method of the temporal operator and the fixed point calculation cost are explained.
○ Symbol definition
State: State set
Trans: State transition set
s: State (∈State)
t: State transition (∈Trans)
t.src: Transition source of state transition t
t.dst: Transition destination of state transition t Φ, Ψ: CTL expression
"s | = Φ": CTL formula Φ is true in state s
#S: Size of set S (number of elements)


○ AX Φ
Mathematical definition
S: = {s ∈ State | ∀t (∈ Trans, t.src = s) t.dst | = Φ}


○ EX Φ
Mathematical definition
S: = {s ∈ State | ∃t (∈ Trans, t.src = s) ST t.dst | = Φ}


○ AG Φ (Maximum fixed point)
Mathematical definition
# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = All states of the set Sn that reach all the transitions to the set Sn.
Sn + 1: = {s ∈ Sn | ∀t (∈ Trans, t.src = s) t.dst ∈ Sn}
* Sn: A set of states where any state within n steps on any path satisfies Φ (monotonically decreasing)

# Maximum fixed point calculation
S: = ∩Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: # Sn-1 * #Trans * # Sn-1
=> Cost formula: (# S0) ^ 2 * #Trans


○ EG Φ (Maximum fixed point)
Mathematical definition
# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = all states of set Sn with or without transition to set Sn
Sn + 1: = (s ∈ Sn | (∃t (∈ Trans) ST (t.src = s ∧ t.dst ∈ Sn)) ∨ (¬∃t (∈ Trans) ST t.src = s)}
* Sn: A set of states where any state within n steps satisfies Φ in a path. (Monotonic decrease)

# Maximum fixed point calculation
S: = ∩Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #Sn * ((#Trans * #Sn) + #Trans)
=> Cost formula: # S0 * #Trans * (# S0 + 1)


○ AF Φ (Minimum fixed point)
Mathematical definition
# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = set of states reflected in Sn at any transition, or all states of set Sn
Sn + 1: = {s ∈ State | ∀t (∈ Trans, t.src = s) t.dst ∈ Sn} ∪ Sn
* Sn: A set of states that satisfy Φ within n steps in an arbitrary path (monotonically increasing)

# Minimum fixed point calculation
S: = ∪Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #State * #Trans * #Sn
=> Cost formula: #State * #Trans * # S0


○ EF Φ (Minimum fixed point)
Mathematical definition
# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = set of states reflected in Sn at a certain transition, all states of set Sn
Sn + 1: = {s ∈ State | ∃t (∈ Trans, t.src = s) t.dst ∈ Sn} ∪ Sn
* Sn: A set of states that satisfy Φ within n steps in a pass (monotonically increasing)

# Minimum fixed point calculation
S: = ∪Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #State * #Trans * #Sn
=> Cost formula: #State * #Trans * # S0


○ A (Φ U Ψ): Minimum fixed point mathematical definition
T: = {s ∈ State | s | = Φ}

# Set S0: = all states satisfying logical expression Ψ
S0: = {s ∈ State | s | = Ψ}

# Set Sn + 1: = Elements of T reaching Sn by any transition, or all elements of Sn.
Sn + 1: = {s ∈ T | ∀t (∈ Trans, t.src = s) t.dst ∈ Sn} ∪ Sn
* Sn: A set of states that satisfy Φ within n steps in a pass (monotonically increasing)

# Minimum fixed point calculation
S: = ∪Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #T * #Trans * #Sn
=> Cost formula: #T * #Trans * # S0


○ E (Φ U Ψ): Minimum fixed point mathematical definition
T: = {s ∈ State | s | = Φ}

# Set S0: = all states satisfying logical expression Ψ
S0: = {s ∈ State | s | = Ψ}

# Set Sn + 1: = T elements that reach Sn in a certain transition, or all elements of Sn.
Sn + 1: = {s ∈ T | ∃t (∈ Trans, t.src = s) t.dst ∈ Sn} ∪ Sn
* Sn: A set in which Ψ holds within n steps and Φ holds until then (monotonically increasing)

# Minimum fixed point calculation
S: = ∪Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #T * #Trans * #Sn
=> Cost formula: #T * #Trans * # S0


○ A (Φ W Ψ): Maximum fixed point mathematical definition
T: = {s ∈ State | s | = Ψ}

# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = An element of Sn that reaches Sn or T at any transition.
Sn + 1: = {s ∈ Sn | ∀t (∈ Trans, t.src = s) (t.dst ∈ Sn) or (t.dst ∈ T)}
* Sn: Within n steps in any pass,
Ψ holds, until then Φ holds or
Ψ does not hold and Φ holds in all states
State set. (Monotonic decrease)

# Maximum fixed point calculation
S: = ∩Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #Sn * #Trans * (#Sn + #T)
=> Cost formula: # S0 * #Trans * (# S0 + #T)


○ E (Φ W Ψ): Maximum fixed point mathematical definition
T: = {s ∈ State | s | = Ψ}

# Set S0: = all states satisfying the logical expression Φ
S0: = {s ∈ State | s | = Φ}

# Set Sn + 1: = An element of Sn that reaches Sn or T in a certain transition.
Sn + 1: = {s ∈ Sn | ∃t (∈ Trans, t.src = s) (t.dst ∈ Sn) or (t.dst ∈ T)}
* Sn: Within n steps in a pass,
Ψ holds, until then Φ holds or
Ψ does not hold and Φ holds in all states
State set. (Monotonic decrease)

# Maximum fixed point calculation
S: = ∩Sn (n is all natural numbers)

Processing cost (size of search target)
For Sn: #Sn * #Trans * (#Sn + #T)
=> Cost formula: # S0 * #Trans * (# S0 + #T)

[Supplementary explanation 2: Equivalent rewriting rules for logical operations]
○ Equivalent relation of time phase calculation
AFΦ = ¬EG¬Φ
EFΦ = ¬AG¬Φ
AXΦ = ¬EX¬Φ

A (Φ U Ψ) = ¬E (Φ V Ψ)
E (Φ U Ψ) = ¬A (Φ V Ψ)

○ Temporal operation rewrite rules * Rewrite candidates are templates for logical expressions that are searched by "search history analysis means". There are generally two candidates, including negation. The rewrite rule written on the right side is a replacement rule when replacing the original logical expression with the rewrite candidate while maintaining equivalence.

Next
AX
=> Rewrite candidate: ¬EX¬ (Rewrite rule "¬EX¬")
=> Rewrite candidate: EX¬ (Rewrite rule "¬EX¬")
EX
=> Rewrite candidate: ¬AX¬ (Rewrite rule "¬AX¬")
=> Rewrite candidate: AX¬ (Rewrite rule "¬AX¬")

Finally
AF
=> Rewrite candidate: ¬EG¬ (Rewrite rule "¬EG¬")
=> Rewrite candidate: EG¬ (Rewrite rule "¬EG¬")

EF
=> Rewrite candidate: ¬AG¬ (Rewrite rule "¬AG¬")
=> Rewrite candidate: AG¬ (Rewrite rule "¬AG¬")

Globally
AG
=> Rewrite candidate: ¬EF¬ (Rewrite rule "¬EF¬")
=> Rewrite candidate: EF¬ (Rewrite rule "¬EF¬")

EG
=> Rewrite candidate: ¬AF¬ (Rewrite rule "¬AF¬")
=> Rewrite candidate: AF¬ (Rewrite rule "¬AF¬")

Until
A (Φ U Ψ)
=> Rewrite candidate: ¬E (¬Φ W ¬Ψ) (Rewrite rule "¬E (¬Φ W ¬Ψ)")
=> Rewrite candidate: E (¬Φ W ¬Ψ) (Rewrite rule "¬E (¬Φ W ¬Ψ)")

E (Φ U Ψ)
=> Rewrite candidate: ¬A (¬Φ W ¬Ψ) (Rewrite rule "¬A (¬Φ W ¬Ψ)")
=> Rewrite candidate: A (¬Φ W ¬Ψ) (Rewrite rule "¬A (¬Φ W ¬Ψ)")

Weak Until
A (Φ W Ψ)
=> Rewrite candidate: ¬E (¬Φ U ¬Ψ) (Rewrite rule "¬E (¬Φ U ¬Ψ)")
=> Rewrite candidate: E (¬Φ U ¬Ψ) (Rewrite rule "¬E (¬Φ U ¬Ψ)")

E (Φ W Ψ)
=> Rewrite candidate: ¬A (¬Φ U ¬Ψ) (Rewrite rule "¬A (¬Φ U ¬Ψ)")
=> Rewrite candidate: A (¬Φ U ¬Ψ) (Rewrite rule "¬A (¬Φ U ¬Ψ)")

1 is a block diagram of a system state verification device as one embodiment of the present invention. The figure which shows an example of FSM. FIG. 5 is a diagram showing an example of a state that satisfies verification condition 1; FIG. 6 is a diagram showing an example of a state that satisfies verification condition 2. FIG. 6 is a diagram showing an example of a state that satisfies verification condition 3. 3 is a flowchart showing the overall processing flow of the first embodiment. 3 is a flowchart showing a flow of assembly processing of a search procedure according to the first embodiment. FIG. 3 is a diagram illustrating a specific example of the first embodiment. 9 is a flowchart showing the overall processing flow in Embodiment 2. 9 is a flowchart illustrating a flow of search procedure assembly processing according to the second embodiment. 9 is a flowchart illustrating a flow of reusability reflection processing according to the second embodiment. FIG. 6 is a diagram illustrating a specific example of the second embodiment. FIG. 6 is a diagram illustrating another specific example of the second embodiment. 10 is a flowchart illustrating a flow of reusability reflection processing according to the third embodiment. FIG. 6 is a diagram illustrating a specific example of Example 3.

Explanation of symbols

11: Verification condition input means 12: Syntax analysis means 13: Search procedure assembly means 14: Relational database (first and second relational databases)
15: search procedure execution means 16: search history storage means 17: inspection result output means 21: logical expression rewrite candidate generation means 22: search history analysis means 23: search processing cost analysis means 24: search sentence generation means 25 for atomic terms : Retrieval sentence generation means 26 relating to logical operators 26: Retrieval sentence generation means relating to temporal operators

Claims (11)

A first relational database storing a state transition model expressing transitions between a plurality of states;
A verification condition accepting means for accepting an input of a verification condition of the state transition model described by a computational tree logic (CTL) expression;
By analyzing the verification condition input to the verification condition receiving unit, a syntax tree including a plurality of nodes each associated with a logical expression is generated, and the logical expression of the parent node is a logical expression corresponding to the child node. A parser means defined based on an expression and an operator assigned to the parent node;
A search statement for searching for a state satisfying a logical expression corresponding to each node of the syntax tree is set such that the search statement of the parent node uses an output of a logical expression corresponding to the child node of the parent node as an argument. A search statement generation means for generating;
By executing each search statement generated by the search statement generation means with respect to the first relational database in the order of nodes in the hierarchy from the leaf node to the root node in the syntax tree, Search execution means for acquiring the corresponding states as search results,
Search result output means for outputting a search result corresponding to at least a root node of the syntax tree;
Verification device with A second relational database for storing a search result for each of the search sentences in association with a logical expression corresponding to each of the search sentences or an identifier of the logical expression;
The search sentence generation means
Read the nodes of the syntax tree from the root to the leaves in order of shallowness, and check whether the target logical expression corresponding to the read node or its identifier is stored in the second relational database,
When stored, delete the descendants of the read node, update the target logical expression corresponding to the read node to a reference to the search result associated with the target logical expression,
The search execution unit acquires the search result by referring to the second relational database for the node updated to the reference to the search result.
The verification apparatus according to claim 1. A logical expression generation means for generating a first equivalent expression of the logical expression and a negative second equivalent expression of the logical expression by rewriting the logical expression by a rewriting rule based on Domorgan's law;
When the target logical expression or its identifier is not stored (1) when the first equivalent expression of the target logical expression is stored in the second relational database, the search sentence generation means reads Deleting a descendant of the node and replacing the target logical expression with a reference to the search result of the first equivalent expression of the target logical expression;
(2) When the first equivalent expression of the target logical expression is not stored and the second equivalent expression of the target logical expression is stored, the descendants of the read node are deleted, and the read node Replacing the target logical expression corresponding to the first equivalent expression and adding a second node indicating a reference to the search result of the second equivalent expression of the target logical expression as a child of the read node;
The verification apparatus according to claim 2.   The verification device according to claim 3, wherein the search sentence generation unit performs the process (2) only when an operator assigned to the read node is different from a negation operator. Further comprising recursive control means,
When the search sentence generation means does not satisfy any of the conditions (1) and (2),
It is checked whether or not a partial logical expression included in the target logical expression is stored in the second relational database. When the partial logical expression is stored, the partial logical expression is referred to by referring to a search result corresponding to the partial logical expression. Obtain the number of states that satisfy the expression, calculate the processing cost of the target logical expression based on the operator assigned to the read node and the obtained number of states,
For the first equivalent expression or the second equivalent expression, when the partial logical expression is stored in the second relational database, the processing cost is calculated in the same manner as the target logical expression,
When the processing cost of the first equivalent expression or the second equivalent expression is smaller than the processing cost of the target logical expression, the syntax tree is updated in the same manner as (1) or (2),
The recursive control unit is configured to select a second target logical formula for which a processing cost is not calculated because the target logical formula, the first equivalent formula, and the second equivalent formula are not stored in the second relational database. Acquires a syntax tree in which a partial logical expression of the second target logical expression is assigned to a root, and controls the acquired syntax tree to be recursively processed by the search statement generation unit;
The search statement generation means, after recursion processing, accesses the second relational database and refers to a search result corresponding to the second target logical expression to satisfy the second target logical expression The verification device according to claim 3, wherein the verification device is acquired. Preparing a first relational database storing a state transition model expressing transitions between a plurality of states;
A verification condition receiving step for receiving an input of a verification condition of the state transition model described by a computational tree logic (CTL) expression;
By analyzing the verification condition input in the verification condition receiving step, a syntax tree including a plurality of nodes each associated with a logical expression is generated, and the logical expression of the parent node is the logical expression corresponding to the child node. A parsing step defined based on an expression and an operator assigned to the parent node;
A search statement for searching for a state satisfying a logical expression corresponding to each node of the syntax tree is set such that the search statement of the parent node uses an output of a logical expression corresponding to the child node of the parent node as an argument. A search statement generation step to generate,
By executing each search sentence generated by the search sentence generation step with respect to the first relational database in the order of nodes in the hierarchy from the leaf node to the root node in the syntax tree, each search sentence is executed. A search execution step for acquiring the states corresponding to each as a search result,
A search result output step for outputting a search result corresponding to at least a root node of the syntax tree. Storing a search result for each of the search sentences in a second relational database in association with a logical expression corresponding to each of the search sentences or an identifier of the logical expression;
The search sentence generation step includes:
Read the nodes of the syntax tree from the root to the leaves in order of shallowness, and check whether the target logical expression corresponding to the read node or its identifier is stored in the second relational database,
When stored, delete the descendants of the read node, update the target logical expression corresponding to the read node to a reference to the search result associated with the target logical expression,
The search execution step acquires the search result by referring to the second relational database for the node updated to the reference to the search result.
The verification method according to claim 6. A logical expression generation step of generating a first equivalent expression of the logical expression and a negative second equivalent expression of the logical expression by rewriting the logical expression according to a rewrite rule based on Domorgan's law;
In the search statement generation step, when the target logical expression or its identifier is not stored, (1) when the first equivalent expression of the target logical expression is stored in the second relational database, the read Deleting a descendant of the node and replacing the target logical expression with a reference to the search result of the first equivalent expression of the target logical expression;
(2) When the first equivalent expression of the target logical expression is not stored and the second equivalent expression of the target logical expression is stored, the descendants of the read node are deleted, and the read node Replacing the target logical expression corresponding to the first equivalent expression and adding a second node indicating a reference to the search result of the second equivalent expression of the target logical expression as a child of the read node;
The verification method according to claim 7.   9. The verification method according to claim 8, wherein the search sentence generation step performs the process (2) only when an operator assigned to the read node is different from a negation operator. Further comprising a recursive control step,
In the search sentence generation step, when neither of the conditions (1) and (2) is satisfied,
It is checked whether or not a partial logical expression included in the target logical expression is stored in the second relational database. When the partial logical expression is stored, the partial logical expression is referred to by referring to a search result corresponding to the partial logical expression. Obtain the number of states that satisfy the expression, calculate the processing cost of the target logical expression based on the operator assigned to the read node and the obtained number of states,
For the first equivalent expression or the second equivalent expression, when the partial logical expression is stored in the second relational database, the processing cost is calculated in the same manner as the target logical expression,
When the processing cost of the first equivalent expression or the second equivalent expression is smaller than the processing cost of the target logical expression, the syntax tree is updated in the same manner as (1) or (2),
In the recursive control step, a second target logical formula whose processing cost is not calculated because it is not stored in the second relational database among the target logical formula, the first equivalent formula, and the second equivalent formula. Acquires a syntax tree in which a partial logical expression of the second target logical expression is assigned to a root, and controls to perform the processing by the search statement generation step recursively on the acquired syntax tree;
In the retrieval sentence generation step, after recursion processing, the number of states satisfying the second target logical expression by accessing the second relational database and referring to a search result corresponding to the second target logical expression The verification method according to claim 8, wherein the verification method is acquired.   The verification program for making a computer perform each step as described in any one of Claims 6 thru | or 10.

Images