JPH10161906A - Device and method for executing software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To control the simulation of hardware and software so that it matches with real operation timing. SOLUTION: A hardware simulator 4 displays the image of hardware on a display means 5 based on hardware information 2 and updates the indication based on the change of hardware. A user generates the event of test data to be inputted to the software by operating this image while using the mouse or keyboard of input means 1. A virtual execution engine 6 simulates the operation of software corresponding to the applied event. A user definition simulator 9 sends the change contents of external environment to affect mutually with a system to the hardware simulator 4 as the event.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an improvement of a software execution device and a software execution method for testing software under development, and more particularly, to controlling a simulation of hardware and software so as to correspond to an actual operation timing. By doing so, it pertains to one that performs an accurate test.

[0002]

2. Description of the Related Art In various systems such as an air conditioner (air conditioner), a microwave oven, an electronic rice cooker, and a portable telephone, software is used to control hardware. A test for confirming the operation is indispensable for software development. Conventionally, a test of software to be incorporated in hardware has been performed using the hardware after the completion of the hardware to be incorporated. For this reason, when hardware is incomplete at the early stage of development, it has been difficult to test software.

[0003] As a result, software testing and hardware development cannot be performed simultaneously in parallel, resulting in a problem that the product development period is lengthened. Further, at the software specification stage, the developer himself has manually performed a task of detecting errors by visually following the software specifications. For this reason, there is little possibility that a software error is overlooked, and it has been difficult to improve work efficiency.

[0004] As a technique for solving such a problem, Japanese Patent Application Laid-Open No. 6-110049 by the present applicant is cited. According to this technology, when an operation specification of software is given, operations included in the specification are sequentially simulated, and a change in hardware corresponding to the operation is displayed.

[0005]

However, Japanese Patent Application Laid-Open No.
In the configuration 10049, the simulation time is advanced each time a certain process for executing the simulation makes one cycle. For this reason, in the simulation, unlike the actual case, the time does not progress until a certain process has completed one cycle, and the progress pace of the time varies according to the content of the process. As a result, it has been difficult to perform accurate simulations on matters related to the passage of time, such as counting by a timer and changes in product temperature.

Japanese Patent Application Laid-Open No. Hei 5-289860, which is another technique related to software testing, divides a program into virtual parts, defines the operation in advance for each part, and defines the operation when an operation is given to the part. Perform the operation. JP-A-5-289860 mentions that a timer, which is an example of a virtual part, operates based on time. However, the entire simulation is performed according to time information, and input of input data for testing software is performed. Timing is not taken into account.

However, in an actual system, both the operation of hardware and the operation of software are performed with a certain required time. For this reason, there has been a demand for a technique of providing time information for simulation of both hardware and software to perform simulation corresponding to actual operation timing. In some cases, the software operates differently depending on the timing at which an operation is input, so input data (test data) given to the software for a test.
At a desired timing.

[0008] Further, not only may software and hardware affect each other, but also software and hardware may have a relationship with an external environment. In such a case, not only the operation of the system may change the external environment, but also the changed external environment may further affect the operation of the system. For example, changes in the temperature inside the refrigerator are affected by the outside air temperature, and when the air conditioner is operated, the room temperature outside the air conditioner also fluctuates. In the prior art, hardware and software constituting the system itself can be simulated, but such a change in the external environment is not simulated. For this reason, it is difficult to perform an accurate software test including the relationship with the external environment, and a software test apparatus that simulates a change in the external environment has been required.

The present invention has been proposed to solve the above-mentioned problems of the prior art, and an object thereof is to control hardware and software simulations so as to correspond to actual operation timings. By
An object of the present invention is to provide a software execution device and a software execution method for performing an accurate test. It is another object of the present invention to provide a software execution device and a software execution method for generating predetermined data by operating virtual hardware to be simulated and performing a test efficiently.

Another object of the present invention is to provide a software execution device and a software execution device for effectively performing a test in which the timing of an event is a problem by giving predetermined data at a designated timing based on the control. Is to provide a way. It is another object of the present invention to provide a software execution device and a software execution method for performing a realistic and accurate test by simulating a change in an external environment of the system.

It is another object of the present invention to provide a software execution device and a software execution method for efficiently performing a test by reusing stored predetermined data for simulation. It is another object of the present invention to provide a software execution device and a software execution method for realizing various test modes by saving information during a simulation and restarting the simulation.

[0012]

According to one aspect of the present invention, there is provided a software execution device for testing software used for controlling hardware, the virtual execution being performed based on information on the hardware. First execution means for forming hardware on a computer, and second execution for executing software to be executed on the virtual hardware based on predetermined data for testing the software Means,
Control means for controlling the operation timing of the virtual hardware and its software corresponding to the actual operation timing with respect to the first execution means and the second execution means. .

According to a seventh aspect of the present invention, there is provided a software execution method for testing software used for controlling hardware, wherein the information relating to the hardware is provided. A first execution process for forming virtual hardware on a computer based on the first execution process, and executing a software to be executed on the virtual hardware based on predetermined data for testing the software. 2 and a control process for controlling the operation timing of the virtual hardware and its software to correspond to the actual operation timing with respect to the first execution process and the second execution process. It is characterized by including.

A recording medium on which computer software for realizing a software execution method for testing software is also an aspect of the present invention. In this case, the software execution method realized by the computer software recorded on the recording medium includes a first execution process for forming virtual hardware on a computer based on the information on the hardware, and a test of the software. Based on the given data to
A second execution process for executing software to be executed on the virtual hardware, and an operation timing of the virtual hardware and the software with respect to the first execution process and the second execution process, And a control process for performing control so as to correspond to the actual operation timing.

According to the first and seventh aspects of the present invention, even if the hardware is not completed, if information about the hardware is input,
Virtual hardware is formed on a computer, and software to be executed is executed on the virtual hardware. When the hardware operates under the control of software, the operation appears in the virtual hardware. For this reason, even if the hardware is not completed in the early stage of development, it is possible to give the predetermined data to the software in the same environment as using the actual hardware (actual machine) and perform the software test.
Note that the software mentioned here may be specific software such as a mnemonic code or software specifications. Therefore, even if the specific software is not completed, the software can be tested. As a result, the development time of the product can be shortened, and the detection of the specification defect which has been conventionally performed by the developer can be assisted, thereby significantly improving the accuracy and efficiency of software debugging. Since the operation timings of the virtual hardware and the software are controlled so as to correspond to the actual operation timings, it is possible to simulate accurately in accordance with the actual operation timings.

According to a second aspect of the present invention, in the software execution device according to the first aspect, the predetermined data is generated by operating virtual hardware on the first execution means. 2. The software execution device according to 1.

According to an eighth aspect of the present invention, the invention of the second aspect is grasped from the viewpoint of a method. In the software execution method according to the seventh aspect, the predetermined data is stored in the first place.
8. The software execution method according to claim 7, wherein the software execution method is generated by manipulating virtual hardware by the execution processing of the software.

According to the second and eighth aspects of the present invention, if the virtual hardware is operated with a mouse or the like, predetermined data to be given to the software is generated, so that there is no need to define and input the predetermined data as a character string. As a result, software testing becomes more efficient.

According to a third aspect of the present invention, in the software execution device according to the first or second aspect, the first execution means is provided when a series of events whose occurrence timings are specified are given as predetermined data. 3. The software execution device according to claim 1, wherein each event is sent to the second execution unit at the designated timing under the control of the control unit.

According to a ninth aspect of the present invention, the invention of the third aspect is grasped from a method point of view. In the software execution method according to the seventh or eighth aspect, the first execution processing is performed at a timing of occurrence. When a series of specified events are given as predetermined data, each event is provided to the second execution process at the specified timing based on the control by the control process. It is characterized by.

According to the third and ninth aspects of the present invention, not only the predetermined data is generated sequentially but also the generation timing is specified for each event constituting the predetermined data, the control is performed based on the control by the control means. Thus, an event is provided to the software simulation at a specified timing. For this reason, it is possible to effectively perform a test in which the timing of an event is a problem, for example, the operation differs depending on the timing at which data is input.

According to a fourth aspect of the present invention, in the software execution device according to the first, second or third aspect, a definition means for defining a change content of an external environment related to the target system; And a third execution unit that provides the change in the external environment to the second execution unit based on the operation and the defined change content.

According to a tenth aspect of the present invention, the invention of the fourth aspect is grasped from the viewpoint of a method. In the software execution method according to the seventh, eighth or ninth aspect, there is a relationship with the target system. Providing a change process of the external environment to the second execution process based on a definition process for defining a change content of an external environment, an operation of the system, and the defined change content. And a third execution process.

According to the fourth and tenth aspects of the present invention, a change in the external environment is simulated even when the system changes the external environment or when the change in the external environment affects the operation of the system. For this reason, by further simulating the operation of the system based on the simulated change in the external environment, it is possible to obtain more accurate test results that are more practical. In particular, by simulating a change in the external environment based on the control, a change in the external environment that is closer to reality can be obtained, and an accurate test can be performed.

According to a fifth aspect of the present invention, in the software execution device according to the first, second, third or fourth aspect, the software execution device further comprises storage means for storing predetermined data obtained from the first execution means, The first execution means is configured to read out the stored predetermined data and send it to the second execution means.

According to the fifth aspect of the present invention, the predetermined data created by the first execution means is recorded, and the simulation can be performed by reusing the predetermined data. For this reason, the simulation when the same predetermined data is used is made more efficient, and the reproduction test of the abnormal operation is facilitated.

The invention of claim 6 is the invention of claims 1, 2, 3, 4
Or in the software execution apparatus according to 5, wherein information necessary for restarting each of the simulations after interruption is stored at a desired point in time, and a second storage means for storing each simulation using the stored information. And a restart means for restarting the computer.

According to the sixth aspect of the present invention, information for restarting the simulation once interrupted, such as the state of software and hardware, can be stored at a desired time. Therefore, in the event that an unexpected event such as a failure or accident occurs after storage, various tests can be implemented by re-starting the work from the point of recording or resuming the work at a later date according to the schedule. Can be.

In particular, when a test to be performed automatically using the recorded predetermined data requires a long time, information for resuming is stored when reproduction of the predetermined data has been performed halfway. By resuming the test later, it is possible to automatically perform a test that requires a long time and to divide the test according to a schedule. For this reason, the degree of freedom of the test operation is improved.

[0030]

Next, an embodiment of a software execution apparatus according to the present invention will be described with reference to the drawings.

(1) Configuration In this embodiment, a software test apparatus (a test apparatus) embodying a software execution apparatus according to claims 1 to 5 and a software execution method executed on this software execution apparatus (claims 6 to 10) (Hereinafter referred to as “this device”) and a software test method. First, FIG. 1 is a functional block diagram showing the configuration of the present apparatus. In this figure, solid arrows indicate the flow of data, and broken arrows indicate the flow of control.

First, the present apparatus has input means 1 for inputting information and instructions. As the input means 1, for example, a keyboard and a mouse can be used. The input unit 1 is used, for example, to input hardware information 2 relating to the configuration and operation of hardware under development and an operation specification 3 as software to be tested.

Further, the present apparatus simulates and displays the hardware and the operation of the hardware based on the hardware information 2 to display virtual hardware on a computer. (Corresponding to first execution means). Further, the present apparatus has a display means 5 for displaying various information, and the hardware simulated by the hardware simulator 4 and its operation are displayed on the display means 5.

The hardware simulator 4 not only displays hardware, but also inputs an operation on the displayed hardware via the input means 1 and uses the input operation for a software test. It is configured to be sent to the virtual execution engine 6 as data (corresponding to the predetermined data).

The virtual execution engine 6 causes the virtual hardware to execute software to be tested on the virtual hardware based on the operation specifications 3 and the test data obtained from the hardware simulator 4. (Corresponding to execution means).

The input means 1 is also used to define external environment change contents 8 related to the system to be tested (corresponding to the definition means in claim 4). The apparatus has a user-defined simulator 9 (corresponding to a third execution means in claim 4) for simulating a change in an external environment based on the operation of the system and the defined change content 8. . Further, the present apparatus has a clock 7 for providing time information to the hardware simulator 4, the virtual execution engine 5, and the user-defined simulator 9. The clock 7 corresponds to a control unit that controls the hardware simulator 4 and the virtual execution engine 6 to control the operation timing of the virtual hardware and its software so as to correspond to the actual operation timing.

The present apparatus has a reproduction history file 10 (corresponding to a storage means in claim 5) for storing test data, and the hardware simulator 4 reproduces the test data in response to an input instruction. The test data stored in the history file for use 10 is read and sent to the virtual execution engine 6.

In addition, the present apparatus has a restart file 11 (corresponding to a second storage unit in claim 6) for storing information that can be restarted after being interrupted once at a desired time for each simulation. . Correspondingly,
The hardware simulator 4, the virtual execution engine 6, and the user-defined simulator 9 are configured to restart each simulation using information stored in the restart file 11 in response to an input instruction. The restart means (claim 6) for restarting the simulation is constituted.

The present apparatus also includes a browsing history file 1 for storing information such as transitions generated when the virtual execution engine 6 simulates the operation of software.
2 Since the hardware simulator 4, the virtual execution engine 6, the user-defined simulator 9, and the clock 7 are configured as processes in a multi-process system, they are highly independent of each other, and the whole operation is stable. .

(2) Function and Effect (2-1) Outline of Test in This Device Here, it is assumed that a built-in microcomputer program for controlling the refrigerator is tested as software.
A user who is a program developer can test software by simulation at an early stage of development when concrete microcomputer programs such as refrigerator hardware and assembler mnemonic code are not completed.

That is, the user first inputs the hardware information 2, the operation specifications 3, and the change contents 8 of the external environment from the input means 1. When the user inputs a test start instruction from the input unit 1, the instruction is sent to the hardware simulator 4, the virtual execution engine 6, and the user-defined simulator 9.

Upon receiving the instruction to start the test, the hardware simulator 4 displays an image of the refrigerator hardware on the display means 5 based on the hardware information 2. By operating the image using the mouse or keyboard of the input unit 1, the user can generate an event as test data input to the software.

Further, the user-defined simulator 9 controls the temperature of the refrigerator and the freezer as the external environment of the system in addition to the time, the room temperature, the opening and closing of the door, and the ON / O of the compressor.
Simulation is performed based on FF, room temperature, and the like, and the change content is sent to the hardware simulator 4 as an event.

The hardware simulator 4 changes the display of the hardware based on the event by the user operation and the event sent from the user-defined simulator 9, and sends these events to the virtual execution engine 6. The virtual execution engine 6 simulates the operation of the software corresponding to the given event. When the simulated software changes the hardware, the change is sent to the hardware simulator 4,
The hardware display is updated by the hardware simulator 4.

If there is an error in the operation specification 3, no change that would occur in the display of the hardware on the display means 5 occurs, so that the user can discover an abnormality in the software. Note that, in order to realize the above test, specific information and processing contents related to each part of the present apparatus will be described below.

(2-2) Software Information The operation specification 3 input by the user through the input means 1 is a state transition diagram representing the specification of the microcomputer program for controlling the refrigerator. FIG. 2 shows an operation specification 3 represented as a state transition diagram.
FIG.

Here, a state transition diagram (STD: State)
A transition diagram is a diagram of a state transition model. The state transition model is one of the expression forms of software specifications, and includes several possible states 106 (shown by circles in FIG. 2) and transitions 107 between states (shown by arrows in FIG. 2). You. This device converts the software specifications into a state transition diagram (S
TD: State Transition Diagr
am) and can be called an STD simulator.

In the state transition diagram of FIG.
As the transition description 108 representing the content of the transition, a condition (event) that causes the transition and a phenomenon (action) that occurs due to the transition are defined. FIG. 3 is a diagram illustrating an example of a format of an event and an action. As shown in this figure, the event 109 and the action 110 are described by being separated by a delimiter “//”.

FIG. 4 is another example of a state transition diagram, specifically, the operation specification of software for controlling a compressor of a refrigerator. In this example, when the power is turned on, the operation starts from the state init, and in the state reset, when the temperature in the refrigerator is higher than the reference temperature for turning on the compressor (event “refrigerator temperature: ON temperature or more”), the compressor starts operating. (Action "compressor: run") to state on.

As a result of continuing the operation of the compressor in the state “on”, when the temperature drops sufficiently (event “Refrigerator temperature: O
<FF temperature ”) occurs and transits to state protect. In this transition, as an action, the compressor is stopped (action “compressor: stop”) and a protection timer is started (action “protection timer: set”). The state protec while the protection timer is counting
The compressor does not operate even if the temperature inside the refrigerator rises.

In a software test, there can be various types of events. For example, an event such as “open a door” / “close a door” is test data generated by the hardware simulator 4 by a user. Conversely, state transitions and actions are generated by simulation by the virtual execution engine 6 as a result of inputting test data, and the generated results are finally provided to the user through the display unit 5.

(2-3) Hardware Information The hardware information input by the user from the input means 1 is information representing the configuration and operation of the refrigerator as hardware. The hardware information is represented by a state transition model similar to the above for each component constituting the refrigerator. For example, FIG. 5 is a diagram illustrating a state transition in a certain timer.

In this example, when the timer is in the “initial” state, and the virtual execution engine 6 processes the event and the action “set” occurs, the state of the timer transits to “continue” and is set. The counting of the time is started. Also, if an action of “stop” occurs during the continuation of the count, the state of the timer transits to “stop”, and the counting of time is interrupted. When the set time has elapsed, an event of “timeout” is automatically generated, and the state shifts to “end”.

Note that the expression form of the state transition diagram in this example is merely an example, and is not limited to the state transition diagram as long as the data format can represent the equivalent meaning.
Any desired format can be used. For example, to represent a state transition diagram in text, create a list of states including an identifier for each state and a list of transitions using the identifier,
An event and an action may be described for each transition.

(2-4) Changes in External Environment The external environment is an element that is related to the hardware and software of the system but does not constitute the system itself. For example, the temperature inside the refrigerator or the room temperature around the refrigerator is not an element that constitutes the refrigerator itself, but affects the operation of software that controls the refrigerator. As the contents of these changes in the external environment, for example, a mathematical expression for calculating a new numerical value based on some numerical values at a certain point in time is given.

This formula is created based on the following factors. For example, the temperature of the refrigerator compartment or the freezer rises when the door is opened. Further, these temperatures are reduced by the operation of the compressor, but are slightly increased during the defrosting operation. The temperature is less likely to decrease as the content in the refrigerator increases, and harder to cool as the outside air temperature (room temperature) increases. What is necessary is just to create a term using a constant or a function for each of these elements, and create a mathematical expression including the term.

(2-5) Interface with User The above-mentioned software information and hardware information may be created in advance as a file and read into the processing unit when a test is performed. For example, FIG. 6 is a diagram illustrating a schematic configuration example in the case of realizing an STD simulator that is the present apparatus. That is, when the user 111 gives an instruction to the STD simulator 113 through the input unit 112, the STD simulator 113 describes the STD information file 114 in which the operation specification 3 of the microcomputer program to be tested is described and the hardware information 2 of the refrigerator. The read hardware information file 115 is read.
When the change of the external environment is not simulated, the content of the change of the external environment is not essential information. Based on the information thus read, virtual hardware and virtual software are realized by simulation, and a virtual test environment for testing software is constructed.

The exchange of information between the STD simulator 113 and the user 111 is performed by a graphical user interface (GUI) displayed on the video display means 116.
Done through. For example, the GUI display 11 shown in FIG.
Reference numeral 9 denotes a display on the display means 5 by the hardware simulator 4, which is used for displaying the occurrence of an event, for monitoring the appearance of the refrigerator, and for parts having an interface with the outside world, and the like.

The GUI display 120 shown in FIG. 8 is displayed on the display means 5 by the virtual execution engine 6 and is displayed in the ST mode.
It is used for monitoring the state of D and components inside the refrigerator, and for inputting commands for controlling the operation of the present apparatus. Less than,
The description will be given assuming that the user gives various instructions through such a GUI. Instructions such as operation / stop of the device transmitted from the user via the keyboard or mouse are notified to the hardware simulator 4, virtual execution engine 6, clock 7, and user-defined simulator 9 according to the type.

(2-6) Contents of Test In order to start the test, the user operates the control shell on the GUI 120 (FIG. 8) of the virtual execution engine 6.
At 121, a command to start debugging is input.
Here, as a mode of providing test data (event) to the virtual execution engine 6, a manual mode and an automatic mode can be selected.

(2-6-1) Manual Mode In the manual mode, simulation is performed while sequentially inputting events one by one. In the automatic mode, a series of test data input in advance is continuously supplied to software. This is a mode for performing simulation.

When the manual mode is selected, the virtual execution engine 6 starts counting time by transmitting a signal to the clock 7, so that the hardware simulator 4 can generate an event. FIG. 9 is a flowchart showing a schematic procedure of the operation in the manual mode.

That is, in the manual mode, when the user operates the display through the keyboard or the mouse, the hardware simulator 4 generates an event (test data) (step 91). The hardware simulator 4 sends the generated event to the virtual execution engine 6 as data in a predetermined format that can be understood by the virtual execution engine 6 (step 92). The format that the virtual execution engine 6 can understand is, for example, a character string such as “refrigerator door: open;”. Here, FIG. 10 shows a GUI 123 showing the entire refrigerator.
Alternatively, an event 125 is generated by an operation on the GUI 124 indicating a door that is a part of the refrigerator, and the event 12
FIG. 5 is a conceptual diagram showing a relationship that 5 is sent to a virtual execution engine 6.

The virtual execution engine 6 that has received the event
Checks whether a state transition or action occurs due to the received event (step 93), and performs a simulation of the operation specification. Since the result of this execution is provided to the user through the hardware simulator 4 and the display means 5 (step 94), the user generates the next event according to the provided result (step 9).
1).

(2-6-2) Automatic Mode In the manual mode as described above, the user can arbitrarily generate an event and interactive debugging of the program is possible. , To trigger events at the right time,
The following automatic modes are suitable. The following procedure (FIG. 11) is required to generate an event in the automatic mode.

First, the user inputs test data to be generated, and saves the input data as a file 10 (step 111). FIG. 12 illustrates the format of the event information 129 stored in the test data file. In this example, the generation time is specified for each event as the timing to generate.

Next, the user operates the mouse and clicks on the automatically generated event load button 135 on the GUI 119 (FIG. 7) of the hardware simulator 4.
As a result, the contents of the file are read (step 11).
2) Each event included in the file is displayed in the event display window 136 (FIG. 7).

Subsequently, the mode is switched to the automatic mode by clicking the auto button 137 (step 1).
13) If the mode was the manual mode until then, the occurrence of the event by manual as described above is stopped. Then, when a command to start debugging is input from the control shell 121 (FIG. 8), the clock 7 starts counting time and the test is started (step 11).
4). In the automatic mode, the hardware simulator 4 sequentially sends the read events to the virtual execution engine 6 according to the time while referring to the time provided by the clock 7 (step 115).

The user operates the manual button 13
8 (FIG. 7) to return to the manual event generation mode, or click the event clear button 139 to delete the event.

(2-6-3) Effects of Embodiment As described above, in this embodiment, not only test data is generated sequentially but also the generation timing is specified for each event constituting the test data. If so, an event is provided to the software simulation at a designated timing based on the clock 7.
For this reason, it is possible to effectively perform a test in which the timing of an event is a problem, for example, the operation differs depending on the timing at which data is input. FIG. 13 is a timing chart conceptually showing the state of processing for an event by comparing the case of the prior art with the case of the present invention.

That is, when test data is generated only sequentially (sequentially) as in the prior art, for example, when event 1 is input as test data, the corresponding process 1 is immediately performed, and event 2 is input. Then, the corresponding process 2 is performed (example on the left side of FIG. 13).
As described above, conventionally, corresponding processes are always performed in sequence according to an event that is test data. Therefore, it is difficult to perform an effective software test when the presence / absence of processing changes depending on the event input timing.

On the other hand, in the case of the present embodiment, as shown in the example on the right side of FIG. 13, for the test data to be generated, the position on the time axis can be designated as the occurrence time for each event. In this example, the event 2 occurs outside the software, and the event 2 occurs before the process 1 corresponding to the event 1 ends, so that the process 2 is not performed. The temporal element that process 2 is not activated during the time required for process 1 is as follows:
This is realized by time information from the clock 7.

As described above, according to the present embodiment, it is possible to carry out a test in accordance with an actual temporal change, for example, an event occurring during processing by software is not detected.
Therefore, it is possible to effectively perform a test in which timing matters, such as an operation for removing chattering.

(2-7) Operation of Clock Time information used for event generation in the automatic mode as described above is provided from the clock 7. Clock 7
As shown in FIG. 14, the time is counted by counting cycles of a crystal oscillator or the like (step 141), and after a lapse of a predetermined time (step 142), a new time is notified to each simulator (step 143). ,
The procedure from time counting (step 141) is repeated. The clock provides a common time to the entire device by such processing. In the flowcharts of FIG. 14 and subsequent figures, connectors A, B, C, and D indicate that there is a relationship for exchanging information between the respective parts of the apparatus.

(2-8) Operation of Hardware Simulator 4 The refrigerator, which is hardware in such a simulation, is displayed on the display means 5 as a computer graphics image created by the hardware simulator 4. In manual mode, the user
By operating the image with the mouse or keyboard of the input unit 1, an event as test data can be generated. Therefore, there is no need to define and input test data as a character string, and the efficiency of software testing is improved.

For example, when a user wants to generate an event of opening a door for a refrigerator as hardware, the user can use a mouse cursor or button to generate an event as shown in FIG.
The operation of opening the door with the GUI 123 of the refrigerator shown in FIG.
At 124, the open button is clicked with the mouse. As a result, a “door: open;” event 125 in which a part name and a state name are paired is automatically generated and sent to the virtual execution engine 6.

In order to realize such a function, the hardware simulator 4 specifically refers to time information by the clock 7 (FIG. 15) (step 151),
It is determined whether or not the test data generated by the user-defined simulator 9 has been sent (step 15).
2) In some cases (step 153), the display is changed based on the mouse click or the transmitted test data (step 154). When there is no event from the user-defined simulator 9 and in the automatic mode (step 155), an event sequence arranged in the order of the scheduled occurrence time is read in advance, and an event whose current time has passed the scheduled occurrence time is generated. (Steps 156, 15
4,157).

When there is no event from the user-defined simulator 9 and in the manual mode (step 155), when the mouse is clicked (step 158), the display is changed (step 15).
4) Test data is generated (step 157). When the display is updated, the test data is notified to the second execution means (step 157).

The hardware simulator 4 refers to the state change of each component notified from the virtual execution engine 6 irrespective of whether the hardware simulator 4 itself generates test data (step 159), and displays based on the change. Is updated (step 1510). By observing the updated display in this way, the user can determine whether the software is correctly controlling the hardware.

(2-9) Operation of Virtual Execution Engine 6 The virtual execution engine 6 processes the input test data in accordance with the software specification represented by the state transition and refers to the time provided by the clock 7. Change the state of software and products. The processing at this point is performed similarly regardless of the execution form of the simulation.
The execution form of the simulation is, for example, a distinction between a manual mode and an automatic mode. Also,
In addition, a distinction can be made between normal execution and a special form such as step execution of each transition.

Specifically, the virtual execution engine 6 (FIG. 1)
6), referring to the time ticked by clock 7 (step 16)
1) Subsequently, it is determined whether or not an internal event such as a timer timeout has occurred (step 162). Here, the internal event is an event that occurs based on the function of the software regardless of the hardware or the external environment. If an internal event has not occurred, an external event is referenced (step 163). If an internal event or an external event has occurred (step 16).
4) Compare the state transition diagram with the event (step 16)
5).

As a result of this comparison, the transition is fired when any of the transition events that can be fired from the current state is:
This is the case when the given events match. As a result of the comparison, if the transition is fired (step 166), an action is generated to change the state of the part, and the hardware simulator 4 and the user-defined simulator 9 are notified of the change in the state of the part (step 167). The state in the figure is changed (step 168). In this case, the virtual execution engine 6 updates the current state in the STD monitor GUI. FIG. 17 shows the GU for the transitions and actions generated by the virtual execution engine 6.
It is a conceptual diagram which shows the relationship which updates I.

(2-10) Update of Display The hardware simulator 4 notified of the change in the state of the component from the virtual execution engine 6 updates the status of the component monitor GUI. For example, when the action of turning on the lamp occurs, a highlight display indicating the state of the lamp component changes to lighting as shown in a lamp component GUI 126 in FIG. 18, or a refrigerator GUI 1 showing the appearance of the refrigerator.
At 23, a lamp is turned on.

By repeating the process from the generation of the test data to the change of the display, the user can find out the defect of the program. If the lamp does not turn on even after the operation that should have turned on the lamp, it can be considered that there is a problem in the program.

For example, it is assumed that, while the transition content 108 in FIG. 2 is correct, an erroneous transition content that does not include “lamp: turn on” is erroneously input as shown in FIG. In this case, as a result of the event “opening the door” being generated by the hardware simulator 4, the virtual execution engine 6 notifies the user of the transition from the state 1 to the state 2 and the result of the action “run the compressor”. Show. However, the action of “lamp is turned on” is not described because it is not described in the specification, and the virtual execution engine 6 does not turn on the lamp. The user who sees this result finds a defect in the specification.

(2-11) Processing by User-Defined Simulator 9 Further, in the present embodiment, even when the system changes the external environment or the change of the external environment affects the operation of the system, the user-defined simulator 9 Simulates changes in the external environment.

FIG. 20 is a flowchart showing a procedure in which the user-defined simulator 9 simulates a change in the external environment. As shown in this figure, the user-defined simulator 9 receives numerical values indicating the state of the system from the hardware simulator 4 and the virtual execution engine 6 (Step 201), and refers to the time provided by the clock 7 (Step 201). 202). Then, a new value of the numerical value to be simulated is calculated based on the mathematical expression given by the user as the change content (step 203), and the previous numerical value is updated with the calculated new numerical value (step 204). If the calculated temperature changes beyond the reference value (step 205), an event as test data is generated and notified to the hardware simulator 4 (step 206).

The condition of the event occurrence due to the change of the numerical value is as follows.
For example, the temperature may change by one digit,
A boundary value for determining ON / OFF of the compressor may be used. After reflecting the received event on the GUI, the hardware simulator 4 sends the event to the virtual execution engine 6. FIG. 21 is a conceptual diagram showing a state in which an event is sent from the user-defined simulator 9 to the virtual execution engine 6 via the hardware simulator 4.

As described above, the virtual execution engine 6 further simulates the operation of the system on the basis of the change in the external environment simulated by the user-defined simulator 9, thereby obtaining more accurate test results that are more practical. Obtainable. In particular, by simulating a change in the external environment based on the clock 7, a change in the external environment closer to reality can be obtained, and an accurate test can be performed.

(2-12) Saving and Browsing of Test Data The user records the history (history) of the event generated by the user in the hardware simulator 4 through the reproduction history display window 127 of FIG. The information can be always browsed as a set of time. In addition, the user sets the hardware simulator G
History save button 1 for reproduction on UI 119 (FIG. 7)
This history can be seen in FIG.
0 can be stored in the reproduction history file 10 in the same format as the test data 129. If the history clear button for reproduction 130 is pressed, the history is deleted.

The reproduction information 104 recorded in this manner can be used as test data in the automatic mode. Therefore, the simulation when the same test data is used is made more efficient, and the reproduction test of the abnormal operation is facilitated.

(2-13) Viewing History In this embodiment, the virtual execution engine 6 records the history 133 of the event reception, the action occurrence, and the STD state transition occurrence (FIG. 2).
2). The user operates the GUI 120 of the virtual execution engine 6.
Through the browsing history display window 131 shown in FIG. 8, it is possible to always browse these histories arranged in the order of occurrence time. In addition, the user browses the GUI 120 (FIG. 8) of the virtual execution engine 6 and browses history.
By clicking the button 132, this history can be saved in the browsing history file 12 with the contents shown in FIG. History for viewing
When the r button 134 is pressed, the history is deleted.

(2-14) Interruption and Resumption of Simulation In the present embodiment, information for restarting the simulation once interrupted, such as the state of software and hardware, is stored in the restart file 11 at a desired time. be able to. Therefore, in the event that an unexpected event such as a failure or accident occurs after storage, various tests can be implemented by re-starting the work from the point of recording or resuming the work at a later date according to the schedule. Can be.

In particular, when a test performed automatically using the recorded test data requires a long time, restart information is stored when the test data is reproduced halfway, and restarted later. By doing so, it is possible to automatically perform a test that requires a long time and to divide the test according to a schedule. For this reason, the degree of freedom of the test operation is improved.

More specifically, when recording the status during the software test, the control shell 121 is used.
From FIG. 8, a command to save information in the restart file 11 is input. As a result, the current state of the STD,
The state, time, and the like of the component are recorded in the restart file 11. Specific contents of the restart information include, for example, the state of each component included in the hardware (including the time of the timer and the count number of the counter), the state of the software expressed by the state transition model, and the clock 7. When the user-defined simulator 9 is used, each value such as temperature can be listed.

When resuming the debugging that has been suspended,
What is necessary is just to input the command which loads the file 11 for restart from the control shell 121 (FIG. 8). As a result, the virtual execution engine 6 sets the status of the STD and the components according to the file. Next, the virtual execution engine 6 sends a signal to the hardware simulator 4 and the user-defined simulator 9 to set the state of the component in accordance with the contents of the restart file 11, and sends a signal to the clock 7 to set the time. Send According to these signals, the hardware simulator 4, the user-defined simulator 9, and the clock 7 also acquire necessary information from the restart file 11, respectively, and the test is restarted.

(2-15) Effects of Embodiment As described above, in this embodiment, even if the hardware is not completed, if the hardware information 2 on the hardware configuration and operation is input, the hardware The operation is displayed on the display means 5 by the simulation of the hardware simulator 4. Then, when the displayed hardware is operated by the input means 1 such as a mouse, test data to be given to the software is also generated. Even if specific software such as mnemonic code is not completed, if the operation specification 3 of the software is input, the virtual execution engine 6
Thus, the operation of the software is simulated using the test data, and when the hardware operates under the control of the software, the operation appears on the display of the display unit 5.

For this reason, even if the hardware and software are not completed at the early stage of development, test data is given to the software in the same environment as using the actual hardware (real machine), and the software is tested. be able to. As a result, the development time of the product can be shortened, and the detection of the specification defect which has been conventionally performed by the developer can be assisted, thereby significantly improving the accuracy and efficiency of software debugging.

Since the simulation of the hardware and software is performed based on the information on the time provided by the clock 7, an accurate simulation according to the actual operation timing is realized.

(3) Other Embodiments The present invention is not limited to the above-described embodiments, but includes other embodiments as exemplified below. For example, the present invention can be implemented not only for software testing but also for software execution itself. Further, in the automatic mode of the above-described embodiment, in order to improve operability, the user stops the apparatus at the time of occurrence of a malfunction, or stops the apparatus at an arbitrary time, and slowly adds a new component. It is necessary to be able to see the status of the problem and to go back to the history to find the faulty part. In order to support such operations, it is desirable to provide the following functions.

For example, the virtual execution engine GUI 120
A command to interrupt the test (debug) is input from the control shell 121 (FIG. 8). As a result, a signal is transmitted to the clock 7 and the counting of time is stopped, so that occurrence of the event is stopped and debugging is stopped. By stopping debugging at a point of interest, the user can check the information displayed on each GUI at that time.

Also, a command (eg, “cont”) for executing a step to execute debugging for one transition is input from the control shell 121 of the virtual execution engine GUI 120 (FIG. 8). As a result, the virtual execution engine 6
Continues the processing of the event and, at the time one STD transition occurs, sends a signal to stop time counting to clock 7
Stop debugging by sending to. If the number of transition steps to be executed is specified as an optional parameter of the command, such as “cont 5”, debugging is stopped when n transitions have been executed. In this way, it is possible to examine the information in detail while proceeding with debugging for each part which is considered to be the cause of the defect in units of transition.

Further, the virtual execution engine GUI 120
By inputting a command for setting a breakpoint from the control shell 121 (FIG. 8),
Set breakpoints (stop points) at desired locations in the software. Breakpoints may be set in units of STD states or events. If a breakpoint is set in the transition destination state when a state transition occurs, the virtual execution engine 6 stops debugging and sends a signal to the clock 7 to stop time counting. As a result, even for the parts that execute at high speed, the execution of the software is surely stopped at the intended places,
It becomes easy to consider necessary information.

In the above embodiment, the hardware simulator 4, the virtual execution engine 6, the clock 7, and the user-defined simulator 9 are realized by processes, but they need not necessarily be realized by processes.
In addition, signals are used for communication between processes, and files are used for recording history and resumption information, but these can also be realized in a free manner.

For example, the hardware simulator 4, the virtual execution engine 6, and the user-defined simulator 9 are realized as objects (instances) in an object programming oriented language, and messages can be used for communication between the objects. Further, the recording of the history and the information for resumption can be performed by saving the contents (snapshot) of the entire used area of the memory in a predetermined area of the external storage device without using the file format.

In the above embodiment, the test data is generated by operating the virtual hardware realized by the hardware simulator 4. However, the hardware simulator 4 does not necessarily need to be configured in such a manner. The data may be provided externally in the form of a file or the like. Further, a configuration in which the contents of change 8, the user-defined simulator 9, the history file for reproduction 10, the file for resumption 11, and the history file for browsing 12 in the above embodiment are not provided is also conceivable.

[0107]

As described above, according to the present invention,
Because the hardware and software simulations are controlled according to the actual operation timing, the accuracy and efficiency of software execution is greatly improved.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing the configuration of an embodiment of the present invention.

FIG. 2 is a diagram showing a simplified operation specification 3 represented as a state transition diagram in the embodiment of the present invention.

FIG. 3 is a diagram showing an example of a format of an event and an action in the embodiment of the present invention.

FIG. 4 is a diagram showing another example of the state transition diagram according to the embodiment of the present invention.

FIG. 5 is a diagram showing a state transition of a certain timer in the embodiment of the present invention.

FIG. 6 is a diagram showing an embodiment of the present invention;
The figure which shows the example of a schematic structure when realizing a TD simulator

FIG. 7 is a display example of a GUI displayed on the display unit 5 by the hardware simulator 4 in the embodiment of the present invention.

FIG. 8 is a display example of a GUI displayed on the display unit 5 by the virtual execution engine 6 in the embodiment of the present invention.

FIG. 9 is a flowchart showing a schematic procedure of an operation in a manual mode in the embodiment of the present invention.

FIG. 10 shows a GUI 123 showing the entire refrigerator or a GUI showing a door as a part of the refrigerator in the embodiment of the present invention.
Event 125 is generated by an operation on 124,
Conceptual diagram showing the relationship that this event 125 is sent to the virtual execution engine 6

FIG. 11 is a flowchart showing a schematic procedure of event occurrence in an automatic mode in the embodiment of the present invention.

FIG. 12 is a diagram showing an example of a format of event information according to the embodiment of the present invention.

FIG. 13 is a timing chart conceptually showing the state of processing for an event by comparing the case of the prior art with the case of the present invention.

FIG. 14 is a flowchart showing an operation procedure of a clock in the embodiment of the present invention.

FIG. 15 is a flowchart showing an operation procedure of the hardware simulator 4 in the embodiment of the present invention.

FIG. 16 is a flowchart showing an operation procedure of the virtual execution engine 6 in the embodiment of the present invention.

FIG. 17 is a diagram illustrating an example of a GU according to the embodiment of the present invention regarding a transition and an action generated by a virtual execution engine 6;
Conceptual diagram showing the relationship for updating I

FIG. 18 is a display example of a GUI showing a state of lamp parts constituting a refrigerator in the embodiment of the present invention.

FIG. 19 is an example of an erroneous transition content that does not include “lamp: turn on” in the action in the embodiment of the present invention.

FIG. 20 is a flowchart showing a procedure in which the user-defined simulator 9 simulates a change in the external environment in the embodiment of the present invention.

FIG. 21 is a conceptual diagram showing a state in which an event is sent from the user-defined simulator 9 to the virtual execution engine 6 via the hardware simulator 4 in the embodiment of the present invention.

FIG. 22 is a diagram showing a format of a history such as an event recorded by the virtual execution engine 6 in the embodiment of the present invention.

Claims (10)

[Claims] 1. A software execution device for testing software used for controlling hardware, comprising: first execution means for forming virtual hardware on a computer based on information on the hardware; A second execution unit that executes software to be executed on the virtual hardware, based on predetermined data for testing the first execution unit and the second execution unit; Control means for controlling the virtual hardware and the operation timing of the software so as to correspond to the actual operation timing. 2. The software execution device according to claim 1, wherein the predetermined data is generated by operating virtual hardware on a first execution unit. 3. When a series of events whose occurrence timings are specified as given data are given as predetermined data, the first execution means specifies each event based on control by the control means. 3. The software execution device according to claim 1, wherein the software execution device is configured to send to the second execution means at the timing. 4. A definition means for defining a change content of an external environment related to the target system, an operation of the system, and a change of the external environment based on the defined change content. 4. The software execution device according to claim 1, further comprising a third execution unit provided to the second execution unit. 5. A storage device for storing predetermined data obtained from the first execution unit, wherein the first execution unit reads out the stored predetermined data and executes a second execution unit. The software execution device according to claim 1, 2, 3, or 4, wherein the software execution device is configured to send the data to the software execution device. 6. A second information for storing at a desired time information necessary for restarting each of the simulations after the interruption.
6. A storage means for resuming each simulation using the stored information, and a restart means for restarting each simulation.
A software execution device as described. 7. A software execution method for testing software used for controlling hardware, comprising: a first execution process for forming virtual hardware on a computer based on information on the hardware; A second execution process for executing software to be executed on the virtual hardware based on predetermined data for testing, and a first execution process and a second execution process. A control process for controlling operation timing of the virtual hardware and its software so as to correspond to actual operation timing. 8. The software execution method according to claim 7, wherein the predetermined data is generated by operating virtual hardware by a first execution process. 9. A method according to claim 1, wherein when a series of events whose occurrence timings are specified are given as predetermined data, each of the first execution processes is specified based on control by the control process. 9. The software execution method according to claim 7, wherein the method is provided for the second execution process at the timing. 10. A definition process for defining a change content of an external environment related to the target system; an operation of the system; and a change of the external environment based on the defined change content. 10. The software execution method according to claim 7, further comprising a third execution process provided for the second execution process.