JPH11194960A - Software testing equipment - Google Patents

Abstract

(57) [Summary] [PROBLEMS] To enable software testing even when hardware is not completed, and to continue testing when hardware is partially completed. A target development environment includes a target development environment as an operation environment of a target software and a host environment as a work environment for testing the PRG. The target development environment includes a PRG to be tested and the PRG. The control means 105 for controlling each HW device group that constitutes the hardware (HW) 300 to be controlled by the control means 105 and whether information to be exchanged with the PRG based on the device control input / output distribution information is on the control means 105 side The target development unit has a distribution unit 103 for switching control of whether to be on the side of the target communication unit 106 and a change unit 107 for changing device control input / output distribution information. Side communication means 201 and H
Physical level virtual HW realization means 2 that virtually realizes the operation of W
02 and a logical level virtual HW realizing means 207 for virtually realizing an environment in which human operations on the HW are possible.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software test apparatus capable of practically and effectively verifying and debugging a program incorporated in a product. The present invention relates to a software test apparatus capable of efficiently debugging and verifying the operation of a program under development that is proceeding in parallel.

[0002]

2. Description of the Related Art In many electric and electronic products such as air conditioners, electronic rice cookers and refrigerators, and various electric and electronic products such as portable telephones and information devices, the control of a microprocessor (CPU) is central to control. Software control is the mainstream, and the microcomputer control circuit as hardware built into the product and the program as control software are inseparably integrated.

Therefore, when a product is developed, software for controlling the hardware is developed concurrently with development of hardware for controlling the product. Then, in order to intensify competition, product development needs to be done in a short time.

[0004] Therefore, when a new product is developed, it is necessary to push hardware and software at the same time, and the operation verification and debugging of the software for controlling the completed hardware are very difficult during the product development period. The final stage.

[0005] Testing and debugging for operation confirmation are indispensable for software development. Conventionally, testing of software to be incorporated into hardware is performed by using the hardware after the completion of the hardware to be incorporated. It was done. Therefore, if the hardware is incomplete,
Testing the software was difficult.

As a result, the software test and the hardware development cannot be performed simultaneously, resulting in a problem that the development period of the product becomes long and does not meet the actual situation of the product development.

[0007] In addition, a test in which many pieces of hardware are connected at a time in a short period of time is a very complicated operation, and therefore, there is a possibility that software errors are overlooked.
It was also difficult to improve work efficiency. Furthermore, if there is an error in the developed hardware device itself, in the worst case, the erroneous software will be tested using the erroneous hardware. It could be a very difficult task.

[0008] As a general method for solving such a problem, there is a use of a CPU simulator. This CPU simulator simulates the operation of a target CPU on a host computer, thereby enabling execution of software without using any hardware.

However, there is a limit on the operation of software that can be executed using the CPU simulator.

For example, in the case of an operation that waits for an input from a hardware device such as a sensor and uses the value, it is difficult to realize the operation of waiting for the above input using only a CPU simulator.

[0011] In the above case, the CPU simulator alone cannot actually connect to a hardware device, and cannot connect to a peripheral circuit of the CPU. This cannot be done in practice.

[0012]

In recent years, products controlled by microcomputers have been steadily increasing, and the product development cycle of consumer products has been shortened due to intensifying competition. Therefore, when developing a new product, hardware and software must be pushed in parallel,
Verification and debugging of the software that controls the completed hardware is the final stage of product development.

[0013] Testing and debugging for operation confirmation are indispensable for software development, but testing of software to be incorporated in conventional hardware involves waiting for completion of the hardware to be incorporated and then actually using the hardware. There are a method of performing the method and a method of using a CPU simulator.

In the former case, since actual hardware is used, software testing cannot be performed if the hardware is incomplete. 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 and does not match the actual situation of product development.

In the latter half of the product development period, a software test is performed when the hardware is ready, so the operation is difficult and there is a possibility that a sufficient test cannot be performed. That is, a test in which many pieces of hardware are connected at one time is a very complicated operation, and therefore, there is little possibility that software errors are missed, and it is difficult to improve the efficiency of the operation.

Furthermore, if there is an error in the developed hardware device itself, in the worst case, the erroneous software will be tested using the erroneous hardware, and the detection of those errors and the Investigation into the cause may still be a very difficult task, which is a major bottleneck.

On the other hand, in the method using a CPU simulator, software can be executed without using any hardware by simulating the operation of a target CPU on a host computer. There is a limit on the operation of software that can be executed using the CPU simulator.

For example, in the case of an operation that waits for an input from a hardware device such as a sensor and uses the value, it is difficult to realize the operation of waiting for the above input using only a CPU simulator.

This is because, in the case described above, the CPU simulator alone cannot actually connect to a hardware device, and cannot connect to a peripheral circuit of the CPU. This cannot be done in practice.

As a technique for solving the above-mentioned problems associated with software execution using a CPU simulator, a "program simulation apparatus" (Japanese Patent Application No. 5-227401, Japanese Patent Application No. 6-3
No. 6124, Japanese Patent Application No. 6-217128). In this technique, a peripheral circuit connected to a CPU and a hardware device are created as software on a host computer in the above-described case, and the operation of the peripheral circuit and the hardware device is simulated. It enables the execution of software that has input and output with the device. Furthermore, the operating system functions that are implemented and used on the target are also realized on the host computer, and the operations such as the above-described interrupt processing can be executed in exactly the same manner as on the target.

However, in the “program simulation device”, all software is stored in the C on the host computer.
The simulation was executed one by one on the PU simulator. Furthermore, peripheral circuits and hardware devices have also been simulated on the host computer.

For this reason, the execution speed of the software is extremely slow as compared with that of the target computer (for example, it takes tens to hundreds of times), and is therefore important for the execution of the software for testing. In many cases, tasks such as "repeated execution", "long-time execution", and "confirmation of execution time" require a great deal of labor and time.

Furthermore, the relative speed with respect to the operation of the hardware cannot be easily predicted, and there is a possibility that the operation which is far from the execution of the software on the actual target machine may be tested. Not a few.

In software development in microcomputer-controlled product development, tests using actual hardware are important. However, when developing software, it is important to check the reliability of its operation, and in order to obtain a complete program without bugs, the time required for debugging must be considerably taken into consideration. While verifying the operation, as soon as the actual hardware is completed, it is necessary to verify the operation of the software using the completed hardware. In the case of a wide variety of hardware, the emergence of a development environment in which completed hardware can be sequentially incorporated into the completed hardware to enable comprehensive verification of software and debugging can be expected. It had been.

In particular, technology capable of executing source code to confirm and debug operation of software in a range including input / output with hardware at a sufficiently high execution speed without limiting the mounting method. Development is important.

Therefore, an object of the present invention is to enable a test of target software under the same environment as when target hardware actually exists, even if the target hardware is incomplete. It is an object of the present invention to provide a software test apparatus which can execute a test of target software using the completed target hardware when the hardware becomes available.

[0027]

In order to achieve the above object, the present invention is configured as follows. That is, in a software test apparatus that tests target software used for controlling target hardware that is target hardware, a target development environment that is an operating environment of the target software and a work environment for testing the software. A target environment to be tested, hardware device control means for controlling each hardware device group constituting hardware to be controlled by software, and a hardware device control input device. A hardware device control input / output distribution unit that controls whether information to be exchanged with the target program based on the output distribution information is switched to the hardware device control program side or the target side communication unit side;
Hardware device control input / output distribution information changing means for changing hardware device control input / output distribution information; and a host development environment for transmitting / receiving information to / from the target side communication means. And physical level virtual hardware realizing means for virtually realizing the operation of the target hardware, and logical level virtual hardware realizing means for virtually realizing an environment enabling artificial operation on the target hardware It is characterized by.

The present system provides a cross development environment composed of a target development environment which is an operation environment of software to be executed, and a host environment which is a work environment for testing the software.

The software to be tested is divided into a hardware device control program and a target program. The former is completely dependent on the hardware device, and the latter is less dependent on the hardware device.

For testing, it is necessary to manipulate the state of each hardware device. Therefore, in this system, the hardware device control input / output allocating means operates the hardware device of the actual hardware or exchanges the control input / output with the host environment, and virtualizes the hardware device on the host. Or can be selectively implemented.

The target-side communication means exchanges information with the host-side communication means, thereby enabling a virtual operation of a hardware device on the host.

Since the target program exchanges information with the hardware device via the hardware device control register even during the test in which the above selection is performed, it is not necessary to consider at all what selection is being performed based on the selection. Absent.

By making the hardware device control input / output distribution means refer to the hardware device control input / output distribution information, the above selection can be flexibly changed according to the product and the development status of the product. it can.

The hardware device control input / output distribution information can be dynamically rewritten by the hardware device control input / output distribution information changing means during execution of the software. And the operation of a virtual hardware device on the host can be dynamically selected.

In the host environment, physical level virtual hardware allows manipulation and reference of the state of each hardware device at the physical signal level.

The physical level virtual hardware holds the state of each hardware device at a physical signal level.

When the target level program notifies the hardware device that a new request has been issued to the hardware device through the host-side communication means, the physical level virtual hardware responds to the request by rewriting the physical level virtual hardware. Update the status of the corresponding hardware device. Physical level virtual hardware is used when the status of a hardware device is updated by a user operation.
The status change information of the hardware device is notified from the host communication means to the target program via the hardware device control input / output distribution means. In this way, even if there is a hardware device that is not actually connected, the target program can be executed without any consideration.

In the present system, in the host environment, the logical level hardware enables the operation and reference of the state of each hardware device at a logical semantic level. That is, the logical-level virtual hardware holds the state of each hardware device at a logical meaning level. Further, the host environment is provided with hardware information abstraction degree conversion means for converting the information of the signal level into the information of the semantic level and reading out the hardware state from the physical level virtual hardware to the logical level virtual hardware. By transmitting the information of the semantic level from the logical level virtual hardware to the hardware information abstraction level converting means and converting the level of the abstraction into the information of the signal level so that the hardware state is mapped to the physical level virtual hardware. Accordingly, it is possible to execute software while virtually operating a hardware device at a logical level even for a hardware device that is not actually connected.

At the time of conversion, the hardware information abstraction degree conversion means uses conversion information describing a conversion method and physical-logical correspondence information describing correspondence between information at a meaning level and information at a signal level, Virtual hardware is
The logical-level information is managed using the physical-logical correspondence information.

The conversion information and the physical-logical correspondence information are information dependent on each product, and need to be replaced for each product.
Except for one piece of information, it can be realized completely product-independent.

Although the target side basically depends on the chip used, etc., using the configuration proposed by the present invention,
By standardizing the protocol used in the target-host communication means, the host-side environment can be realized as a general-purpose one.

According to the present invention, in order to realize a sufficient execution speed in software execution for the purpose of a test, a system in which a target microcomputer and a host computer are directly connected using a target-host communication means is employed. ing.

Thus, since the software operates on the actual target CPU, the execution speed does not become extremely slow unlike the case of using a CPU simulator. Further, in the present invention, in order to enable execution of software up to a range including input / output with a hardware device,
The configuration of software to be executed is unified into a format for controlling hardware via a hardware device control register. This is not particularly limited as a method of implementing software to be incorporated in the product targeted by the present invention.

In the present invention, a hardware device control input / output distribution unit exists by accessing the control register. By referring to the hardware device control input / output allocation information, the allocation unit can flexibly change the connection configuration of the hardware device and execute software according to the situation at the time of the test. . For hardware devices that are not connected,
The operation of the hardware is simulated on the host computer, and the input and output are realized through the communication means.

In the simulation of a hardware device on a host computer, physical level virtual hardware that can directly interact with a target and logical level virtual hardware that is described by introducing product knowledge that is more understandable to humans are described. To achieve. As a result, it is possible to select a necessary level of abstraction and perform a test depending on the time of the test, and to perform a highly reliable test with a small burden on humans.

The present invention provides a hardware as a means for realizing the conversion of the information abstraction level required for realizing the logical level virtual hardware from the information on the abstraction level possessed by the physical level virtual hardware. It includes an information abstraction conversion unit.

By using the conversion information and the physical-logical correspondence information, the gap in the meaning of the information can be filled, hardware simulations at different levels can be performed, and tests at different levels using them can be performed. I do.

[0048]

Embodiments of the present invention will be described below with reference to the drawings.

The present invention is a system for supporting debugging of a program incorporated in a product having microcomputer control hardware, and is an improvement of a software execution device and a software execution method for testing software for operating hardware under development. It is intended. In particular, by simulating a part (or all) of the hardware that must be connected to execute the software so as to correspond to the actual operation timing by the software, the hardware is not dependent on the development status of the hardware. To be able to perform accurate tests.

Conventional software operation verification methods include a method of assembling a microcomputer program and hardware into a product form (actual device test) and a method of using an emulator. The program cannot be debugged until it is completed. Further, a plurality (many) of program developers cannot perform debugging due to the limitation of hardware.

In the case of a method of verifying the operation of a microcomputer program using an emulator, a user needs to input information or connect to hardware in order to perform debugging including input / output of hardware. is there.

On the other hand, in the system of the present invention, part or all of the hardware is virtually prepared on a PC (personal computer), and necessary hardware is required between the virtual hardware and a target program (software being developed). In addition to being able to exchange data, completed hardware can also be connected, and with this completed hardware, data can be directly exchanged with the target program to verify operation. By doing so, it is possible to realize a system capable of checking and debugging the operation of a program without waiting for completion of hardware or while adding completed hardware as needed.

Hereinafter, the present invention will be described in detail.

FIG. 1 shows the system configuration. The components of this system are as shown in FIG.
0 and the host machine-side system 200, and if there is completed real hardware 300 as target hardware, the real hardware 300 is connected to the target-side system 100 instead of the host machine-side system 200. Can test. In this case, the virtual hardware of the host machine-side system 200 which has performed the function of the connected real hardware 300 is not only unnecessary, but if it conflicts, a malfunction may occur. 104 is changed so that the hardware device control input / output allocation unit 103 allocates the control input / output to the function of the connected real hardware 300 so as to use the real hardware 300.

That is, since the real hardware 300 cannot be used during the development stage, the host machine side system 200 is connected to the target side system 100 having the target program 101 to be verified until the completion, until the completion. To Host machine side system 2
00 has a function of realizing virtual hardware for simulating the target hardware, connects the target system 100 and the host machine system 200, substitutes the hardware, and tests the target program. When the real hardware 300 is completed, the real hardware 300 is connected to the target system 100 in place of the virtual hardware of the host machine system 200 and tested.

Not all of the real hardware 300 need be completed, and even if it is a part, the part of the real hardware 300 is replaced with the virtual hardware of the system 200 on the host machine side when the part is completed. Others can be connected to the system 100 and tested on behalf of virtual hardware.

In the host machine 200, the host-side communication unit 201, the logical level virtual hardware 207, the hardware information abstraction degree conversion unit 203, and the physical-logical correspondence information 2
06, conversion information 205, physical level virtual hardware 2
02, and an execution control unit 204.

The target side 100 includes a target program 101, a hardware device control register 10
2. Hardware device control input / output distribution unit 10
3. Hardware device control input / output distribution information 10
4. Hardware device control program 105, hardware device control input / output distribution information change unit 10
7, a target communication unit 106 and a hardware main body.

The target side 100 and the host side 200 are connected by target-host communication means 208.

When the target hardware 300 and the target software 101 are combined, it is possible to confirm that the software 101 is operating correctly as specified by operating the hardware and observing the reaction to the hardware.

On the other hand, only a part of the hardware is completed, or all the hardware is not yet completed.
In such a situation that the host machine cannot be used, the host machine side 200 can operate the hardware as if the real target hardware is connected and can see the reaction and perform the same debugging work as described above. Prepare virtual hardware.

Then, the target program 101 is debugged while operating the virtual hardware as if it were real hardware.

The hardware device control register 102 in FIG. 1 is used to buffer events from hardware / virtual hardware and actions from the target program 101. It determines which of the events sent from the real hardware / virtual hardware is to be transmitted to the target program 101 and whether the action output from the target program 101 is to be transmitted to the real hardware or the virtual hardware. The hardware device control input / output allocation information 104 is information used by the hardware device control input / output allocation unit 103 for allocation, and is used for hardware device control input / output allocation. It can be changed by the broadcast changing unit 107.

The hardware device control program 105 is for bridging the exchange between the target program 101 and the real hardware 300. The hardware device control program 105 transmits an event detected in the hardware 300 to the target program 101 and responds to the action. This controls the operation of the hardware 300. Further, the target-side communication unit 106 is in charge of transmitting an action to the host machine / receiving an event.
Also, hardware device control input / output distribution information 1
04 is transmitted / received.

The hardware device control input / output distribution information change unit 107 changes the hardware device control input / output distribution information 104 or returns the distribution information to the host in response to a request from the host. Also, when a change request is received, it has a function of reflecting the change request in the corresponding distribution information.

The host communication unit 201 is connected to the target 10
0 is responsible for sending and receiving data to and from the virtual hardware,
The sorting information change / viewing request sent from 04
Processing is performed on transmission data in accordance with a predetermined protocol, and the processed data is transmitted. In addition, the received data is expanded to extract an action or a result of a browsing request.

The physical-level virtual hardware 202 is virtual hardware on the host machine 200 that expresses the state / operation of the hardware at the level of the data handled in the target 100. In addition to operating / observing the hardware 207, the target program 101 can be debugged by operating / observing the virtual hardware 202 at this physical level. The virtual hardware that can directly exchange with the target program 101 is the physical level virtual hardware 202.

The hardware information abstraction degree conversion unit 203
Events / actions from physical level to logical level,
Conversely, it converts from a logical level to a physical level.

The execution control unit 204 is a user interface prepared on the host machine 200 side for operating the hardware device control input / output distribution information to switch between real hardware and virtual hardware. The conversion information 205 is information necessary for conversion between a logical level and a physical level of an event / action, and is prepared for each product.
To convert a logical level event to a physical level, or a physical level action to a logical level, each event / action and a conversion routine name,
This is information that consists of the corresponding arguments.

The logical-level virtual hardware 207 simulates the state / operation of the hardware on the host machine in an expression that can be easily understood by the user.
When you interact with this virtual hardware, events occur,
When the action returns, the state of the virtual hardware changes.

The target-host communication means 208
The communication between the target 100 and the host machine 200 is enabled. For example, a line such as a serial line or a parallel line and a protocol for transmitting data to the line are determined. The communication is performed according to the following.

This system is a software execution device for testing software used for controlling target hardware, and has the following features.

That is, the present invention provides a cross development environment including a target development environment, which is an operation environment of software to be executed, and a host environment, which is a work environment for testing the software.

The target development environment includes a hardware 300 to be controlled by software, a hardware device control program 105 for controlling each hardware device group constituting the hardware, and a hardware device control input / output distribution unit. 103, hardware device control input / output distribution information 104, and hardware device control input / output distribution information change unit 107
, A hardware device control register 102, a target program 101, a target-side communication unit 106
Consists of

The host development environment includes a physical level virtual hardware 202, an execution control unit 204, a hardware information abstraction degree conversion unit 203, and physical-logical correspondence information 206.
, Product-specific conversion information 205, logical-level virtual hardware 207, and host-side communication unit 201.

The software to be tested is divided into a hardware device control program 105 and a target program 101, the former being completely dependent on the hardware device, and the latter being less dependent on the hardware device. . The hardware device control register 102 is a shared area for managing between the above two programs. If the hardware device control register 102 is standardized and shared, the target program can be independent of the hardware device.

The distribution of real hardware and virtual hardware is as follows.

For software testing, it is necessary to manipulate the state of each hardware device.

The hardware device control input / output allocating unit 103 operates the hardware device of the actual hardware or virtually controls the hardware device on the host by exchanging the control input / output with the host environment. Or can be selectively realized.

The target communication unit 106 exchanges information with the host communication unit 201, thereby enabling a virtual operation of a hardware device on the host.

Even during the test in which the above selection is made, the target program 101 exchanges information with the hardware device via the hardware device control register 102, so that the selection based on the selection of the test is totally considered. No need.

By making the hardware device control input / output allocation section 103 refer to the hardware device control input / output allocation information 104, the selection can be flexibly changed according to the product and the development status of the product. be able to.

The hardware device control input / output distribution information change unit 107 dynamically rewrites the hardware device control input / output distribution information 104 according to information from the execution control unit 204 on the host side during execution of the software. Even during execution, the operation of the actual hardware device and the operation of the virtual hardware device on the host can be dynamically selected in accordance with an instruction from the host.

The realization of virtual hardware at the physical level is as follows.

In the host environment, the physical level virtual hardware 202 enables the manipulation and reference of the state of each hardware device at the physical signal level.

The physical level virtual hardware 202 holds the state of each hardware device at a physical signal level.

The physical level virtual hardware 202 communicates with the target program 1 through the host side communication unit 201.
When the hardware device 01 is notified that a new request has been issued, the status of the corresponding hardware device in the physical level virtual hardware 202 is updated in accordance with the request.

When the status of a hardware device is updated by a user operation, the physical-level virtual hardware 202 transmits the status change information of the hardware device from the host side communication unit 201 to the hardware device control input / output distribution unit. 103, Notify the target program 101 via the hardware device control register 102. By doing so, the target program 10
1 can be performed without considering any hardware devices that are not actually connected.

In the host environment, the logical level virtual hardware 207 enables the operation and reference of the state of each hardware device at a logical semantic level. The logical-level virtual hardware 207 holds the state of each hardware device at a logical meaning level.

The information of the semantic level from the logical level virtual hardware 207 is transferred to the hardware information abstraction conversion unit 203.
The hardware state is mapped to the physical level virtual hardware 202 by performing the abstraction conversion into signal level information. This makes it possible to execute software while virtually operating the hardware device at a logical level even for a hardware device that is not actually connected.

The hardware information abstraction degree conversion unit 203 converts the signal level information to the meaning level information to convert the hardware state from the physical level virtual hardware 202 to the logical level virtual hardware 207. Can read aloud. As a result, even for hardware devices that are not actually connected,
The software can be executed while monitoring the state of the hardware device at a logical level.

The hardware information abstraction degree conversion unit 203
At the time of conversion, conversion information describing a conversion method and physical-logical correspondence information 206 describing correspondence between information at a meaning level and information at a signal level are used.

The logical-level virtual hardware 207 uses the physical-logical correspondence information 206 to manage logical-level information. <Debug Flow> Next, a general flow of how to perform debugging will be described.

The user can select the hardware 300 or
The logical level virtual hardware 207 / physical level virtual hardware 202 can be operated. This operation is sent to the target program 101 as an event,
The target program 101 returns an action corresponding to the event to the (virtual) hardware.

The developer (user) checks the behavior of the (virtual) hardware and checks whether the target program 101 operates incorrectly.

In order to describe the flow of the entire system, a case where a user operates the logical level virtual hardware 207 will be mainly described (see FIG. 2).

Here, the event means the hardware 30
0, or in response to a change in state occurring in the virtual hardware 202, 207, the target program 10
This is information that is transmitted to 1.

For example, assuming that the product is a refrigerator, a temperature sensor, which is one of (virtual) hardware, transmits a temperature change to a program as an event.

The action means that the target program 101 controls the (virtual) hardware.
This is information to be transmitted to (virtual) hardware. Taking the case of a refrigerator as an example as described above, the target program 101 transmits a command to start operation to the compressor as an action in response to the event of the temperature rise.

The difference between the logical and physical levels in virtual hardware will be described.

Here, “hardware information (behavior) that the user can understand intuitively” is “logical level”,
“Hardware information that can be understood by the target CPU” is called “physical level”.

For example, "opening and closing of a refrigerator door" is described in [1]. Express with a graphic.

[2]. It is represented by bit data “0” and “1” at the fifth bit of the address. If there are two ways of expressing, of these,
[1] is a logical level virtual hardware 207,
[2] is physical level virtual hardware 202. Since the actual hardware 300 is the actual hardware to be controlled, if the actual hardware 300 can be used, the actual hardware 300 is actually used.
Manipulate itself.

In the case of the logical level virtual hardware 207 / physical level virtual hardware 202, an event is generated by operating a user interface (GUI or the like) prepared respectively. The user interface has a graphic representation of the hardware appearance,
Various things such as graphs, buttons, text input and output are available.

When the user operates the logical-level virtual hardware 207, a change in the operation correspondence is displayed on the virtual hardware (GUI), and the corresponding event is sent to the hardware information abstraction degree conversion unit 203. For example, when the “door” of the virtual refrigerator is opened, information corresponding to “door, open” is sent to the hardware information abstraction degree conversion unit 203. (Figure 2
P1) The hardware information abstraction degree conversion unit 203 converts the sent event from a “logical level (a level that can be understood by the user)” based on physical-logical correspondence information and conversion information prepared for each product. It is converted to a “physical level (a level that can be understood by the target CPU)”.

For example, the event “door, open” is replaced with information such as “set the third bit of address“ 101A ””. This physical level event information is sent to the physical level virtual hardware 200 (P2 in FIG. 2).

In order to maintain consistency with the logical-level virtual hardware, the state of the physical-level virtual hardware is changed based on the sent event. The event is subsequently sent to the host communication unit 201 (P in FIG. 2).
3).

The host-side communication section 201 processes the received event into communication data according to the protocol specified by the target-host communication means 208, and sends out the data to the target side (P4 in FIG. 2).

The event sent from the host is received by the target communication section 106 on the target side. The target-side communication unit 106 expands the transmitted data according to a prescribed protocol, and sets “address“ 1 ”.
Event information corresponding to "set the third bit of 01A" is extracted. The extracted event is stored in a temporary reception buffer, and an input request is issued to the hardware device control input / output distribution unit 103 (P5 in FIG. 2).

On the other hand, an event that occurs when the real hardware 300 is operated is sent to the hardware device control program 105. When the door of the actual refrigerator is closed, an electric signal is sent to the peripheral circuit, and “address“ 1 ”
01A "is the event information corresponding to" reset the third bit of ".
(P6 in FIG. 2).

Hardware device control program 10
5 sends the event sent from the hardware 300 to the hardware device control input / output distribution unit 103 (P7 in FIG. 2).

When both the real hardware and the virtual hardware are connected, the hardware device control input / output distribution unit 103 determines whether the event sent from the host-side virtual hardware (P5 in FIG. 2) Which of the events sent from the hardware 300 is transmitted to the target program 101 is determined based on the hardware device control input / output distribution information 104.

The distribution information is provided for each hardware.
For example, assuming that the event relating to the “door” is determined to use the virtual hardware, the event “set the third bit of the address“ 101A ”” sent from the virtual hardware is Reflected in the hardware device control register 102 (P in FIG. 2)
8).

The target program 101 refers to the contents of the hardware device control register 102, and detects an event sent from the contents (P in FIG. 2).
9).

As a result of an arbitrary process corresponding to an event, an action may be performed on (virtual) hardware. This action is reflected in the hardware device control register 102 (P10 in FIG. 2).

For example, assuming that the target program 101 takes an action to turn on the interior lamp in response to "door open", the bit of the hardware control register 102 corresponding to the action is changed (address "102B"). The fifth bit of is set, etc.).

The action transmitted from the target program 101 is the hardware device control register 1
02, the hardware control input / output distribution unit 103
(P11 in FIG. 2).

The hardware device control input / output distribution unit 103 determines whether the action is transmitted to the real hardware 300 (P13 in FIG. 2) or to the virtual hardware 202, 207 (FIG. 2). P12).

As a result, the action is executed by the real hardware 3
00, the corresponding hardware 300 through the hardware device control program 105.
Is transmitted (P14 in FIG. 2).

Thus, for example, the interior lamp is turned on.

If the action is virtual hardware 202,2
When it is determined that the information is to be transmitted to 07, the position and value (address and its value) changed in the hardware device control register 102 are sent to the target-side communication unit 106. In the case of the interior lamp, information corresponding to “the fifth bit of the address“ 102B ”is set (“ 1 ”)” is sent to the target-side communication unit 106 (P12 in FIG. 2). .

The target communication unit 106 converts the action sent from the hardware device control input / output distribution unit 103 into data in a format defined by the protocol, and communicates through the target-host communication unit 208 to the host communication unit. It is sent to 201 (P15 in FIG. 2).

In the host side communication unit 201, the target
The data transmitted from the inter-host communication unit 208 is expanded to extract necessary actions (address and value). The retrieved action is sent to physical level virtual hardware. Continuing with the above example, "address" 102
Information that the fifth bit of "B" is "1" is sent to the physical level virtual hardware (P16 in FIG. 2).

In the physical level virtual hardware 202,
The state of the physical level virtual hardware 202 is changed based on the action sent from the host communication unit 201. By observing the physical level virtual hardware 202 by the user, it is possible to know that the target program 101 has sent an action of turning on the interior lamp.

Further, the hardware information abstraction degree conversion unit 2
At 03, a routine for checking the physical level virtual hardware 202 and detecting an event / action is executed (P17 in FIG. 2).

As a result, a newly changed portion is found out, and the virtual hardware state at the physical level (the fifth bit of the address “102B” is “1”) is changed to the virtual hardware state at the logical level (the internal lamp is turned off). (Lit) to convert the action information. This action is transmitted to the logical level virtual hardware 207 (P1 in FIG. 2).
8).

In the logical level virtual hardware 207,
Change the state of virtual hardware based on the reported action. By observing the virtual hardware, the user can know whether or not the interior lamp is turned on.

As described above, when there is no actual hardware 300, the virtual hardware 200 can be operated to generate test data (event) for the target program 101. Further, by viewing the reaction (action) to the test data on the (virtual) hardware 300, the target program 1
Check that 01 is working properly.

Further, since the hardware device control input / output distribution information change unit 107 is provided, debugging can be performed even when both the real hardware 300 and the virtual hardware 200 are connected. By changing the hardware device control input / output distribution information 104, the user can select which of the real hardware and the virtual hardware to use. The above-described distribution is performed based on the hardware device control input / output distribution information 104.

The execution control unit operates the distribution information on the host side, and the hardware device control input / output distribution information change unit 107 actually changes the distribution information on the target side.

In the execution control unit 204, “view” and “change” of the hardware device control input / output distribution information 104 are performed.
Can be done. For example, if it is specified that “door” and “temperature sensor” use virtual hardware 202 and 207, and “compressor” and “fan” use real hardware 300, etc. Part 201
-Transmitted to the hardware device control input / output distribution information change unit 107 through the target side communication unit 106,
The hardware device control input / output distribution information change unit 107 changes the hardware device control input / output distribution information 104 (P23 (a) → P25 (a) → P in FIG. 2).
24 (a) → P22 (a) → P21 (a)).

When the “viewing request” is transmitted, the hardware device control input / output distribution information change unit 107
Transmits the distribution information 104 to the target-side communication unit 106-
It returns to the execution control unit 204 via the host-side communication unit 201 (P21 (b) → P22 (b) → P24 (b) in FIG. 2).
→ P25 (b) → P23 (b)).

The virtual hardware has a logical level (20
7) and a physical level (202) are prepared. With the virtual hardware 207 at the logical level, debugging can be performed with the same feeling as operating a real machine.

On the other hand, the physical level virtual hardware 20
In 2, it is possible to operate while looking at the RAM map. <Description of each component> Here, each component is summarized.

[Target Program 101] The target program 101 is software to be debugged by the present invention. Target program 101
Receives an event that has occurred in the hardware 300 or virtual hardware on the host machine through a hardware control register, starts the process triggered by the event, and performs an action for controlling the hardware / virtual hardware. To the hardware control register 10
It is often an event-driven program such as returning to 2.

FIG. 3 shows a processing flow of the target program 101.

First, in step S31, an arbitrary process is performed. The processing for the event is performed at this stage. Then, the process proceeds to step S32, where it is checked whether or not an event has occurred by referring to the hardware device control register 102. Also write the action. Then, the process returns to step S31.

The processes of steps S31 to S32 are repeated. [Hardware Device Control Register 102] The hardware device control register 102 is an area that buffers events from hardware / virtual hardware and actions from the target program 101, and is placed on the memory.

The hardware device control distribution unit 103 described below transmits an event to this area. Also,
The target program 101 operates with reference to an event transmitted through this area.

Conversely, the target program 101 transmits an action to this area, and the hardware device control distribution unit 103 transmits the action to (virtual) hardware.

This register can be represented as shown in FIG. For example, when transmitting a digital event / action, the third [bit] of the address “0100” is an area for transmitting a door opening / closing event, the address “0101”.
The second [bit] is used to convey a compressor ON / OFF action.

In the case of an analog event / action, a value in the range of “0” to “255” represented by the address “0102” is used. Note that, in FIG. 4, it is represented by 8 [bits], but this is not necessarily required. For example, 4 [b
It], 16 [bit], and other bit configurations are also possible. [Hardware device control input / output allocation unit 103 / hardware device control input / output allocation information 104] The hardware device control input / output allocation unit 103 determines which of the events sent from the real hardware / virtual hardware is the target program. Tell 101
Further, it is determined whether the action output from the target program 101 is sent to real hardware or virtual hardware.

For example, it is determined which information of the temperature sensor of the real machine or the temperature sensor of the virtual environment on the PC is to be transmitted to the target program 101. Information on which event is transmitted and to which action is sent is stored in the hardware device control input / output distribution information 104. Also, when a virtual interrupt from the host machine is received, an actual hardware interrupt can be handled by jumping from the distribution unit to the interrupt handler.

The hardware device control input / output distribution information 104 can be represented as shown in FIG. Similarly to the above hardware device control register 102, “0”
The third [bit] of “100” is defined as an area for the door, and “0” and “1” indicate which of the real / virtual hardware events to use and which hardware to transmit the action to. I do.

For example, if the bit information is “0”, an event from the real hardware 300 is written to the register, and if the bit information is “1”, an event from the virtual hardware is written to the register.

In FIG. 4, the data is represented by 8 bits, but it is not always necessary. For example, 4 [bit],
16 [bit] and other bit configurations are also possible.

The control register 102 and the hardware device control input / output distribution information 104 correspond to each other, and can be expressed in a similar format. However, they are not the same thing.

The control register 102 and the distribution information 10
4 is supplemented. For example, the control register 102
Is as follows: When the hardware status is represented by ON / OFF digitally, each bit has a meaning. 0 [bit] of “0100”: Indicates opening / closing of a door. “0”
Indicates a closed state. First [bit] of “0100”: Indicates whether the LED is on or off.
“0” indicates that the light is off. The second [bit] of “0100” represents the operation / stop of the fan. “1” indicates that the vehicle is running. Third [bit] of “0100”: Indicates the operation / stop of the compressor. “1” indicates that the vehicle is running. And so on. On the other hand, the following sort information 104 is prepared. 0th [bit] of “A100”: Indicates whether a real door or a virtual door is used.

“1” indicates that the virtual one is used. 1st [bit] of “A100”: Indicates whether the real LED or the virtual LED is used.

"0" indicates that the genuine product is used.

Analogous values such as the input from the temperature sensor have meaning at one address.

[0152] “0101” represents the temperature of the refrigerator compartment (value after A / D conversion). Now, since the hexadecimal number indicates "5", if the sensor detects -10 to 20 degrees, it indicates just around 0 degrees. “0102”: Indicates the room temperature (outside air temperature). ... and so on. For analog values, the same sort information 104 as for digital is prepared. 0th [bit] of “A101”: Indicates which temperature is used in the actual refrigerator compartment or the virtual refrigerator compartment. “0” indicates that the real one is used. 1st [bit] of “A101”: Indicates which temperature is used in a real room or a virtual room. “1” indicates that the virtual one is used. The above is the control register 10
2 and supplementary information about the sorting information 104. still,
The hardware device control input / output distribution information 104 can be changed by the host machine side system 200 (performed through the target side communication unit 106).

The processing of the hardware device control input / output distribution unit 103 is divided into an input side (FIG. 5) and an output side (FIG. 6). In each case, the distribution process is performed based on the hardware device control input / output distribution information 104.

FIG. 5 is an input flow showing a process for transmitting information from (virtual) hardware to the target program 101.

First, steps S501 and S5
In step 02, a request from the target-side communication unit 106 and the hardware device control program 105 is waited.

If there is an input request, the process proceeds to step S503. If there is no input request, the process proceeds to step S5.
Return to 01.

In step S503, it is checked whether or not the request is from the target communication unit 106. As a result, if the request is from the target communication unit 106, the process proceeds to step S504. If it is not a request from the target-side communication unit 106, that is, if it is a request from the hardware device control program 105, the process proceeds to step S505.

In step S504, an event is read from the reception buffer of the target communication section 106. Then, the process proceeds to step S505.

On the other hand, in step S505, an event is read from the control program 105. And step S
It moves to the process of 506. In step S506, the read event is stored in the hardware device control register 102.
Is determined based on the distribution information 104.

As a result, if the image can be expanded, the process proceeds to step S507, and if not, the process proceeds to step S508.

In step S507, the event is developed in the register, and the process returns to step S501.

In step S508, the event is discarded. Then, the process returns to step S501.

As described above, steps S501 to S508 are repeated.

FIG. 6 is a flowchart showing a process for transmitting an action sent from the target program 101 to (virtual) hardware.

First, an output request is checked by executing steps S601 and S602. The output request is issued by the target program 101 or the hardware device control program 105.

As a result of the check in step S602, if there is an output request, the process proceeds to steps S603 and S604, and if there is no output request, the process returns to step S601.

In step S603, referring to the hardware device distribution information, it is determined whether the action is to be sent to real or virtual hardware based on this information. That is, it is determined whether or not to output to the communication unit 106 on the target side.

If it is determined in step S604 that the output is to be made to the virtual hardware, step S605
The process proceeds to the process of step S605 when outputting to the actual hardware.

In step S605, an action is written to the transmission buffer. Then, step S601
Return to the processing of.

On the other hand, in step S606, an action is transmitted to the hardware device control program 105. Then, the process returns to step S601.

As described above, the processing of steps S601 to S606 is repeated. [Hardware device control input / output allocation information change unit 107] The hardware device control input / output allocation information change unit 107 changes or allocates the hardware device control input / output allocation information 104 in response to a request from the host. Performs processing to return information to the host side. In the case of a change request, data of the type “address + value” is sent in addition to the ID indicating the change.

This is reflected in the corresponding distribution information.

In the case of “viewing request”, a place (address, etc.) is sent together with an ID indicating viewing. An ID indicating response data corresponding to the browsing request is added to the distribution information of the corresponding address, and the target communication unit 106
Write to the transmission buffer of.

FIG. 24 shows the flow of processing of the hardware device control input / output distribution information change unit 107.

First, in step S2401, a change / browsing request from the target communication unit 106 is waited. If the request has been received, the process proceeds to step S2402, and it is determined whether the request is a “change request”.
As a result, if it is “change request”, step S24
03, and if it is not a “change request” but a “viewing request”, the process moves to step S2404.

In the process of step S2403, the sorting information is changed based on the transmitted data.
Then, the process returns to step S2401.

On the other hand, in the process of step S2404, distribution information specified in the data is obtained. Then, the process proceeds to step S2405.

In the processing in step S2405, the distribution information is written into the transmission buffer of the target communication section 106. Then, the process returns to step S2401. [Hardware Device Control Program 105] This program bridges the exchange between the target program 101 and the hardware 300. The event detected in the hardware 300 is transmitted to the target program 101, and the operation of the hardware 300 is controlled according to the action. Functions equivalent to the hardware device control program are provided in physical level virtual hardware on the host machine.

FIG. 7 shows a processing flow of the hardware device control program.

This program firstly starts with step S
At 701, an event is detected from hardware or an action is sent to hardware.
Then, the process proceeds to step S702, and an output request is issued to the distribution unit in order to obtain action information. Alternatively, an input request is issued to pass event information. Then, the process returns to step S701, and the above processing is repeated. [Target-side communication unit 106] Target-side communication unit 10
Reference numeral 6 denotes a part in charge of transmitting an action to the host machine / receiving an event. In addition, a request to change / view the hardware device control input / output distribution information 104 is transmitted and received. Processing such as sending transmission data (action and sorting information) with a start code or checksum code, extracting received data from a buffer to check for errors, and extracting necessary events and requests is performed.

<Transmission Flow of Target-Side Communication Unit 106> FIG. 8 shows a process on the transmission side (when transmitting action or sorting information) of the target-side communication unit 106.

In this process, first, in step S801, it is checked whether or not action or distribution information has been written to the transmission buffer. If the check shows that action or distribution information has been written, the flow advances to step S802. If not, step S801
And the above processing is repeated.

In step S802, the event information and the sorting information are processed into transmission data in accordance with the protocol specified by the target-host communication unit 208. When the processing is completed, the process proceeds to step S803, where the processing proceeds to step S803. Through the inter-host communication means 208,
Send data. Then, the process returns to step S801 to repeat the above processing.

<Reception Flow of Target-Side Communication Unit 106> FIG. 9 describes the processing on the receiving side (when receiving an event or a change / browsing request).

In this process, first, in step S901, it is checked whether data has been received from the target-host communication unit 208. As a result, if it has been received, the process moves to step S902, and if it has not been received, the process returns to step S901.

In step S902, the received data is expanded according to a prescribed protocol. Then, the process proceeds to step S903. Step S903
Then, it is determined whether the transmitted data is an event. If the result is an event, step S90
4. If the request is a change / viewing request, step S9
Move to 05.

In step S904, the data is stored in the reception buffer, and an input request is issued to the hardware device control input / output distribution unit 103. Then, step S9
01, and the above processing is repeated.

In step S905, the request is sent to the hardware device control input / output distribution information change unit 107.
Tell Then, the process returns to step S901, and the above processing is repeated. [Target-Host Communication Means 208] Target-
The inter-host communication means 208 enables communication between the target 100 and the host machine 200,
Examples include a serial line and a parallel line. Then, a protocol for transmitting data is determined, and communication is performed according to this protocol. Any communication means capable of exchanging necessary information for constructing the present system may be used. [Physical-logical correspondence information 206] Physical-logical correspondence information 20
6 converts logical level events to physical level,
Alternatively, in order to convert a physical level action to a logical level, each event / action is associated with a conversion routine name and an argument.

FIG. 10 shows an example of the physical-logical correspondence information 206. In FIG. 10, a description 1001 enclosed by "[" and "]" indicates an event / action, and a character string following the description is a conversion processing routine 1002 and an argument 10
03. If information equivalent to FIG. 10 is obtained,
There is no need to limit the notation.

[Logic Level Virtual Hardware 207] The logic level virtual hardware 207 simulates the state / operation of the hardware on the host machine in an expression that is easy for the user to understand. When the virtual hardware is operated, an event occurs, and when the action returns, the state of the virtual hardware changes. In this way, the user can easily generate test data for the target program 101 by operating the virtual hardware, and by observing the virtual hardware, the target program 101 can appropriately generate the hardware 300.
Can be confirmed whether or not is controlled.

FIG. 11 shows the logical level virtual hardware 20.
7 shows the flow of processing. Here, processing is divided into a transmitting side (a direction for transmitting an event to a target) and a receiving side (a side receiving an action from the target) on the way.

The flow of the processing will be described.
At 1101, the logical level virtual hardware and GU
Prepare I.

Then, the transmitting side waits for an event from the user interface (step S1102).

On the other hand, the receiving side waits for an action from the hardware information abstraction degree converter 203 (step S11).
06).

If an event occurs, the transmitting side
An event corresponding to the input is generated (step S11)
03). Then, the process proceeds to step S1104.

In step S1106, the receiving side, which has been waiting for an action from the hardware information abstraction degree conversion unit 203, changes the virtual hardware and the GUI according to the action (step S1107). Then, the process returns to step S1106.

In step S1104, the transmitting side notifies the hardware abstraction degree conversion section 203 of the event. Then, the process proceeds to step S1105. In the process of step S1105, the transmitting side changes the virtual hardware and the GUI according to the event. Then, the process returns to step S1102.

As described above, the transmitting side repeats the processing of steps S1102 to S1105, and the receiving side executes step S1102.
The processing from step 1106 to step S1107 is repeated.

GUI of Virtual Hardware for Refrigerator
As examples of the (graphical user interface), a GUI (1) shown in FIG. 21 and a GUI shown in FIG.
(2).

The GUI (1) is a case where the GUI is prepared in a form as close to real hardware as possible. As shown in FIG. 22, in the GUI (1), a picture of the exterior of the refrigerator is displayed in the left half of the screen, the area is divided into three parts in the vertical direction in the right half, and various sensor temperatures are provided in the upper part, and LEDs and switches are provided in the middle part. The picture related to the motor is displayed in the lower part.

In the picture of the refrigerator, the door can be opened and closed on the screen, and the designated door is opened and closed by specifying the door with a keyboard or a mouse, and the designated door is opened and closed. If the interior light is turned on when it is "open," a screen that matches the actual operation of the refrigerator, such as displaying the state that the interior light is open on the screen, is displayed. .

The temperature of the various sensors is determined by simulating the open / closed state of the door and the outside air temperature in accordance with the actual refrigerator, and the current temperature and changes in temperature are displayed in a graph. There are LED and switches graphically showing the operation switches such as "refrigerated", "freezing", "chilled", "weak", "medium", "strong" etc. attached to the refrigerator and the blinking state of the LED lamp indicating the on / off state For motors, compressors that are the heart of refrigerators, compressors that rotate according to the drive status of the internal fan, compressors with an internal fan that is animated or stopped, , The internal fan is displayed.

As described above, in the GUI (1), it is possible to open the door on the screen, and see that the LED is turned on and that the compressor and the like are rotating / stopping.

The GUI (2) shown in FIG. 22 is functionally equivalent, but is an example in which graphics are simplified. In this case, the opening and closing and the temperature of the door are buttons, sliders and the like.

That is, in the case of the example of FIG. 22, there are an operation panel and a monitor, and the operation panel is used to open and close the “freezer compartment door”, “refrigerator compartment door”, “vegetable compartment door”, etc. The temperature of the “freezer compartment temperature sensor”, “chilled compartment temperature sensor”, and “refrigeration compartment temperature sensor” is set by a slider and displayed.

The monitors include "inside light", "F fan", "R fan", "C fan", "compressor", "at once RED", "heater", and the like. It is displayed.

That is, when an instruction such as opening / closing is given on the screen of the operation panel, the monitoring result is displayed on the monitor screen side.
Characters such as "light on", "run", and "stop" are displayed in characters, and display and operation for each bit, input and display by graph, and the like can be performed. [Hardware information abstraction level conversion unit 203] The hardware information abstraction level conversion unit 203 is located on the host machine, and converts events / actions from a physical level to a logical level, and conversely, from a logical level to a physical level. A conversion routine corresponding to an event / action is called from the physical-logical correspondence information to perform conversion. The conversion routine is included in the conversion information. The processing of the hardware information abstraction degree conversion unit 203 is divided into two processes: a transmission side and a reception side.

<Processing Flow on the Transmission Side of Hardware Information Abstraction Level Conversion Unit 203> FIG. 12 is a processing flow on the transmission side of the hardware information abstraction level conversion unit 203.

The transmitting side first waits for an event from the logical level virtual hardware 207 in step S1201. If an event has come, step S120
Move to the processing of 2.

In step S1202, the event-conversion routine correspondence description section of the physical-logical correspondence information 206
Select the routine and arguments corresponding to the event. Then, the process proceeds to step S1203.

In step S1203, a conversion processing routine in the conversion information is called. As a result, a conversion processing routine of step Sub121, which is a subroutine, is executed. In this conversion processing routine, a logical level event is converted into a physical level and returned to the original main routine. The main routine receives the returned value, executes the process of step S1204, and transmits the returned physical-level event to the physical-level virtual hardware.
Then, the process returns to step S1201, and the above processing is repeated.

The transmission side processing in the hardware information abstraction degree conversion unit 203 is as described above.

<Processing Flow on the Receiving Side of Hardware Information Abstraction Degree Conversion Unit 203> FIG. 13 is a processing flow on the receiving side of the hardware information abstraction degree conversion unit 203.

On the receiving side, first, the process of step S1301 is performed, and in this process, all events / actions at the logical level are listed from the physical-logical correspondence information 206. Then, the process proceeds to step S1302.
In step S1302, conversion information conversion processing routines (subroutine Sub131) corresponding to the listed events / actions are sequentially called. Then, in this conversion processing routine, it is determined whether an event / action has occurred in the physical level virtual hardware. Then, the determination result is returned to the main routine. In the main routine, in step S1303, it is checked whether an event / action has occurred. As a result, if an event / action has occurred, the process advances to step S1304; otherwise, the process returns to step S1302.

In step S1305, the generated event action is transmitted to the logical-level virtual hardware. Then, the process returns to step S1302.

In the process on the receiving side, the processes of steps S1302 to S1304 are repeated in order for the events / actions listed in step S1301. [Conversion information 205] As shown in FIG.
Reference numeral 5 denotes information necessary for conversion between a logical level and a physical level of an event / action, which is prepared for each product. The conversion information 205 includes register information (corresponding to a target) 205a,
Register information (corresponding to host) 205b and conversion processing routine group 205c are included.

As the register information 205a and 205b, a specific address of the memory is allocated and used, and the state of each bit of the address is used as the specific information. The register information 205a, 205b can be represented, for example, as shown in FIG.

That is, as in the case of the hardware device control register 102, for example, “address“ 0100 ”
The third [bit] indicates the opening and closing of the door. "

The conversion processing routine group includes two types of routines, one for the transmitting side and one for the receiving side. Then, the conversion processing routine is prepared for all the routine names that appear in the physical-logical correspondence information.

One of the two types of conversion processing routines is a transmission-side routine that forms a physical-level event from the routine name and the argument and returns the event to the hardware information abstraction degree conversion unit 203.

<Transmission-side Conversion Processing Routine> FIG. 15 shows a processing flow of the transmission-side conversion processing routine.

Referring to FIG. 15, the transmitting side conversion process
First, in step S1501, an event in the form of an address and its value (an event expressed in a physical level) is generated from the argument passed when called by the hardware information abstraction conversion unit (transmission side) 203. S1
It moves to the process of 502.

In step S1502, the register information (corresponding to the target) is changed in response to the occurrence of the event, and the flow advances to step S1503. In step S1503, physical level event information is returned to the hardware information abstraction degree conversion unit 203.

The above is the routine on the transmitting side that forms an event at the physical level from the routine name and the argument, and returns the event to the hardware information abstraction conversion unit 203.

<Receiving-Side Conversion Processing Routine> The other of the two types of conversion processing routines is a receiving-side routine for checking whether a corresponding event / action has occurred. In this routine, based on an argument passed when called by the hardware information abstraction degree conversion unit 203, it is determined whether or not an event / action has occurred in the corresponding component, and the determination result is determined by the hardware. What is notified to the abstraction degree conversion unit 203 is performed.

FIG. 16 shows a processing flow of a conversion processing routine on the receiving side.

Here, first, in step S1601, the event / action for which component of the virtual hardware status data is determined from the argument passed when called by the hardware information abstraction degree conversion unit (reception side) 203. Then, the process proceeds to step S1602.

In step S1602, the register information corresponding to the target and the register information corresponding to the host are compared for the specified portion. Then, the process proceeds to the determination processing in step S1603. Step S
In 1603, it is determined whether or not the register information of the target / host is different. As a result of the determination, if the register information of the target / host is different, the process proceeds to step S1604, and if not (ie, the same), the process proceeds to step S1606.

In step S1606, the fact that no event / action has occurred is notified to the hardware information abstraction degree conversion unit 203. Then, the process ends.

On the other hand, in step S1604, the host corresponding register information is changed according to the target. That is, the state of the logical-level virtual hardware 207 is changed according to the state of the physical-level virtual hardware 202. Then, the process proceeds to step S1605. In step S1605, the fact that an event / action has occurred is notified to the hardware information abstraction degree conversion unit 203. That is, the hardware information abstraction degree conversion unit 203 is notified that the corresponding event / action has occurred.

The above processing is performed. [Physical Level Virtual Hardware 202] The physical level virtual hardware 202 is virtual hardware on the host machine 200 that expresses the state / operation of the hardware at the level of data handled in the target 100. The user can not only operate / observe the logical level virtual hardware 207, but also operate / observe the virtual hardware 202 at this physical level and debug the target program 101.

The virtual hardware that can directly exchange with the target program 101 is the physical level virtual hardware 202. An example of the user interface of the physical level virtual hardware 202 is shown in FIG.

In the case of the example shown in FIG. 23, there are an operation panel and a monitor.
01, “0102”, “0103”... Are addresses, and “01100100”,
“11110101”, “0101001”, “00”
"001000", "01100010",... Are bit data in the address, and "6
"4", "F5", "51", "08"... Represent bit data in the address in hexadecimal notation, and indicate the contents of the register. Is an operation state monitored.

The physical level virtual hardware 202 includes:
There are processes on the sending side and the receiving side. <Transmission-Side Processing Flow> FIG. 17 is a transmission-side processing flow.

First, in step S1701, an event from the hardware information abstraction degree converter 203 or the user interface of the physical level virtual hardware 202 is awaited. Then, if an event has arrived, the process proceeds to step S1702, and the register information (corresponding to the target) in the conversion information is changed according to the event.
Then, the process proceeds to step S1703.

In step S1703, the event is passed to the host communication unit 201. Then, the process proceeds to step S1704. In step S1704, the user interface is changed according to the event sent. Then, the process returns to step S1701.

The transmitting side repeats the processing of steps S1701 to S1704.

<Receiving Side Processing Flow> FIG. 18 is a receiving side processing flow.

First, in step S1801, an action from the host side communication unit 201 is waited. Step S1 when an action is received from the host side communication unit 201
In step 802, the register information (corresponding to the target) in the conversion information 205 is changed according to the event. Then, the process proceeds to step S1803.

In step S1803, the user interface is changed according to the action sent. Then, the process returns to step S1801.

The receiving side repeats the processing of steps S1801 to S1803. [Host-Side Communication Unit 201] The host-side communication unit 201 is responsible for transmitting and receiving data to and from the target. The event sent from the virtual hardware and the sorting information change / viewing request sent from the execution control unit 204 are processed into transmission data according to a predetermined protocol and sent out. Further, the received data is expanded to extract the result of the action or the browsing request.

<Processing Flow on Transmission Side> FIG. 19 shows a processing flow on the transmission side.

First, in step S1901, an event from the physical level virtual hardware 202 or distribution information change data from the execution control unit 204 is waited for. If an event or data comes, step S19
02, the target-host communication means 20
The data is processed according to the protocol specified in 8.
Then, control goes to a step S1903.

At step S1903, the processed data is sent to the target-host communication means 208. Then, the process returns to step S1901.

<Receiving Side Processing Flow> FIG. 20 is a receiving side processing flow.

First, in step S2001, the process waits for action or distribution information to be sent from the target-host communication unit 208. When the data arrives, the process proceeds to step S2002, where an error check is performed and the data is expanded. Then, the process proceeds to the process in step S2003.

In step S2003, if the data is distribution information, the flow proceeds to step S2005, and if the data is an action, the flow proceeds to step S2004.

In step S2005, distribution information is transmitted to execution control unit 2004. Then, the process returns to step S2001.

On the other hand, in the process of step S2004, an action is transmitted to the physical level virtual hardware 202. Then, the process returns to step S2001. [Execution control unit 204] The execution control unit 204 operates a hardware device control input / output distribution information to switch between real hardware and virtual hardware. It is. The switching between the real hardware and the virtual hardware can be performed during execution of the software.

The execution control unit 204 can issue a request to change distribution information and a request to browse. In order to distinguish these requests from events / actions, a specific ID is added to data and sent to the host side communication unit 201.

FIG. 25 shows an example of a user interface of the execution control unit 204. By clicking “Browse”, the current state is displayed as to which of the real / virtual hardware is used for each component (the black circle inside the circle switches).

[0252] For each component, by clicking inside the circle, real / virtual switching can be performed.

FIG. 25 is merely an example, and any GUI that satisfies the same function may be used.

As described in detail above, in the system of the present invention, the software to be tested can be connected to both real hardware and virtual hardware on the host machine. Virtual hardware can be used instead of hardware so that the software under test can be executed, and if the hardware is partially completed, it can be connected to test the software under test. Because
As a result, even if there is no hardware or the hardware is being developed, a software test in combination with the hardware can be performed, and finally, product quality and development efficiency can be improved.

The present invention is not limited to the above-described embodiments, but can be implemented with appropriate modifications without departing from the scope of the invention.

[0256]

As described in detail above, according to the present invention, even if there is no hardware or the hardware is under development, a software test combined with the hardware can be performed. It is possible to provide a software test apparatus capable of improving product quality and development efficiency.

[Brief description of the drawings]

FIG. 1 is a diagram for explaining the present invention, and is a block diagram showing an entire configuration of a specific example of the present invention.

FIG. 2 is a diagram for explaining the present invention, and is a diagram for explaining the operation of the system of the present invention.

FIG. 3 is a diagram for explaining the present invention, and is a flowchart for explaining processing contents of a target program in the system of the present invention;

FIG. 4 is a diagram for explaining the present invention, and is a diagram for explaining an example of register information and hardware device control input / output distribution information used in the system of the present invention.

FIG. 5 is a diagram for explaining the present invention, and is a flowchart for explaining an input processing example of a hardware device control input / output distribution unit in the system of the present invention;

FIG. 6 is a diagram for explaining the present invention, and is a flowchart for explaining an output processing example of a hardware device control input / output distribution unit in the system of the present invention;

FIG. 7 is a diagram for explaining the present invention, and is a flowchart for explaining a processing example of a hardware device control program in the system of the present invention;

FIG. 8 is a diagram for explaining the present invention, and is a transmission flow illustrating a transmission operation of a target-side communication unit in the system of the present invention.

FIG. 9 is a diagram for explaining the present invention, and is a reception flow illustrating a receiving operation of a target-side communication unit in the system of the present invention.

FIG. 10 is a diagram for explaining the present invention, showing an example of physical-logical correspondence information used in the system of the present invention.

FIG. 11 is a diagram for explaining the present invention, which is a diagram for explaining a processing flow of the logical level virtual hardware 207 in the system of the present invention.

FIG. 12 is a diagram for explaining the present invention, and is a diagram for explaining a transmitting-side processing example of the hardware information abstraction degree conversion unit in the system of the present invention;

FIG. 13 is a diagram for explaining the present invention, and for explaining a receiving-side processing example of the hardware information abstraction degree conversion unit in the system of the present invention;

FIG. 14 is a diagram for explaining the present invention, and is a diagram for explaining conversion information 205 in the system of the present invention.

FIG. 15 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a conversion processing routine (transmission side) in the system of the present invention.

FIG. 16 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a conversion processing routine (reception side) in the system of the present invention.

FIG. 17 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of physical level virtual hardware (transmission side) in the system of the present invention.

FIG. 18 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of physical level virtual hardware (receiving side) in the system of the present invention.

FIG. 19 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a host-side communication unit (transmitting side) in the system of the present invention.

FIG. 20 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a host-side communication unit (receiving side) in the system of the present invention.

FIG. 21 is a diagram for explaining the present invention, and is a diagram for explaining an example of a logical level virtual hardware GUI in the system of the present invention.

FIG. 22 is a diagram for explaining the present invention, and is a diagram for explaining an example of a logical level virtual hardware GUI in the system of the present invention.

FIG. 23 is a diagram for explaining the present invention, and is a diagram for explaining an example of a physical-level virtual hardware GUI in the system of the present invention.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 100 ... Target side system 101 ... Target program 102 ... Hardware device control register 103 ... Hardware device control input / output distribution unit 104 ... Hardware device control input / output distribution information 105 ... Hardware device control program 106 ... Target side communication unit 107 ... Hardware device control input / output distribution information change unit 200 ... Host machine side system 201 ... Host side communication unit 202 ... Physical level virtual hardware 203 ... Hardware information abstraction degree conversion unit 204 ... Execution control unit 205 ... Conversion information 206 ... Physical-logical correspondence information 207: logical level virtual hardware 300: real hardware (target hardware).

────────────────────────────────────────────────── ───

[Procedure amendment]

[Submission date] February 16, 1998

[Procedure amendment 1]

[Document name to be amended] Statement

[Correction target item name] Brief description of drawings

[Correction method] Change

[Correction contents]

[Brief description of the drawings]

FIG. 1 is a diagram for explaining the present invention, and is a block diagram showing an entire configuration of a specific example of the present invention.

FIG. 2 is a diagram for explaining the present invention, and is a diagram for explaining the operation of the system of the present invention.

FIG. 3 is a diagram for explaining the present invention, and is a flowchart for explaining processing contents of a target program in the system of the present invention;

FIG. 4 is a diagram for explaining the present invention, and is a diagram for explaining an example of register information and hardware device control input / output distribution information used in the system of the present invention.

FIG. 5 is a diagram for explaining the present invention, and is a flowchart for explaining an input processing example of a hardware device control input / output distribution unit in the system of the present invention;

FIG. 6 is a diagram for explaining the present invention, and is a flowchart for explaining an output processing example of a hardware device control input / output distribution unit in the system of the present invention;

FIG. 7 is a diagram for explaining the present invention, and is a flowchart for explaining a processing example of a hardware device control program in the system of the present invention;

FIG. 8 is a diagram for explaining the present invention, and is a transmission flow illustrating a transmission operation of a target-side communication unit in the system of the present invention.

FIG. 9 is a diagram for explaining the present invention, and is a reception flow illustrating a receiving operation of a target-side communication unit in the system of the present invention.

FIG. 10 is a diagram for explaining the present invention, showing an example of physical-logical correspondence information used in the system of the present invention.

FIG. 11 is a diagram for explaining the present invention, which is a diagram for explaining a processing flow of the logical level virtual hardware 207 in the system of the present invention.

FIG. 12 is a diagram for explaining the present invention, and is a diagram for explaining a transmitting-side processing example of the hardware information abstraction degree conversion unit in the system of the present invention;

FIG. 13 is a diagram for explaining the present invention, and for explaining a receiving-side processing example of the hardware information abstraction degree conversion unit in the system of the present invention;

FIG. 14 is a diagram for explaining the present invention, and is a diagram for explaining conversion information 205 in the system of the present invention.

FIG. 15 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a conversion processing routine (transmission side) in the system of the present invention.

FIG. 16 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a conversion processing routine (reception side) in the system of the present invention.

FIG. 17 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of physical level virtual hardware (transmission side) in the system of the present invention.

FIG. 18 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of physical level virtual hardware (receiving side) in the system of the present invention.

FIG. 19 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a host-side communication unit (transmitting side) in the system of the present invention.

FIG. 20 is a diagram for explaining the present invention, and is a diagram for explaining a processing flow of a host-side communication unit (receiving side) in the system of the present invention.

FIG. 21 is a diagram for explaining the present invention, and is a diagram for explaining an example of a logical level virtual hardware GUI in the system of the present invention.

FIG. 22 is a diagram for explaining the present invention, and is a diagram for explaining an example of a logical level virtual hardware GUI in the system of the present invention.

FIG. 23 is a diagram for explaining the present invention, and is a diagram for explaining an example of a physical-level virtual hardware GUI in the system of the present invention.

FIG. 24 is a diagram for explaining the present invention, and is a diagram for explaining an example of a processing flow of a hardware device control input / output distribution information change unit in the system of the present invention.

FIG. 25 is a diagram for explaining the present invention, and is a diagram for explaining an example of a user interface in an execution control unit in the system of the present invention.

[Description of Signs] 100 target system 101 target program 102 hardware device control register 103 hardware device control input / output distribution unit 104 hardware device control input / output distribution information 105 hardware device control program 106 Target-side communication unit 107: Hardware device control input / output distribution information change unit 200: Host machine-side system 201: Host-side communication unit 202: Physical level virtual hardware 203: Hardware information abstraction degree conversion unit 204: Execution control unit 205 ... conversion information 206 ... physical-logical correspondence information 207 ... logical level virtual hardware 300 ... real hardware (target hardware).

 ──────────────────────────────────────────────────の Continuing on the front page (72) Inventor Takuya Kishimoto 3-3-9, Shimbashi, Minato-ku, Tokyo Inside Toshiba AV EE Co., Ltd.

Claims (2)

[Claims] A software test apparatus for testing target software used for controlling target hardware as target hardware, comprising: a target development environment which is an operating environment of the target software; and an operation for testing the software. A target development environment, a target device to be tested, hardware device control means for controlling each hardware device group constituting hardware to be controlled by software, and a hardware A hardware device control input / output distributor that controls whether information to be exchanged with the target program based on the device control input / output distribution information is switched to the hardware device control program side or the target side communication means side. And hardware device control input / output distribution information changing means for changing the hardware device control input / output distribution information, and the host development environment includes a host side for exchanging information with the target side communication means. Communication means, physical-level virtual hardware realizing means for virtually realizing the operation of the target hardware, and logical-level virtual hardware realizing means for virtually realizing an environment enabling artificial operation on the target hardware A software test apparatus, comprising: 2. The software test apparatus according to claim 1, wherein in a host environment, the physical level virtual hardware realizing means can operate and refer to the state of each hardware device at a physical signal level, While maintaining the state of each hardware device at the physical signal level,
When a new request is issued from the target program to the hardware device through the host-side communication means, the state of the corresponding hardware device in the physical-level virtual hardware is updated according to the request. When the function and the status of the hardware device are updated by user operation, the status change information of the hardware device is notified from the host communication means to the target program via the hardware device control input / output distribution means. A software test apparatus having a function to execute a target program without target hardware.