JPH04271439A - Program verifying device - Google Patents

Abstract

PURPOSE:To logically verify the correctness of a program with respect to individual test data and to verify whether the program is correctly operated independently of test data or contingency in all cases or not. CONSTITUTION:An FST graph and a V item are read by an FST graph reader 1 and a V item reader 2 respectively. The V item is converted into a formula constituted of irreducible minimum operators by a V item converter 3, and all partial verification items constituting the V item are extracted. Subsequently, a dependency graph (DG) generated in accordance with the V item converted by the V item converter 3 and the FST graph by a dependency graph generator 4. When all nodes of the generated dependency graph are determined nodes, discrimination is performed by a discriminating device 6. If dependent nodes exist, they are successively converted into determined nodes by a dependency graph simplifying device 5, and finally, all dependent nodes are converted into determined nodes.

Description

[Detailed description of the invention]

[Object of the invention]

0002

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program verification device.

0003

2. Description of the Related Art Many of recent home appliances such as air conditioners and electric rice cookers incorporate simple microcomputers. A computer built into a device, such as a microcomputer that controls an air conditioner, is called a device-embedded computer. The software that runs this embedded computer is called device embedded software.

[0004] Embedded computers are installed not only in home appliances but also in various equipment such as machine tools, robots, automobiles, airplanes, and rockets. Although embedded systems are becoming very popular, poor software productivity has become a major problem in complex embedded systems. The U.S. Department of Defense (DoD) has set out 197
This is why we have been promoting the design and standardization of the Ada programming language since 1999. In the field of robots, robots are becoming increasingly complex and sophisticated, as seen in the automation of semiconductor manufacturing lines, and conventional manual software development has reached its limits.

[0005] In order to increase the productivity of such device-embedded software, it is essential to improve the programming language such as Ada, as well as to provide a program development support environment. In particular, it is of great significance to support the testing/debugging stage, which was the most bottleneck in the development process of device-embedded software.

Device-embedded software differs from sequential processing programs developed on large-scale computers in the following points.

(1) If each component of a parallel processing device or system operates in parallel, it is a parallel system. For example, most automation equipment such as robots in factories are inherently parallel systems.

(2) The software needs to be able to adequately deal with physical errors in the exception handling device (for example, a part slips while the robot is grabbing and moving the part). . Based on the premise that such physical errors always occur with a certain degree of probability, error handling, that is, an exception handling mechanism in device-embedded software is essential.

One of the most difficult phases in developing device-embedded software with the above characteristics is testing and debugging. In conventional testing methods, a program is executed on an actual machine or a simulator, and checked against test data prepared by a human or automatically generated by a computer.

0010

[Problem to be solved by the invention] However, in general, in the case of complex parallel processing programs, it is a very difficult task for humans to imagine all the situations that will occur due to a combination of various factors, and there are limitations to methods using test data. There is. In other words, during actual operation, there is a possibility that bugs may occur in situations that were not anticipated when creating the test data. If such a bug is discovered after the product is shipped, it will be a big problem. Additionally, bugs cannot be reproduced in parallel processing programs. In other words, even with the same test data, bugs may or may not occur depending on chance. In such cases, debugging requires more time and effort than necessary.

The present invention was made in response to such conventional circumstances, and instead of testing whether a program runs correctly on individual test data, it logically verifies the correctness of the program. The present invention aims to provide a program verification device that can verify whether a program operates correctly in all cases without relying on test data or chance.

[Configuration of the invention]

[0013]

[Means for Solving the Problems] That is, the present invention provides a means for inputting a program expressed by a finite state transition graph, and a means for inputting verification items of the program written in a verification item description language. , the state transition graph, and the verification item, find a node represented by a pair of the state of the state transition graph and the verification item, and a truth value function that is the label of this node, and calculate the dependence. means for generating a graph; and a dependent node among the nodes that cannot determine the value of the truth value function by itself, the dependent node being capable of determining the value of the truth value function by that node alone. The present invention is characterized by comprising means for converting into a decision node, and means for determining whether the program satisfies the verification items based on the value of the truth value function.

[0014]

[Operation] In general, logically verifying a program is difficult as a practical matter, but in the case of device-embedded software, the program can often be expressed by a finite state transition graph. Therefore, the program verification device of the present invention logically verifies the characteristics of the program expressed by such a finite state transition graph, thereby ensuring that the program is correct in all cases without depending on test data or chance. This allows you to verify whether it works or not.

[0015]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the program verification apparatus of the present invention will be described in detail with reference to the drawings.

FIG. 1 shows the configuration of a program verification device according to an embodiment of the present invention. As shown in the figure, the program verification device of this embodiment uses a finite state transition graph (
Finite Stata Transition G
raph (hereinafter referred to as FST graph) and verification items (verifivcation) written in the verification item description language.
n term, hereinafter referred to as V item) as input, and FST
Judgment result of whether the graph satisfies item V (YES/
This is a device that outputs NO), and includes an FST graph reading device 1, a V item reading device 2, and a V item converting device 3.
, a dependency graph generation device 4, and a dependency graph simplification device 5
and a determination device 6.

In the program verification device having the above configuration, first, an FST graph reading device 1 and a V item reading device 2 are used.
Read the FST graph and V item respectively. An example of input/output is shown in FIG. In the figure, 10 shows an example of input of the FST graph, 11 shows an example of input of V item, and 12 shows an example of the judgment result which is the output.

Thereafter, the V item read by the V item reading device 2 is converted by the V item converting device 3 into a formula consisting of the minimum necessary number of operators. Note that the conversion rules in the V item conversion device 3 are shown in FIG. Furthermore, the grammar of the verification item description language is shown in FIG. Note that the verification item is a state logical formula, and the state logical formula is composed of a state logical formula and a path logical formula.

Furthermore, the V item conversion device 3 simultaneously converts V
All partial verification items (Element
of Verification Term, hereinafter referred to as EV
(referred to as items). Cut out all the partial state logical expressions of the V item and give them ID numbers. Proceed with the process using this number.

Extraction of partial logical expressions can be automatically detected based on the syntax rules of the verification item description language. however,
Delete redundant sublogic expressions. Also, mu(sv(Z)
, t(sv(Z))) is expressed as sv(Z). sv(
This is possible because Z) is restricted to be unique. For example, mu(sv(z1),ep(
a & @mu(sv(z2), ap(b #@sv
The EV item of (z1)) & ep@sv(z2)))) is ■ mu(sv(z1),ep(a & @mu(
sv(z2), ap(b# @sv(z1)) & e
p@sv(z2)))) ■ ep(a & @mu(sv(z2), ap(
b # @sv(z1)) & ep@sv(z2))
) ■ mu(sv(z2), ap(b # @sv(z
1)) &ep@sv(z2))■ ap(b #
@sv(z1)) & ep@sv(z2) ■
ap(b # @sv(z1)) ■ ep@sv(
There are 6 types of z2). However, if redundant logical formulas are deleted and processing is performed to represent them with sv(z), the following four EV items can be extracted.

[0021] ■ sv (z1) ■ sv (z2) ■ ap (b # @sv (z1)) ■ ep@
sv(z2) Here, the mu expression represented by each sv(z) is registered in the database, and when sv(z) is decomposed, the original mu expression is decomposed.

Next, a dependency graph (depe
(hereinafter referred to as DG) is generated by the dependency graph generation device 4. Each node of DG is
A set (s,
t). A logical function f is attached as a label to each node. This is expressed as ((s, t), f). f indicates the truth value of the EV item (t) in the state (s) of the FST graph. If the truth value can be determined at that node, f = 1 (
true) or f=0 (false). That is, ((s, t
), 1) is ``When the program state is s, the verification item t
It means that "is true." A node whose value of the truth value function is determined in this way is called a decision node. On the other hand, for nodes whose truth values cannot be determined by themselves (hereinafter referred to as dependent nodes), there is a logical dependency relationship with other nodes (dependency link
, hereinafter referred to as dlink). This becomes the edge of DG. The concrete edge format is dlink((node0,f(x1,...,xn)
), [(node1, x1), . ．． ．． , (noden,
xn)]). It is. Here, nodei=(si,ei), and when the truth value of nodei is xi, node0
The truth value of is expressed as f(x1,...,xn). This d-link goes from node0 to node1 to node
2, ...indicates that there are n edges for noden.

If all nodes of the generated dependency graph are decision nodes, the decision device 6 makes a decision. That is, the set of the initial state s0 of the FST graph and the V item formula e0 (
The truth value of s0, e0) is the determination result.

Furthermore, if there are dependent nodes, the dependency graph simplification device 5 sequentially converts the dependent nodes into decision nodes, and finally all dependent nodes are made into decision nodes.

Next, a method for creating the above-mentioned dependency graph will be explained.

First, the ID number of the partial state logic formula and the FST
A 2-tuple of each state of graph T and a logical function (a graph whose node is (state of T, ID number) (dependence graph)
Create DG. Each node is associated with a logical function on a one-to-one basis. This correspondence is expressed as (node, f) and registered in the database. This logical function may change during the process. Here, if f=1 in ((s, t), f), t is true in s, and if f=0, it is false. The dependence relationship of truth values is nodei (1 ≦i
The truth value xi of ≦n) influences (propagates) the logical variable xi of the logical function f(X1,...,xn) that determines the truth value of node0. A concrete logical function is obtained in the process of decomposing and evaluating (s, t).

In reality, it is not necessary to generate DG for all nodes (S, t), but only the edges and nodes connected to (s0, t0) starting from (s0, t0) need to be generated. Here, s0 is the initial state of T, and t0 is the V item after conversion.

Note that FIG. 5 shows the decomposition evaluation rule for generating DG. Here, t is a state formula and g is a path formula. Note that s is in the same state at 111 in the figure. 112 is a decomposition of a logical expression related to OR. Here, s is in the same state. 113, s1, s2 are the next states in T that satisfy the path formulas g1, g2. Also, at 114, s1 is the state at the next point in time in T that satisfies the path formula g.

Next, simplification of the dependency graph will be explained.

First, d-links ending at the decision node are deleted one by one. That is, d1ink((
node0,f(x1,...,xn)), [(no
de1, x1), (node2, x2), . ．． ．． ,(n
oden, xn)]). , nodei is a decision node (i.e., assign(nodei, fi
) and if fi=0 or fi=1), then xi=fi
Assign it to f and delete this element. In other words, d1
ink((node0,f(x1,...,xi-1,
xi+1,. ．． ．． , xn)), [(node1, x1
),. ．． ．． , (nodei-1, xi-1), (nod
ei+1, xi+1), . ．． ．． , (noden, xn)
]). becomes. If the result of logical calculation of f is 0 or 1, no
de0 becomes the new decision node. This d-link is unnecessary, so delete it. Metrically, each node of DG is 1
The simplification is completed just by tracing once.

Next, for the simplified dependency graph,
Find strongly connected components. A closed component is extracted from this, and all mu logical expressions in the component are made false. In other words, since a new decision node is generated, simplify it again by the above process,
Repeat the process. Eventually, all nodes become decision nodes.

Next, the determination will be explained. ((s0,
t0), f) are decision nodes, and whether f is 0 or 1
can be determined. If it is 1, the judgment is YES (satisfied)
If it is 0, it is NO (not satisfied). Here, s0 is the initial state of the FST graph, and t0 is the V item after conversion.

Next, a simple example of the overall verification will be shown with reference to FIGS. 6 and 7. Figure 6 shows FST graph reading device 1
7 shows the FST graph read from the V item reading device 2. FIG. The meaning of this item V is "Will a certain route pass through a someday?" In this case, the EV item of V item t is t=m
u(sv(z),ep(a#@sv(z))) t'
=ep(a#@sv(z)) However, t and t' can be regarded as the same. The generated dependency graph looks like this:

Nodes: (s0, t), (s1, t), (s2, t), (s3,
t), (s4, t) where (s3, t) is the only decision node and is ((s3, t), 1). Therefore, Edge: d1ink(((s0,t),x),[((s1,t)
, x)]).

d1ink(((s1, t), x), [(
(s2, t), x), ((s3, t), 1)]).

d1ink(((s2, t), x), [(
(s1, t), x)]). By simplifying this graph, we finally get ((s0, t)
, 1), and it can be determined that the finite state graph satisfies the verification items.

As described above, according to this embodiment, various characteristics of a program expressed by a finite state transition graph can be verified. Specific items that can be verified include detection of deadlock, verification of partial order relationships of events, confirmation of mutual exclusion, and confirmation of overlapping relationships of states. Unlike testing using test data, all possibilities can be logically verified, ensuring high reliability.

[0038]

[Effects of the Invention] As explained above, according to the program verification device of the present invention, instead of testing whether a program runs correctly on individual test data, the correctness of the program is logically verified. It is possible to verify whether a program works correctly in all cases without relying on test data or chance.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing the configuration of a program verification device according to an embodiment of the present invention.

FIG. 2 is a diagram showing an example of input/output in an embodiment of the present invention.

FIG. 3 is a diagram showing conversion rules in the V item conversion device.

FIG. 4 is a diagram showing the grammar of the verification item description language.

FIG. 5 is a diagram showing a decomposition evaluation rule for determining a logical function f.

FIG. 6 is a diagram showing an FST graph in a verification example.

FIG. 7 is a diagram showing V items in a verification example.

[Explanation of symbols]

1 FST graph reading device 2 V item reading device 3 V item conversion device 4 Dependency graph generation device 5 Dependency graph simplifier 6 Judgment device

Claims (1)

[Claims] 1. Means for inputting a program expressed by a finite state transition graph; means for inputting verification items of the program written in a verification item description language; means for generating a dependency graph by determining a node represented by a pair of the state of the state transition graph and the verification item and a truth value function that is a label of this node from the verification item; home,
means for converting a dependent node that cannot determine the value of the truth value function by the node alone into a decision node that can determine the value of the truth value function by the node alone, and the truth value A program verification device comprising means for determining whether the program satisfies the verification items based on the value of the function.