JPH0460435A - Automatic apparatus for verification - Google Patents

Abstract

PURPOSE:To prepare verification data accurately and simply and to enable automatic verification of a device to be verified, by representing design specification of the device by a finite state machine model. CONSTITUTION:In the case of verification of a control board 29 of a refrigerator, for instance, first a virtual state and an internal time in an apparatus for verification are initialized. In a signal input element 13, next, an event and an action are extracted 15 and 17 respectively from data inputted from the control board 29. Then, it is verified whether or not they are a combination of an event and an action which can be generated in the current state. In the case when the event and the action which can not be generated exist, judgement is made as abnormality of verification and the process is ended. When a combination of those which can be generated is detected as the result of verification, the internal time is replaced by the time when the event and the action are generated, the virtual state is put in transition to a next state and thereby an internal state and the internal time are updated. Extractions are repeated until the data inputted to the signal input element 13 are up or until a forced end instruction is supplied from the outside.

Description

[Detailed Description of the Invention] [Object of the Invention] (Industrial Application Field) The present invention provides an automatic verification device that verifies whether a device to be verified is operating according to design specifications based on a finite state machine model. Regarding.

(Prior Art) Conventionally, when verifying a device to be verified, data is created in advance according to the items to be verified, and it is confirmed whether the device to be verified operates as specified. That is, data to be supplied to the device to be verified for each verification item according to the setting specifications and expected values of data output from the device to be verified as a result of supplying this data to the device to be verified are created along the time axis. Then, the data is actually supplied to the device under test, and the output data detected from the device under test is compared with the expected value, thereby determining whether the device under test is operating according to the set specifications. It is being inspected.

This will be explained in detail with reference to FIG. 6(a). Figure 6 (L
) The device to be verified 51 shown in ) includes a switch 53 and a sensor 55.
, a motor 57, and a light emitting diode (LED) 59 are connected, and as a result, the device to be verified 51 is configured to, for example, "rotate the motor 57 when the switch 53 is pressed" as shown in the design specification shown in FIG. 6(b). ” and other functions.

Here, pressing the switch 53 for the device to be verified 51 means that the signal at the terminal to which the switch 53 is connected changes from 5 volts to 0 volts, and rotating the motor 57 means If the purpose is to change the signal at the terminal to which the motor 57 is connected from 5 volts to O volts, the verification data creator should actually change the signal from the design specification shown in FIG. 6(b) to the device under verification. Considering the signals to be input and output, data showing the relationship between setting data and expected values as shown in FIG. 6(c) is created.

For example, in the first step, the input terminal connected to the switch 53 is initialized to 5 volts, and in the second step, the input terminal is changed to O volts, thereby creating a state in which the switch 53 is pressed. Furthermore, the expected value data for each of these states can be expressed as follows: It is possible to complete the verification data of the design specification "When the switch 53 is pressed, the motor 57 is rotated."

In order to verify the device to be verified 51 that performs such operations, a verification device 61 is connected to the device to be verified 51 as shown in FIG. 6(a). This verification device 61 is shown in FIG.
C) The setting data shown in
That is, the signal output unit 63 supplies the terminals to which the switch 53 and the sensor 55 are connected, and the device to be verified [5
1 output terminal side, that is, the motor 57 and the LED
A signal input unit 65 that receives an output signal from a terminal to which 59 is connected, and a comparison in which the output signal from the device to be verified 51 received by the signal input unit 65 is compared with the expected value in FIG. 6(b). 67. Note that when the signal output section 63 is connected to the input terminal side of the device to be verified 51, the switch 53 and sensor 55 and the device to be verified 51 are disconnected as shown by dotted lines in FIG. 6(a). .

In the device configured in this way, the signal output section 63 supplies the setting data shown in FIG.
The received output data is sent to the comparator 67 as shown in FIG.
By comparing with the expected value shown in b), it is possible to check whether the device to be verified 51 is operating according to the design specifications.

(Issue 8 to be solved by the invention) In the conventional automatic verification device described above, the verifier himself or herself understands and interprets the design specifications to create verification data.
Since the verifier must have detailed knowledge of the device to be verified, the developer and designer of the device to be verified must also become the verifier and create the verification data, which may interfere with the original development and design work. In addition, there is a problem in that it is difficult for anyone other than the development designer to create accurate verification data.

In addition, it is extremely difficult to create verification data that satisfies all design specifications, and verification items are often omitted, or even if data that can verify all setting specifications can be created, the data contains a lot of duplicated verification data, and it takes a considerable amount of time to verify all of this duplicated verification data, so it is not possible to perform all the verification items due to the amount of time that can be spent on verification. The problem is that it is possible.

Furthermore, various types of verification data are created by individuals, making it difficult to standardize verification and making it difficult to reuse verification data.

The present invention has been made in view of the above, and its purpose is to accurately and relatively easily create verification data based on a finite state machine model without manual intervention, and to verify verification data of a device to be verified. An object of the present invention is to provide an automatic verification device that can automatically perform the following steps.

[Structure of the invention]

(Means for Solving the Problems) In order to achieve the above object, an automatic verification device of the present invention is an automatic verification device that verifies whether a device to be verified is operating as specified based on signals from each part of the device to be verified. an event table that stores events that cause the device to be verified to start operating; an action table that stores actions that the device to be verified performs in response to the events; and a design specification for the device to be verified using the event table and the action table. A state transition table expressed by a finite state machine model, a signal input section into which signals from each part of the device under verification are input, signals from each part inputted by the signal input part, and events stored in the event table. an event extractor that extracts events supplied to the device to be verified by comparing the an action extraction unit that extracts the performed action; a verification unit that verifies whether the information extracted by the event extraction unit and the action extraction unit is correct based on information from the transition state table; and a virtual device to be verified. to virtually create the state of the device under verification,
and an automaton section that transitions a virtual device to be verified to the next state based on the result of the verification section, and the event extraction section converts and extracts an event occurrence condition in the event table into a state event. a state event pool that records the state event data extracted by the state event extraction section; and a state event conversion section that reconverts the state events stored in the state event pool into normal events according to the event occurrence conditions of the event table. The action extraction unit includes a state action extraction unit that converts and extracts the event occurrence conditions of the action table into state actions, and a state action pool that records state action data extracted by the state action extraction unit. and a state/action conversion unit that reconverts the state/action recorded in the state/action pool into a normal action according to the event occurrence conditions of the action table.

(Operation) The automatic verification device of the present invention expresses the design specifications of the device to be verified based on a finite state machine model, and sequentially detects events and actions of the device to be verified from the initial state of the device to determine the state. Detection can be performed without creating verification data by advancing the state to the final state, and the event occurrence conditions in the event/action table are converted to state events/actions and extracted and recorded. The status event/action is reconverted to a normal event according to the event occurrence conditions in the event/action table.

(Example) Hereinafter, the present invention will be explained in detail using the drawings.

FIG. 1 is a block diagram showing the configuration of an automatic verification device according to an embodiment of the present invention. The automatic verification device shown in the figure is
It automatically verifies the device being verified, and specifically, it checks whether the data already taken from the device being verified or the data being taken from the device being verified by monitoring the device is in accordance with the design specifications. This is to verify the device to be verified.

In addition, this automatic verification device performs verification of the device under verification based on a finite state machine model that expresses each operating state of the device under test and the state transition between each operating state. In order to do this, an event table 1 stores all the types and contents of events that trigger the device to be verified to start operating, and an event table 1 stores all types and contents of actions that cause the device to be verified to operate based on the event table 1. The state transition table 5 has an action table 3 representing the event table 3 and a state transition table 5 expressing the design specifications of the device to be verified by a finite state machine model using the event table 1 and the action table 3.

Information from the event table 1, action table 3, and state transition table 5 is supplied to the verification section 9 via the automaton section 7.

The automatic verification device also includes a signal input unit 13 that monitors each part of the device to be verified 11 and inputs and stores signals from each part. The signal input section 13 is connected to an event extraction section 15 and an action extraction section 17. The event extraction section 15 and the action extraction section 17 each extract an event and an action of the device to be verified 11 from the signals of each part of the device to be verified 11 stored in the signal human power section 13, and supply them to the verification section 9. Furthermore, in the automaton part 7,
It has a display section 19 that simply displays the results verified by the verification section 9, and a report section 21 that stores details of the contents verified by the verification section 9.

The event extraction section 15 includes a state event extraction section 15a that extracts state events from the data obtained by the signal input section 13, and a state event pool 1 that records the extracted data.
5b, and a state/event converter 15c that reconverts the recorded data. The action extraction section 17 also includes a state action extraction section 17a that extracts state events from the data obtained by the signal input section 13, a state action pool 17b that records the extracted data, and a state action pool 17b that reconverts the recorded data. and a state/action extraction section 17c.

FIG. 2 is a partially detailed configuration diagram of the automatic verification bag 1 shown in FIG. As shown in the figure, the event table 1, action table 3, and state transition table 5
are stored in the specification data file 23, and the display section 19 and report section 21 are each composed of a CRT display 25 and a report file 27. Further, the device to be verified 11 is a refrigerator control board 29 that constitutes a refrigerator 35, and a sensor 31 is connected to the input terminal side of the two refrigerator control boards, and a motor 33 that drives a compressor is connected to the output terminal side. has been done.

The refrigerator control board 29 configuring the device to be verified 11 includes:
It has the following functions.

1. When the power is turned on, the compressor will operate if the indoor temperature is warmer than 130℃.

2. When the indoor temperature becomes warmer than 120℃, operate the compressor to lower the room temperature.

3. When the indoor temperature gets colder than 130℃, stop the compressor and do not let the indoor temperature drop below that temperature.

4. Once the compressor stops operating, it will not resume operation for 5 minutes (compressor protection timer).

The automatic verification device shown in FIG.
The design specifications of the refrigerator control board 29, which is the device to be verified 11, are expressed based on the finite state machine model using the event table 1, action table 3, and state transition table 5 stored in Events and actions of the device to be verified 11 are sequentially detected from then on to advance the state, thereby making it possible to perform verification without creating verification data. The signal input unit 13 inputs data from the sensor 31 and drive data to the motor 33 that are output to the refrigerator control board 29, and extracts status events from the data input by the signal input unit 13. The state action is extracted by the state event extracting section 15a of the event extracting section 15 and the state action extracting section 17a of the action extracting section 17, and is stored in the state event pool 1.
5b and state action pool 17b, and the recorded state events and state actions are reconverted by state event conversion section 15c and state action conversion section 17c, respectively, and are supplied to verification section 9.

In addition, the automaton section 7 inputs the specifications of the refrigerator control board 29 from the specification data file 23 that stores the event table 1, action table 3, and state transition table 5, and sequentially verifies the state from the initial state according to this input. The verification section 9 actually performs verification according to the instructions from the automaton section 7.

That is, the automaton unit 7 creates a virtual device to be verified on the verification device, virtually creates the state of the device to be verified, and
This state is supplied to the verification section 9. The verification unit 9 extracts possible events and actions in the state supplied from the automaton unit 7 from the state transition table 5, and converts the extracted event and action information into information extracted from the event extraction unit 15 and action extraction unit 17. Verify whether it is correct by comparing it with. If the verification by the verification unit 9 is correct, the automaton unit 7 transitions the virtual device on the verification device to the next state and performs the same verification in this state. If the verification is incorrect, a new The state of the virtual device under verification is created.

FIG. 3 is a state transition diagram showing the specifications of the refrigerator control board 29. As shown in the figure, the two refrigerator control boards are in the states STO, STI, ST2°Sr1. Sr1. Sr.
5. State STO is a state in which the system waits until the power is turned on, state STI is a state in which it is determined whether or not to operate the compressor based on the indoor temperature, and state ST2 is a state in which the compressor is operated until the indoor temperature falls sufficiently. State ST5 is a state in which the compressor is stopped and protected, and state ST5 is a state in which the compressor is protected.
T4 is a state when the indoor temperature rises during compressor protection and the compressor protection is released, and state ST3 is a state where the compressor protection is released and the system waits until the indoor temperature rises.

FIGS. 4(a), (b), and (c) are diagrams showing examples of the event table 1, action table 3, and state transition table 5, respectively, and were created based on the state transition diagram of FIG. This is a spec pig. Event table 1 in FIG. 4(a) contains the six events used in the transition state diagram in FIG.
30'C or higher", "Indoor temperature is -30°C or lower", "Indoor temperature is -20°C or higher", "Indoor temperature 3
"The temperature has dropped below 0℃", "Compressor protection timer has expired"
are extracted and shown corresponding to each ID number 0, 1, 2, 3°4.5. In addition, the action table 3 in FIG. 4(b) extracts the three actions used in the state transition diagram, namely "compressor operation", "compressor stop", "compressor protection, timer initialization", It is shown corresponding to each ID number 0, 1.2. Furthermore,
The state transition table 5 in FIG. 4(c) shows state transitions. For example, if "event ID4 (indoor temperature became -30°C)" occurs in state ST2,
“Action IDI (stop compression/sensor)” and “Action ID2 (initialize compression/sensor protection timer)”
This means to execute `` and advance the state to ``rST5''. These three tables are in the specification data file 2.
It is stored in 3.

By the way, conventionally, the event detection unit has detected all the events described in the event table and recorded them in the event pool. For example, taking Figure 4 as an example, 6
All events were detected and recorded in a pool. FIG. 7 shows the recorded data of each event when the room temperature changes. As shown in the figure, “indoor temperature -3
The status events such as "Indoor temperature is -30°C or higher" and the normal event "Indoor temperature is -30°C or higher" are different events. The time ts when the temperature exceeded ℃ and -30
It combines the data of the time te when the temperature dropped below ℃, and is almost the same. If you record only one set of the time ts when the temperature exceeded -30°C and the time te when the temperature fell below -30°C for these events in the pool, you can later use that data and the event occurrence in the event table. Events can be synthesized by comparing them with conditions.

Therefore, in this embodiment, the state event extraction unit 15a (similarly, the state action extraction unit 17a) and a state event converter 15C that synthesizes the original event from the recorded data.
(Similarly, the state/action converter 17C).

By not directly recording event/action data in the pool in this way, the amount of recorded data can be significantly reduced. In this example, one set of data is required for three events, so the number of records is reduced to 1/3.

In addition to this, "the indoor temperature has exceeded 130 degrees Celsius",
The event "indoor temperature is 130 degrees Celsius" is considered,
If all are used, a maximum of 115 records will be sufficient. Furthermore, since it is not necessary to check the occurrence status for each event, it is expected that the detection time will be shortened.

The operation will be explained with reference to the flowchart in FIG.

First, the virtual state and internal time within the verification device are initialized (steps 110 and 120). Events and actions are extracted from the data manually input from the refrigerator control board 29 by the signal input unit 13 in the event extraction unit 15 and the action extraction unit 17 (steps 130 and 1).
40). The verification unit 9 verifies whether the combination of event and action can occur in the current state (steps 150 and 160). If there are events and actions that cannot occur, the process ends as a verification error (
step 170). As a result of the verification, if a possible combination is detected, the internal time is replaced with the time when the event and action occurred, and the internal state and internal time are updated by transitioning the virtual state to the next state (
Steps 180 190). The verification is completed by repeating steps 130 to 190 until there is no more data input to the signal input unit 13 or a forced termination command is supplied from the outside (steps 200 and 210).

As mentioned above, the design specifications of this automatic verification device are described based on a finite state machine model. A finite state machine model is expressed using a finite set of states and a set of state transitions caused by each human signal, i.e., an event. ). For example, in Fig. 3, "In state 5T2J,"
When an event occurs in which the temperature drops below 0°C,
``Stop the compressor'' and ``Initialize the compressor protection timer.''
This expresses the transition to T5J. At this time, a combination of usable functions (including single functions) possessed by the device to be verified is expressed by a "state" in the finite state machine model. Therefore, all routes that can reach the final state from the initial state of the device to be verified are all possible verification items. By performing verification based on a finite state machine model that expresses the design specifications of the device to be verified, it is possible to prevent omissions of verification items due to human error.

In addition, in this embodiment, we have explained the case of verifying the refrigerator control board, which is the control device of the refrigerator, but this automatic verification device can be applied to many devices such as vending machines and washing machines by changing the specification data file. can also be verified in the same way. If the specification data file of this automatic verification device can be changed from the outside, it can be used as a verification device for vending machines, washing machines, etc. without changing the automatic verification device itself.

In addition, although the verification was performed by inputting the signal data of the control board of the refrigerator directly to the signal input section manually, it is also possible to perform the verification by dividing the signal data into this signal input section and other verification sections. That is, the signal input section first stores signal data in a file, and later the verification section extracts signals from the file in a batch manner and verifies them. In this case, the verification device is independent of the manual speed of the signal input section, so even if the device under test changes rapidly, it is possible to perform the same verification as this automatic verification device by speeding up only the signal input section. becomes. Furthermore, since the signal data itself is stored, it is possible to have the automatic verification device perform the verification any number of times, which is effective when debugging the device to be verified including the automatic verification device itself.

〔Effect of the invention〕

As explained above, according to the present invention, the design specifications of a device under verification are expressed based on a finite state machine model, and the events and actions of the device under verification are sequentially detected from the initial state of the device to be verified. By advancing the state to the final state, it becomes possible to perform verification without creating verification data. Further, unlike creating verification data from design specifications and performing verification, verification is performed directly from the design specifications, eliminating the need to create verification data and making the verification contents (results) easier to understand.

Furthermore, the event occurrence conditions in the event/action table are converted into state events/actions, extracted and recorded, and the recorded state events/actions are reconverted into normal events according to the event occurrence conditions in the event/action table. , the recording capacity can be reduced and the processing speed can be increased.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing the configuration of an automatic verification device according to an embodiment of the present invention, FIG. 2 is a block diagram specifically showing a partial configuration of the automatic verification device shown in FIG. 1, and FIG. Figure 1 is a state transition diagram used in the automatic verification device, Figure 4 is a table showing the event table, action table, and state transition table for the state transition diagram in Figure 3, and Figure 5 is a table showing the state transition table used in the automatic verification device.
Figure 6 is a flowchart showing the operation of the automatic verification device shown in Figure 6, Figure 6 is a diagram showing the configuration, setting specifications, and verification data of the conventional automatic verification equipment, and Figure 7 is an explanatory diagram of changes in indoor temperature and event extraction data. . 1 ・ 3 ・ 5 ・ 7 ・ 9 ・ 11 ・ 13 ・ 15 ・ 5a 5b 5c 17 ・7a 7b 7c ・Event table, ・Action table, ・State transition table, ・Automaton section, ・Verification section, ・Verified device, - Signal human power section, - Event extraction section, - State event extraction section, - State event pool, - State event conversion section, - Action extraction section, - State action extraction section, - State action pool, - State action conversion section.

Claims (1)

[Claims] An automatic verification device that verifies whether a device to be verified is operating as specified based on signals from each part of the device to be verified, the device includes an event table that stores an event in which the device to be verified starts operating, and an event table that stores an event in which the device to be verified starts operating. an action table that stores actions to be performed, a state transition table that expresses the design specifications of the device to be verified using a finite state machine model using the event table and the action table, and signals that input signals from each part of the device to be verified. an input section; an event extraction section that compares signals from each section inputted by the signal input section with events stored in the event table to extract events to be supplied to the device to be verified; and the signal input section. an action extraction section that extracts the action taken by the device under verification by comparing the signals of each section inputted with the actions stored in the action table; and the information extracted by the event extraction section and the action extraction section. A verification section that verifies whether or not it is correct based on the information from the transition state table; an automaton section that transitions the device to be verified to the next state; and a state event conversion unit that reconverts the state event recorded in the state event pool into a normal event according to the event occurrence conditions of the event table, and the action extraction The unit includes a state action extraction unit that converts and extracts the event occurrence conditions of the action table into a state action, a state action pool that stores state action data extracted by the state action extraction unit, and a state action pool that records the state action data in the state action pool. and a state/action conversion unit that reconverts a state action into a normal action according to an event occurrence condition in the action table.