JP2003316603A - Program verification system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a verification system capable of verifying a program without waiting for the completion of a real machine device even in the case that program development precedes the hardware development of a real machine. <P>SOLUTION: Between an ICE debugger 506 corresponding to the specifications of the real machine device 150 and a virtual device 100 for simulating the specifications of the real machine device corresponding to a new program 414, a bridge 504 for performing a conversion processing or the like so as to adapt commands or the like from the virtual device 100 to the ICE debugger 506 is provided. Also, a synchronization RAM 404 is provided so as to absorb the difference of the operation speeds of the real machine device 150 and the virtual device 100 and the synchronization of the data transfer of the synchronization RAM 404 and a user RAM 402 is controlled by a synchronization program 412. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program verification system for verifying the operation of a microcomputer program by using ICE, and in particular, a program verification system using an actual device and a virtual device as peripheral devices necessary for executing the program. Regarding

[0002]

2. Description of the Related Art FIG. 15 shows an example of a conventional real machine debug set. As shown in FIG. 15, an evaluation of an application program for controlling a single-chip microcomputer is performed by using an in-circuit emulator (hereinafter referred to as ICE) 400 that can emulate all functions of the single-chip microcomputer instead of the target single-chip microcomputer.
The debug board 18 is installed in the real machine debug set (peripheral device 12
It was done by connecting to 0).

However, when such a debug set is used, in order to test the program, it is essential that the hardware for operating the system is completed in advance, so that the software development process is hard. There was a problem that it was greatly influenced by the progress of the wear development.

In order to solve this problem, there has been proposed a method of evaluating a program by simulating a target single-chip microcomputer and peripheral devices, without using an actual machine.

An example of such a simulation method is disclosed in, for example, Japanese Patent Laid-Open No. 9-114700. The system disclosed in Japanese Patent Laid-Open No. 9-114700 discloses a built-in software to be tested / debugged, an MPU simulator simulating a microprocessor unit (MPU) and a memory, and an input / output device simulation simulating input / output. Section, an input / output device execution control mechanism that simulates a signal line that connects the MPU and one or more input / output devices, a startup definition file that describes the startup sequence of the simulator, an I / O monitor, and an I / O model. Start process /
Means for ending, means for allowing the user to refer to and change resource information of all I / O models, I / O models and I / O models
It is composed of an input / output simulator operating environment having means for displaying the connection relationship of the O monitor. Each component is
It is composed of multiple processes and connected by virtual wiring. In this simulation method, as shown in FIG. 16, all of the actual peripheral devices 120 are virtual devices 100.
Will be realized in.

An example of an actual machine / simulator mixed loading system that combines the advantages of both the actual machine debug method and the simulator debug method is disclosed in Japanese Patent Laid-Open No. 8-6810. As shown in FIG. 17, the system disclosed in Japanese Unexamined Patent Publication No. 8-6810 is a mixed system of an actual device debug set using ICE64 and a virtual device (simulation unit 50). In this system, transfer of input / output data between the simulation unit 50 and the ICE 64 is realized by using a dedicated real machine interface board 60.

[0007]

[Problems to be Solved by the Invention]
In the simulator-embedded system, as shown in FIG. 17, a dedicated interface board 60 is required in order to transfer the input / output data between the virtual device and the ICE. For this reason, when the specifications of the peripheral device are changed, the interface board design is changed accordingly, which requires cost and time, which makes it difficult to efficiently debug and verify the program.

In order to solve the above problems, the present invention provides
It is an object of the present invention to provide a program verification system capable of efficiently verifying a program when using a real device and a virtual device as peripheral devices.

[0009]

In order to achieve the above object, the program verification system according to the present invention verifies the operation of the microcomputer program by using an actual device and a virtual device as peripheral devices of the microcomputer. A program verification system, wherein an emulator that emulates an operation of the program on the microcomputer, a verification control unit that controls the emulator to perform a verification operation corresponding to the actual device, the verification control unit, and the virtual device And a bridge unit for providing control signals and data from the virtual device to the verification control unit, and a real machine RA for storing input / output data between the real machine device and the program.
M, a synchronization RAM provided between the real machine RAM and the virtual device, and the synchronization R by synchronizing with the input / output operation of the program with respect to the real machine device.
A virtual / actual machine synchronization processing unit for controlling data transfer between the AM and the actual machine RAM is provided.

This configuration corresponds to the specifications of the existing actual device in order to enable the program verification without waiting for the completion of the actual device even if the program development precedes the actual hardware development. Between the verification control unit and the virtual device that simulates the specifications of the actual device corresponding to the new program by software, in order to adapt the control signals and data from this virtual device to the verification control unit, for example, conversion of commands and data, etc. It is provided with a bridge section for performing. This makes it possible to verify the new program without waiting for the completion of the actual device. Further, in order to absorb the difference in operating speed between the real device and the virtual device, a synchronization RAM for performing synchronization is provided in addition to the RAM for the real device used by the program. Further, a virtual / actual machine synchronization processing unit is provided to synchronously control data transfer between the synchronization RAM and the actual machine RAM.

Thus, for example, in the case of developing a so-called developed model having a common main function but having variations in specifications around the user interface (portion related to operation and display), a new real machine for debugging is added. Even if the set is not made with hardware, it is possible to simulate with a virtual device while using the existing real machine set. In addition, the virtual device and the I
There is no need to create a dedicated interface board for exchanging input / output data with the CE. As described above, according to the present invention, it is possible to provide a program verification system capable of efficiently developing a program without waiting for the completion of the actual machine debug set.

In the program verification system, it is preferable that the virtual device and the bridge section are connected by virtual wiring. Further, if a plurality of virtual devices are provided for each function, there is an advantage that other devices can be easily reused in other automatic verification systems.

In the program verification system, a photographing device for photographing an actual device monitor output image output from the actual device device, an actual device monitor output image, and a virtual monitor output image output to the virtual device monitor. It is preferable that the configuration further includes a verification result writing unit that records the verification result file.

According to this configuration, for example, when a prototype of an actual device to which a new program is to be mounted is completed, a virtual device prepared corresponding to the specifications of the actual device is used for program verification. Thus, the operation verification of the completed actual device can be performed. That is, the actual device and the virtual device having the same specifications are operated, and their monitor output images are written in the verification result file. This allows the developer to compare the monitor output images written in the verification result file,
It is possible to determine whether or not the actual device meets the target specifications. Further, when there is an abnormality, it becomes easy to understand which of the actual device and the program has the problem.

Further, in this preferable configuration, the event detecting section for detecting a predetermined change in the peripheral device, and the real machine monitor output image and the virtual monitor output image at a timing according to the detection result of the event detecting section. If an image acquisition unit that captures the image is further provided, the monitor output image can be captured in accordance with the input / output timings of the actual device and the virtual device, and the verification can be performed more efficiently.

Further, if a plurality of the photographing devices are provided, more information can be recorded in the verification result file. For example, when verifying a device having a plurality of types of actual devices, verification is performed. The accuracy can be improved.

Further, according to the detection result of the event detection unit, a verification status distribution unit for transmitting the verification processing status including the real machine monitor output image or the virtual monitor output image to the external terminal is further provided. It is preferable. As a result, even when the person in charge of verification work is in a remote place, accurate information can be obtained in real time. Furthermore, a configuration further comprising a remote control unit that receives a message including a control signal and its destination from an external terminal such as a portable information terminal, extracts the control signal from the received message, and delivers the control signal to the destination of the control signal. Is more preferable. As a result, if any problem occurs during the program automatic verification work, the program verification system can be remotely controlled, and efficient debugging and verification can be performed.

Further, the program verification system according to each of the above-mentioned configurations further includes a scenario control unit for reading data from a scenario file recording an operation procedure for automatically verifying a program and transferring the data to the bridge unit. It is preferable.

According to this configuration, by reading the data from the scenario file in which the operation procedure to be verified is recorded in advance, it is not necessary to perform the verification operation from the virtual device or the actual device, and the program verification system automatically It is possible to perform the verification work physically. Thereby, the program verification efficiency can be further improved.

It is more preferable to further include a timing control unit for controlling the transfer of the data read from the scenario file to the bridge unit according to the operating condition of the emulator. According to this configuration, for example, even when the emulator malfunctions due to some cause, the timing control unit performs control such as rereading the scenario file and transferring it to the bridge unit. This improves the reliability of the automatic verification work.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION First, configurations and terms common to the following embodiments will be described with reference to FIG.

The program 414 is developed as a program that operates on a microcomputer, and is a program to be debugged in the program verification system according to the present invention.

The real machine program 410 includes a program 414 to be debugged and a synchronization program 412. The synchronization program 412 is not installed in the actual microcomputer and is used only in the program verification system.
Writing data to the AM 402 is performed by the actual device 150.
Performs processing to synchronize with data writing from.

The peripheral device 120 is the program 41.
4 is an input / output device required for the operation verification of No. 4, and includes an actual device 150 and a virtual device 100. The actual device 150 is an input / output device (hardware itself) of an actual device in which the program 414 is installed. On the other hand, the virtual device 100 simulates the hardware of an actual machine in which the program 414 is installed by software.

The ICE 400 is an in-circuit emulator that emulates an actual built-in microcomputer in which the program 414 is mounted in order to verify the execution of the program 414. The ICE 400 includes a microcomputer emulator 406, a user RAM 402, and a synchronization. It includes a RAM 404. The user RAM 402 is a RAM that stores input / output data between the actual device 150 and the program 414, and the synchronization RAM 404 is described in detail later, but from the virtual device 120 to the user RAM 40.
2 is a RAM for temporarily storing the data to be written to the memory 2.

The operation of the ICE 400 is controlled by the debugger 500. The debugger 500 includes a bridge 504 and an ICE debugger 506 (verification control unit). IC
The E debugger 506 is designed to cause the ICE 400 to execute a verification operation corresponding to the specifications of the actual device 150. On the other hand, the bridge 504 performs conversion of control commands between the virtual device 100 and the ICE 506 in order to enable the verification operation using the virtual device 100 as an input / output device instead of the actual device 150. It is realized by software.

That is, the program verification system according to the present embodiment enables program verification without waiting for the completion of the actual device even if the program development precedes the actual hardware development. The virtual device 100 that simulates the specifications of the real device corresponding to the new program (program 414) by software while using the real device 150 and the ICE debugger 506, and the virtual device 1
50 adapting 00 to ICE debugger 506
4 are provided.

The virtual wiring 206 is the virtual device 120.
And a debugger 500, and wiring for virtually connecting the automatic verification control unit and the like described in the later embodiment. When the virtual device 100, the debugger 500, etc. are realized by a plurality of personal computers, the virtual wiring 206
As network, USB, RS232C, IEEE
E1394 can be used. Further, when the virtual device 100, the debugger 500, and the like are realized as a plurality of applications or processes that can be independently executed in one personal computer, the virtual wiring 206 is a DDE that enables communication between applications or processes.
It can be realized by using a data communication function such as COM. It should be noted that a specific embodiment of the virtual wiring 206 is described in the previous application (Japanese Patent Application No.
No. 001-219887).

The communication method using the virtual wiring 206 may be either asynchronous communication or synchronous communication. Asynchronous communication is a communication method in which data is sent unilaterally to a communication partner and there is no reply. Synchronous communication is a communication method that waits until reply data is returned from the communication partner after transmitting data to the communication partner.

HTA stands for HTML Applicat
Abbreviation of "ions", various functions (HTML, CSS, script language (Java
(Registered trademark, abbreviated below) Script, VBA, etc.), Be
Havior) is supported.

ActiveX is an Internet-compatible OLE document object ActiveX.
It is an API for developing an eX document and a client application having an Internet access function.

OLE is an Object Linkin
Abbreviation for g and Embedding, an application can call the function of another application and use it as its own function. In the embodiment described below, an example of using the Excel application of Microsoft Corporation from the HTA will be described.

(First Embodiment) An embodiment of the present invention will be described below with reference to the drawings.

The program verification system according to the present embodiment realizes all transfer and synchronization of input / output data between the virtual device 100 and the ICE 400 by software, and the peripheral device 120, the ICE 400, etc. are respectively placed on the virtual wiring 206. By connecting to the program 41
It is a system configuration that enables flexible correspondence in accordance with the verification purpose of item 4. That is, the IC as shown in FIG.
The configuration is different from the conventional system having a dedicated I / F 60 realized by hardware between the E64 and the simulation unit 50.

<System Configuration> In the program verification system according to the present embodiment, as shown in FIG. 1 and the like, the peripheral device 120 required for the operation of the program 414 is composed of the virtual device 100 and the actual device 150. In addition, the virtual device 100 and the debugger 500
Are both connected to the virtual wiring 206.

<Initialization Processing> When the program verification system is started, initialization processing is performed. In the initialization process, the virtual device 100 and the debugger 500 perform a connection process for connecting to the virtual wiring 206. In addition, the bridge 504 of the debugger 500 permits reception interrupts in advance in order to receive messages from the virtual input 102 and virtual output 104 of the virtual device 100.
Further, the ICE 400 puts the program 414 into the execution state in advance.

<Data Transfer from Virtual Input to ICE> Data transfer from the virtual input 102 to the ICE 400 is executed as in (a1) to (a3) below.

(A1) Data transmission from virtual input to virtual wiring: An input event generated at the virtual input 102 designates a RAM write message transfer to the debugger 500 and writes the input event data to the RAM of the synchronization RAM 404. The address and the RAM data are transferred to the bus slot 10
It is sent to the virtual wiring 206 via the synchronous communication via 6.

(A2) Bridge write processing: from virtual input 102 to virtual wiring 206 and bus slot 502
The message sent to the bridge 504 by way of it is received by the synchronous receiving unit 550 that performs a reception interrupt process in the bridge 504, as shown in FIG. After that, the command conversion unit 552 sends the message from the virtual input 102 to the I
In order to conform to the format that the CE debugger 506 can process, according to the message list as shown in FIG. 3, the received message is a 1-byte memory write,
Analyze which message is 1-byte memory read, ICE reset, ICE execution, etc. The command issuing unit 554 passes the analysis result to the Virtual Link 560 in the ICE debugger 506.

The VirtualLink 560 controls the existing debugger 562 designed to perform the verification operation corresponding to the specifications of the actual device 150, and is passed from the virtual input 102 to the synchronization RAM 404 in the ICE 400 during program execution. RAM with specified RAM address
Write data on the fly. After that, the synchronization receiving unit 550 sends back a writing completion notice as a reply to the message to the virtual input 102 that is the sender of the message. "On the fly" means program 4
User RAM 40 in ICE 400 even when 14 is running
2 is a function of the ICE 400 that enables reading and writing of RAM data in the synchronization RAM 404 and the register in the microcomputer emulator 406.

(A3) Transfer processing from synchronization RAM to user RAM; the synchronization program 412 causes the microcomputer emulator 406 to check the program 414 for changes in the data written in the synchronization RAM 404. ing.

For example, in the case of key input, the synchronization program 412 is called immediately after the key input processing of the program 414, and the change generated in the synchronization RAM 404 by the key input data is checked via the microcomputer emulator 406, and there is a change. If so, the key input data is transferred to the user RAM 4
The data is transferred to the key input data confirmation area provided in 02. The key data of the virtual input 102 and the input / output 1 of the actual machine
When the key input data from 56 is simultaneously input, the virtual key data has priority. The order of this process is
It is also possible to change the key input data from the actual device 150 by giving priority to the application.

The key input process in the synchronization program 412 is specifically started by calling the synchronization program 412 from the program 414 as shown in FIG. 4 (step S400). First, the key input data transferred from the virtual device 100 via the microcomputer emulator 406 and stored in the synchronization RAM 404 is read (step S402), and a change in the key input data is checked (step S404).

If there is a change, the key input data is overwritten in the actual machine key input data confirmation area provided in the user RAM 402 (step S406). The actual machine key input data confirmation area is an area in the user RAM 402 in which the data confirmed by the key input from the actual machine input / output 156 should be recorded. In this way, by overwriting the key input from the virtual device 100 in the real machine key input data confirmation area, the virtual key input is processed with priority over the real machine key input.

The key data transferred from the virtual device in the synchronization RAM 404 is cleared (step S4).
08), so that continuous data processing is not performed by the periodically called key processing. If the continuous key is to be validated, step S408 is deleted and virtual input 1
The ON key data may be transmitted when the key is pressed from 02, and the OFF key data may be transmitted when the key is released.

<Data Transfer from User RAM to Virtual Output> On the other hand, the program 414 outputs the output R in the user RAM 402 according to the input data from the virtual input 102.
When the AM data is changed, the procedure for transferring this output RAM data from the user RAM 402 to the virtual output 104 is as follows (b1) to (b4).

(B1) Program user RAM change;
Immediately after the RAM data related to the virtual output 104 in the user RAM 402 is changed by the program 414, processing for transmitting the change from the user RAM 402 to the specific RAM in the synchronization RAM 404 is performed. Specifically, as shown in FIG. 5, the process is started by calling the virtual synchronization program from the program 414 (step S420). User RAM from program 414
Immediately after the output process to the 402 (step S422), a change in the output RAM data in the user RAM 402 is detected (step S424). If there is a change, the output RAM data is transferred from the user RAM 402 to the synchronization RAM 4
The data is transferred in 04 (step S426).

(B2) Data transmission from the virtual output to the virtual wiring; Next, from the virtual output 104, the synchronization RAM 404
To read the change event of the output RAM data in the
The message transfer designation from the virtual output 104 to the debugger 500 and the RAM address for reading the event are sent out to the virtual wiring 206 through the bus slot 108 by synchronous communication together.

(B3) Bridge device read processing;
The message sent from the virtual output 104 to the bridge 504 via the bus slot 502 is as shown in FIG.
It is received by the synchronous reception unit 550 which performs reception interrupt processing. After that, the command conversion unit 552 follows the message list as shown in FIG.
1-byte memory write, 1-byte memory read, ICE
Analyze which message is reset, ICE execution, etc. The command issuing unit 554 displays the analysis result as I
VirtualLink 560 in CE debugger 506
Pass to. The VirtualLink 560 controls the existing debugger 562 to execute the ICE400 during program execution.
The output RAM data in the synchronization RAM 404 therein is read on the fly. After that, the synchronous receiving unit 550 returns the read output RAM data to the virtual output 104 that is the transmission source of the message. As a result, the output R
The transfer of AM data to virtual output 104 is complete.

(B4) Virtual output display processing: virtual output 1
04 displays a virtual LCD on the personal computer monitor based on the output RAM data.

Further, as described above, the synchronization RAM 404
Instead of using the change event of the virtual input 102, by reading the data of the user RAM 402 into the debugger 500 at a constant cycle from the virtual input 102, the virtual LC is displayed at the virtual output 104.
You may make it display D etc.

<Effect> As described above, according to this embodiment, the real device 150 and the virtual device 100 are used as the peripheral devices 120, and the synchronization R is set in the ICE 400.
The AM 404 is provided, and the virtual device 100 and the ICE 400 are provided.
It is possible to perform all the synchronization processing with the software (the bridge 504 and the synchronization program 412). This allows efficient program development without waiting for the completion of the actual debug set.

In this embodiment, a plurality of virtual devices 100 having different functions may be connected to the virtual wiring 206. According to this configuration, there is an advantage that other devices can be easily reused in other automatic verification systems.

(Second Embodiment) In the case where the program development precedes the hardware development, if the actual machine debug set is completed, whether the actual machine debug set is operating normally is checked by using the program under development. It is necessary to verify the operation. However, conventionally, when the actual device debug set does not operate normally at the time of operation verification, it is difficult to determine which of the program and the actual device debug set is bad, and there is a problem that analysis takes time.

Therefore, in the program verification system according to the second embodiment of the present invention, as shown in FIG. 6 and the like, the actual device 150 necessary for the program operation of the program 414.
The actual input 152 and the actual output 154 are connected to the virtual wiring 206 from the ICE 400 via the debugger 500. In addition, the program verification system has a configuration in which the virtual input 102 and the virtual output 104, which virtually realize the same functions as the actual input 152 and the actual output 154, are connected to the virtual wiring 206.

Further, in the program verification system, the camera monitor 202 for displaying the actual output 154 on the PC camera 204 and displaying the image captured by the PC camera 204 is provided on the monitor of the personal computer. Also, the image of the virtual output 104, which has the same function as the actual output 154,
Display on the PC monitor.

Camera monitor 202 and virtual output 104
In order to record the display image of, the recording control unit 302 transfers the key code of the virtual input 102 to the ICE 400, and then displays the actual output 154 and the virtual output 104 in accordance with the display image data in the ICE 400. The displayed image is copied to the clipboard 200 and recorded in the verification result file 350. In addition, the display dump data at that time is also recorded in the verification result file 350.

The verification result file 350 is the actual output 154.
Is an application file that allows a debugging operator to visually compare the execution results of the virtual output 104 and the virtual output 104. For example, Microsoft Excel
(Registered trademark, abbreviated below) and the like. The control program of the recording control unit 302 that controls reading and writing of the verification result file 350 is written using HTA. In addition, the verification result file 350 is
When creating with el, the OLE function is used in order to read and write from the recording control unit 302. Data communication between the recording control unit 302 and the virtual wiring 206 is Ac
It can be realized by using liveX.

<Initialization Processing> When the program verification system according to the present embodiment is also activated, first, initialization processing is performed. The virtual device 100, the debugger 500, and the recording control unit 302 perform connection processing for connecting to the virtual wiring 206. Bridge 504 receives messages from virtual input 102 and virtual output 104 by:
Receive interrupts are enabled in advance. The ICE 400 puts the program 414 into the execution state in advance. The event detection unit 308 includes a virtual input 102 and a bridge 504.
Allow receiving messages from. The image data acquisition unit 310 permits the message reception from the virtual output 104.

<Operation Confirmation of Actual Machine Debug Set> In this program verification system, for example, in order to confirm the operation of the actual output 154, the virtual output device 100 used for the program evaluation by the simulator until the actual output 154 is completed. , Operation comparison with the completed actual output 154,
It can be done as follows.

<Data Transfer from Virtual Input to ICE> The procedure for transferring data from the virtual input 102 to the ICE 400 is (a1) to (a3) described in the first embodiment.
Is almost the same as. However, in the procedure of (a1),
It differs from the first embodiment only in that the virtual input 102 specifies the RAM write message transfer not only to the debugger 500 but also to the event detection 308.

<Data Transfer from User RAM to Virtual Output> When the program 414 changes the output RAM data in the user RAM 402 according to the input data from the virtual input 102 or the like, this output RAM data is changed to virtual output 1
The procedure for transferring to 04 is described in the first embodiment (b
It is almost the same as 1) to (b4). However, in the procedure of (b4), if the virtual output 104 not only displays the output RAM data on the personal computer monitor on the virtual LCD, but also if the output RAM data changes, the event detection unit 308.
On the other hand, the point that the screen change event and the display dump data are transferred via the virtual wiring 206 is different from the first embodiment.

<Image copy event detection from virtual input>
In order to detect the issuance of the key event from the virtual input 102, the key data is sent from the virtual input 102 to the event detection unit 308 via the virtual wiring 206. The event detection unit 308 passes the key data to the image data acquisition unit 310. Further, if there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, the virtual output 104 sends the image change message and the display dump data of the virtual output 104 to the image data acquisition unit 310. Forward.

<Recording Displayed Image> Image Data Acquisition Unit 31
0 writes the key data in the verification result file 350 via the verification result writing unit 304. The verification result writing unit 304 reads and writes data by a method suitable for the format of the verification result file 350.

When the image data acquisition unit 310 receives a display change message from the virtual output 104, it issues an instruction to the capture control unit 306 to display the image on the camera monitor 202, which is the image data of the actual output 154, on the clipboard 200. To capture. Also, the virtual output 104
Similarly, the display image of is also captured on the clipboard 200. The image captured on the clipboard 200 is written in the verification result file 350 by the verification result writing unit 304.

A concrete example of the verification result file 350 is shown in FIG.
Shown in. As shown in FIG. 7, the verification result file 350 is sent from the virtual output 104 when displaying each of the image images of the virtual screen and the actual screen for each combination of the screen mode and the operation key. Display dump data is recorded.

From the verification result file 350 shown in FIG. 7, the screen mode is set to "MDPWRON" and "KPO" is set.
It can be seen that when the key operation defined by the name "WER" (operation to turn on the power) is performed, nothing is displayed on both the virtual screen and the actual screen.
By the key operation defined by the name "KCH UP", the character "CH03" is displayed at the upper right of the screen, and by the key operation defined by the name "KVOL UP", "Vol 24" is displayed at the lower left of the screen. It can be seen that the character "" is displayed. In any of the above key operations, the virtual screen and the actual screen are the same. However, for the key operation defined by the name "KMENU", "M" is displayed at the top line on the virtual screen.
Although "ENU" is displayed, "MEU" is displayed on the actual machine screen.
It is displayed as "0", and the display states of the virtual screen and the real machine screen do not match. This shows that there is a bug in the real machine device 150 regarding the key operation of "KMENU".

Although it is schematically shown in FIG. 7, actually, in the column of “virtual screen” of the verification result file 350,
Virtual output 1 captured on clipboard 200
The image image itself of 04 is pasted. Also,
The image of the actual output 154 captured by the PC camera 204 and captured from the camera monitor 202 to the clipboard 200 is pasted in the “actual screen” field. Therefore, by comparing these image images, the debug operator can easily recognize the difference between the virtual screen and the actual screen.

<Control of a plurality of PC cameras> FIG.
As shown in FIG. 3, in addition to the PC camera 204 for photographing the state of the actual output 154, a PC camera 205 for photographing the state of the actual device input / output 156 is further provided, and the actual device 150
May be configured to be photographed. Note that the actual machine input / output 156
The state of means, for example, a state in which a key input to the actual device 150 is echo-displayed on the actual device monitor, a processing result is displayed on the monitor, and the like. A camera monitor 202 and a camera monitor 203 are connected to the PC camera 204 and the PC camera 205, respectively. Further, the recording control unit 302 is further provided with a capture selection unit 324 that selects a monitor image to be captured from the camera monitor 202 and the camera monitor 203 to the clipboard 200. This makes it possible to record more monitor images.

<Effect> As described above, in the present embodiment,
In order to confirm the operation of the newly developed actual output 154,
Virtual output 104 that operates in the same manner as this actual output 154
(Operation verified) is operated by the ICE 400, and the execution result of the actual output 154 and the virtual output 104 can be visually confirmed by the debug operator, and the verification result file 3
Write to 50. As a result, the actual output 154 and the virtual output 1
The operation comparison of 04 is facilitated, and the operation verification of the hardware of the actual output 154 can be efficiently performed. Further, if a plurality of PC cameras for photographing the state of the actual device 150 are provided, more information can be recorded,
The verification accuracy can be improved.

(Third Embodiment) The main difference between the program verification system according to the third embodiment of the present invention and the program verification system according to the second embodiment is that the program verification according to the present embodiment is performed. The system consists in performing automatic program verification. Therefore, as shown in FIG. 9 and the like, the program verification system includes the verification result file 350 and the recording control unit 3 described in the second embodiment.
02, a scenario file 352, and a scenario control unit 314 that controls reading and writing of the scenario file 352. The recording control unit 302 and the scenario control unit 31
4 configures an automatic verification control unit 300 for realizing automatic program verification.

The scenario file 352 is an operation procedure (scenario) for automatically verifying the program 414.
Is a file in which is recorded, and can be realized by using, for example, Excel of Microsoft Corp., similarly to the verification result file 350. Automatic verification control unit 30
The control program of 0 is written using HTA. Further, when the verification result file 350 and the scenario file 352 are created in Excel, the OLE function is used in order to read and write these from the automatic verification control unit 300. In addition, the automatic verification control unit 300 and the virtual wiring 2
Data communication with 06 can be realized by using ActiveX.

The configuration and operation of this program verification system will be specifically described below.

This program verification system is ICE40
The display of the virtual output 104 is updated based on the change of the display image data in 0, and the display image of the virtual output 104 is transferred via the clipboard 200 to the verification result file 350.
And the expected value data for verification recorded in the verification result file 350 in advance is automatically compared.

<Automatic Sequence of Data Transfer from Scenario to ICE> The automatic verification process of the program verification system will be described below. The automatic verification processing is performed by the automatic verification control unit 300 by reading the key data and the like from the scenario file 352, automatically transferring the data to the ICE 400 and causing the ICE 400 to execute, and writing the execution result in the verification result file 350 for evaluation.

In the scenario file 352, operation information (key data etc.) necessary for operation verification is recorded in advance according to the verification procedure. Scenario file 352
Is created as a state transition table as shown in FIG. 11, for example, using the Excel file. In this program verification system, after the screen mode is set to a predetermined state according to the operation sequence described in the scenario file, the event key is issued and the action (valid or invalid) for each key input is confirmed. To do.
For example, in the case of the scenario file 352 shown in FIG.
According to the execution order shown in FIG. 11, first, in the state where the screen mode is set to “MDPWRON”, “KPOWER”,
"KCH UP", "KVOL UP", "KMEN"
U "and" KSET "key inputs are sequentially performed to verify the operation of the virtual device and the actual device with respect to each of these key operations.
In the state of "NU", as in the above, "KPOWER",
"KCH UP", "KVOLUP", "KMEN"
Key operations of "U" and "KSET" are sequentially performed to verify the operation of the virtual device and the actual device.
The same verification is performed for each screen mode of "TIMER", "MDSET", and "MDTEST".

Here, the scenario file 3 shown in FIG.
The details of the automatic verification process using 52 will be described more specifically by taking the case where the operation verification for each key input in the state of the screen mode “MDMENU” is performed as an example. The automatic verification control unit 300 verifies the operation for the key input in the screen mode "MDMENU" by the following procedures (1) to (9).

(1) "1" is set in the reset completion monitor flag RAM in the synchronization RAM 400.

(2) In order to cause the ICE 400 to initialize the program 414, the scenario reading unit 316 instructs the data transmitting unit 320 to issue a reset GO command. The "Reset GO" command means ICE40
The "reset" command to stop the execution of the real machine program 410 and initialize it to 0 and the "GO" command to make the ICE 400 start the execution of the real machine program 410 from the beginning are executed in series. Data transmission unit 320
Synchronizes with the ICE through the bridge 504.
Send a reset GO message to the debugger 506. The real machine program 410 is reset and started by the ICE debugger 506 executing the reset GO of the ICE 400. The reset completion monitor flag RAM value is set to "0" in the start program of the actual program reset start execution. When the ICE 400 completes the reset GO, the scenario read 316 section is reset G from the bridge 504 via the data transmission section 320.
O Complete notification.

(3) Flag RAM for reset completion monitor
After confirming that the value has become “0”, in order to set the screen mode to “MDMENU”, the scenario file 35
In 2, the scenario reading unit 316 sequentially reads and issues the keys described in the operation sequence of the screen mode. The issued key is the data transmission unit 32.
0, bus slot 312, virtual wiring 206, debugger 5
It is passed to the ICE 400 via 00. In the example of FIG. 11, the key “KPOWER” is described as the first operation of the operation sequence of “MDMENU” (column of operation 1 in the scenario file of FIG. 11).
This key is issued first.

(4) The user RAM 402 determines whether the actual machine program 410 has completed the processing of the "KPOWER" key.
Confirm by checking the change of the value in the specific RAM inside. When the change in the specific RAM can be confirmed, next, “KME” described in the operation 2 of the operation sequence is described.
NU "key is issued, and user RAM 40
By checking the change of the specific RAM in 2,
Check if the "KMENU" key processing is completed. The above processing is repeatedly executed up to the last key described in the operation sequence of the scenario file 352.
In the case of “MDMENU” shown in FIG. 11, “KPOWE
By executing the "R" key and the "KMENU" key, the target screen mode "MDMENU" is set.

(5) When the desired screen mode is set, first, the image data in the user RAM 402 is loaded into the synchronous RAM 4
Take in 04.

(6) Next, the issuance keys described in the scenario file 352 are sequentially issued to verify the operation. In the example of FIG. 11, first, the "KPOWER" key is issued. It is confirmed by the change of the specific RAM value in the user RAM 402 that the processing of the "KPOWER" key is completed.

(7) When it is confirmed that the processing of the "KPOWER" key is completed, the processing result of this "KPOWER" key is verified. The virtual output 104 notifies the event detection unit 308 of the presence / absence of screen change. The event detection unit 308 determines whether or not there is a screen change based on the scenario file 352.
Judge whether the valid / invalid specifications described in are met.

For example, in the scenario file shown in FIG. 11, a circle symbol indicates that the key issuance in the screen mode is valid, and a cross symbol indicates that the key issuance in the screen mode is invalid. Represent In addition,
"Key issuance is valid" means that the key issuance causes some changes on the screen, and "key issuance is invalid" means that the key issuance does not cause any changes on the screen. Say.

Here, the column of "MDMENU" and "KP"
If a "KPOWER" key is issued when the screen mode is "MDMENU", if this key is processed correctly, then some kind of "○" is written in the column corresponding to the intersection with the "OWER" line. Therefore, if the screen change occurs due to the issuance of the “KPOWER” key, the event detection unit 308
"KPOWER" in "MDMENU" screen mode
It is judged that the valid / invalid specification of the key is satisfied.

The event detection unit 308 colors the valid / invalid specification column of the scenario file 352 according to the result of the determination as to whether the valid / invalid specifications are satisfied. That is, the event detection unit 308 determines that the scenario file 35
If it is determined that the valid / invalid specification described in 2 is satisfied, the display attribute of the valid / invalid specification column of the scenario file 352 is set to, for example, blue via the verification result writing unit 304. If it is determined that the condition is not satisfied, for example, the color is set to red so that the abnormal operation can be recognized. As a result, the debug operator can easily identify whether the target specification is satisfied by the display color of the valid / invalid specification column of the scenario file 352. Further, here, the verification result of the valid / invalid specification is recorded in the scenario file 352, but the verification result file 350 may be provided with a column for recording the verification result of the valid / invalid specification.

(8) Further, the verification result writing unit 304 writes the screen data (executed image data) acquired from the user RAM 402 by the image data acquisition unit 310 into the verification result file 350. Furthermore, the verification result writing unit 304
Compares the execution image data with reference image data created in advance before executing the verification process, and writes the comparison result to the verification result file 350. The reference image data is dump data of image data that should be displayed as a result of correct processing of the key, and is written in the verification result file 350 as shown in FIG. For example, in the verification result file 350 according to the example shown in FIG. 12, if the comparison result of the reference image data and the execution image data is coincident, a ◯ symbol is written, and if they are not coincident, an x symbol is written in the “judgment” column. There is. As a result, the debug operator can easily verify whether or not the predetermined screen data is displayed by issuing the key, simply by looking at the determination column of the verification result file 350.

(9) Further, the verification result file 350 has a screen image (reference screen) based on the reference image data.
Is attached in advance. The verification result writing unit 304
As shown in FIG. 12, the screen (execution screen) output to the virtual output 104 is pasted to the column next to the reference screen via the clipboard 200. As a result, the debug operator can easily identify the difference between the reference screen and the execution screen just by looking at the verification result file 350.

When the processes up to (9) for the "KPOWER" key are completed, the process returns to (5) and (6).
In step 1, the next issue key "KCH UP" described in the scenario file is issued, and the subsequent processing is performed. Similarly, the verification result file as shown in FIG. 12 is completed by repeating the processes of (5) to (9) for all the issued keys described in the scenario file.

In the present embodiment, the existing debugger 562 monitors the behavior of the ICE 400 in order to prevent the automatic verification process from being unable to continue if the ICE 400 becomes abnormal due to some cause during the automatic verification process. To do. When a change occurs in the operation of the ICE 400, the ICE debugger 506 sends a message as shown in FIG. 13 to the ICE status monitor 558 in the bridge 504.
(See Figure 2). In addition, this message
From the CE status transmission unit 556, via the virtual wiring 206,
It is transmitted to the timing control unit 318 in the scenario control unit 314. As a result, the timing control unit 318 causes the I
The scenario reading unit 31 is adapted to the operation change of the CE 400.
6 to reissue the data of the scenario file 352.

As described above, according to this embodiment, automatic program verification can be realized.

<Remote Control> As shown in FIG. 10, an execution status distribution unit 322 for distributing the execution status of the automatic verification process is provided in the recording control unit 302, and electronic mail is sent and received to and from an external device. The electronic mail transmitting / receiving unit 602 for performing the above may be further provided. With this configuration, the execution status distribution unit 322 to the e-mail transmission / reception unit 60
If the execution status of the automatic verification process is delivered to the portable information terminal 604 and the like via E-mail via 2, the execution status of the automatic verification process can be monitored in real time from a remote location.

When a defect of the program 414 is found during execution of the automatic verification processing, the program verification is performed from the portable information terminal 604 or the like by using the debugger control command as shown in FIG. 3 as an e-mail message. This program verification system can be controlled remotely by sending it to the system. Further, the remote control result is distributed from the execution status distribution unit 322 to the portable information terminal 604 or the like by electronic mail via the electronic mail transmission / reception unit 602.

As a result, the program verification system can be remotely controlled.

In the automatic verification processing, instead of using the above-mentioned state transition table as the scenario file 352, the description method of the scenario file 352 and the control method of the automatic verification control unit 300 can be changed as appropriate to perform arbitrary automatic verification. Processing can be realized.

<Specific Operation> The operation of the program verification system for automatically verifying a program will be described in more detail below.

<Initialization Processing> When the program verification system (configuration shown in FIG. 10) of this embodiment is also activated, first, initialization processing is performed. The virtual device 100, the debugger 500, the automatic verification control unit 300, and the electronic mail transmission / reception unit 602 perform connection processing for connecting to the virtual wiring 206. Further, the bridge 504 permits reception interrupt in advance in order to receive a message from the data transmission unit 320 and the virtual output 104. Further, the execution status distribution unit 322 permits the message reception from the virtual output 104. Further, the execution status monitor 606 in the electronic mail transmitting / receiving unit 602 permits reception from the execution status distribution unit 322.

<Reset from reading scenario to virtual wiring G
Stream O command data> From the scenario reading unit 316,
In order to initialize the execution of ICE400, reset GO
The data transmission unit 320 is instructed to transmit the command. The data transmitting unit 320 sends a message created according to the format of the reset GO command as shown in FIG. 3 to the bridge 504 by synchronous communication from the bus slot 106 to the virtual wiring 206.

<Bridge Device Writing Process> The bridge 5 is transmitted from the data transmitting unit 320 via the bus slot 502.
As shown in FIG. 2, the message sent to 04 is received by the synchronous receiving unit 550 that performs a reception interrupt process.
The command conversion unit 552 refers to the table as shown in FIG. 3, analyzes which message the received message is, such as 1-byte memory write, 1-byte memory read, ICE reset, or ICE execution, and the result is analyzed. From the command issuing unit 554 to the Vi in the ICE debugger 506.
It is passed to the realLink560.

The VirtualLink 560 controls the existing debugger 562, issues a reset command to the ICE 400, then issues an execution start command, and sends an execution completion notification as reply data of the synchronous receiving unit 550, which is the sender of the message. It returns to the data transmission unit 320.
The data transmission unit 320 notifies the scenario reading unit 316 of the completion of the reset GO command execution, and the scenario file 35
Execute according to the contents of 2.

<Flow of data from scenario file to virtual wiring> The scenario reading unit 316 reads the key code from the scenario file 352, and the data transmitting unit 320
1 in the message list as shown in FIG.
A message created according to the byte memory write command issuance format is sent to the bridge 504 from the bus slot 106 to the virtual wiring 206 by synchronous communication.

<Bridge Write Processing> Data Transmission 32
The message sent from 0 to the bridge 504 via the bus slot 502 is received by the synchronous receiving unit 550 that performs a reception interrupt process, as shown in FIG. And
The command conversion unit 552 analyzes whether the received message is a 1-byte memory write, 1-byte memory read, ICE reset, or ICE execution message based on the table shown in FIG. The analysis result is output from the command issuing unit 554 to the ICE debugger 506.
It is passed to the Virtual Link 560 in.

The VirtualLink 560 controls the existing debugger 562 to store the virtual input 10 in the synchronization RAM 404 in the ICE 400 executing the program 414.
After writing on-the-fly the RAM data of the designated RAM address passed from 2, the write completion notice is returned to the data transmitting unit 320 that is the sender of the message as the reply data of the synchronous receiving unit 550. When you receive a reply,
The execution status distribution unit 322 informs the event detection unit 308 that the key data has been distributed.

<Transfer Processing from Synchronizing RAM to User RAM> The synchronizing program 412 has the synchronizing RAM 404.
The microcomputer emulator 406 is caused to check the change of the above at a timing necessary for the program 414.

For example, in the case of key input, the synchronization program 412 is called immediately after the key input processing of the program 414, checks the change of the key data RAM in the synchronization RAM 404 via the microcomputer emulator 406,
If there is a change, the key data is transferred to the key data confirmation area of the user RAM 402. At this time, virtual input 1
When the key data of 02 and the key data from the actual device 150 are simultaneously input, the key data from the virtual input 102 is prioritized.

The key input processing in the synchronization program 412 is specifically as described with reference to FIG. 4 in the first embodiment. This makes virtual key input
It is processed with priority over the actual key input.

<Data Transfer from User RAM to Virtual Output> When the program 414 changes the output RAM data in the user RAM 402 (output data to the virtual output 104) by the key code read from the scenario file 352, this output RAM The method of transferring data to the virtual output 104 is as described in (c1) to (c4) below.

(C1) User RAM change of program;
Immediately after the RAM area related to the virtual output 104 in the user RAM 402 is changed by the program 414, processing for transmitting the change from the user RAM 402 to the specific RAM in the synchronization RAM 404 is performed. Specifically, as shown in FIG. 5, the process is started by calling the virtual synchronization routine from the program 414 (step S420). Immediately after performing the output process (step S422) to the actual device 150, the actual device 150
To detect the change in the output RAM data to (step S42
4) If there is a change, output RAM data to user RAM
The data is transferred from 402 to the synchronization RAM 404 (step S426).

(C2) Flow data from the virtual output to the virtual wiring; next, from the virtual output 104, the synchronization RAM 404
To read the change event of the output RAM data in the
The message transfer designation from the virtual output 104 to the debugger 500 and the RAM address for reading the event are sent out to the virtual wiring 206 through the bus slot 108 by synchronous communication together.

(C3) Bridge device read processing;
The message sent from the virtual output 104 to the bridge 504 via the bus slot 502 is as shown in FIG.
It is received by the synchronous reception unit 550 which performs reception interrupt processing. After that, the command conversion unit 552 follows the message list as shown in FIG.
1-byte memory write, 1-byte memory read, ICE
Analyze which message is reset, ICE execution, etc. The command issuing unit 554 displays the analysis result as I
VirtualLink 560 in CE debugger 506
Pass to. The VirtualLink 560 controls the existing debugger 562 to execute the ICE400 during program execution.
The output RAM data in the synchronization RAM 404 therein is read on the fly. After that, the synchronous receiving unit 550 returns the read output RAM data to the virtual output 104 that is the transmission source of the message. As a result, the output R
The transfer of AM data to virtual output 104 is complete.

(C4) Virtual output display processing; virtual output 1
At 04, a virtual LCD is displayed on the personal computer monitor based on the output RAM data. Further, if there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, the virtual output 104 sends a message of an image change and a message to the image data acquisition unit 310 via the execution status distribution unit 322. The display dump data of the virtual output 104 is transferred.

Further, without using the above-mentioned event, the user RA is sent to the debugger 500 at a constant cycle from the virtual input 102.
Read the data of M402 and output virtual L at virtual output 104.
A method of displaying a CD or the like may be used.

<Transfer from data transfer to event detection> When the key data is sent from the data transmission unit 320 to the execution status distribution unit 322, the key data is passed from the event detection unit 308 to the image data acquisition unit 310. Be done.
If there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, an image change message is sent from the virtual output 104 to the image data acquisition unit 310 via the execution status distribution unit 322. Also, display dump data of virtual output is transferred.
The image data acquisition unit 310 writes the key data in the verification result file 350 from the verification result writing unit 304.

When the image data acquisition section 310 receives a display change message from the virtual output 104, it captures the display image of the virtual output 104 on the clipboard 200. The image captured on the clipboard 200 is written in the verification result file 350 by the verification result writing unit 304.

Specifically, as shown in FIG. 12, the key data is written in the operation key column, and the scenario file 352 is written.
The screen mode of is written in the screen mode column.

<Comparison of Reference Image Data and Execution Image Data> In the verification result file 350, the difference between the “reference image data” and the “execution image data” is determined,
Write the judgment result as "○" and "x" in the "judgment" column. When the verification result file 350 is created in Excel, the IF function can be used to determine the difference between the “reference image data” and the “execution image data”.

<Creation of Reference Image Data> Regarding the creation of the reference image and its display dump data for performing the automatic verification processing, the image data and the display dump data are shown in FIG. It can be created by writing on the screen and execution image data.

<Effect> As described above, according to the present embodiment, the program file can be automatically verified by using the scenario file, and the evaluation efficiency can be improved. Also, the execution status of the automatic program verification can be monitored from a remote location.

(Fourth Embodiment) After the hardware of the actual machine in which the program 414 is to be installed is completed, as shown in FIG. 14, a program verification system using only the actual machine debug set without using virtual devices. Therefore, it is possible to perform automatic verification.

[0121]

As described above, according to the present invention, the ICE
In the program verification system that uses, the peripheral device can be realized without the hardware for performing the program verification by dividing the peripheral device into the actual device and the virtual device, and the program verification system can be constructed in a short time. With regard to automatic verification, the output display such as an LCD display can be recorded as it is, regardless of whether it is an actual device or a virtual device, so that the program verification time can be shortened. Further, since the automatic verification can be remotely controlled, the program can be debugged and verified by remote control, thus improving work efficiency.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a program verification system according to a first embodiment of the present invention.

FIG. 2 is a block diagram showing the internal configuration of the debugger.

FIG. 3 is an explanatory diagram of a list of messages from the virtual device to the bridge.

FIG. 4 is a flowchart of key input processing.

FIG. 5 is a flowchart of display output processing.

FIG. 6 is a block diagram showing a configuration of a program verification system according to a second embodiment of the present invention.

FIG. 7 is an explanatory diagram showing an example of a verification result file.

FIG. 8 is a block diagram of a program verification system using a plurality of cameras as a modification of the program verification system according to the second embodiment.

FIG. 9 is a block diagram showing the configuration of a program verification system according to a third embodiment of the present invention.

FIG. 10 is a block diagram of a modified example of the program verification system according to the third embodiment.

FIG. 11 is an explanatory diagram showing an example of a scenario file.

FIG. 12 is an explanatory diagram showing an example of a verification result file according to the third embodiment.

FIG. 13 is an explanatory diagram showing a list of events from ICE to a virtual device.

FIG. 14 is a block diagram showing the configuration of a program verification system according to a fourth embodiment of the present invention.

FIG. 15 is a block diagram of a conventional program verification system using an actual debug set.

FIG. 16 is a block diagram of a program verification system using a conventional system simulator set.

FIG. 17 is a block diagram of a conventional program verification system in which an actual set and simulator are embedded together.

[Explanation of symbols]

100 virtual devices 102 virtual input 104 virtual output 120 peripheral devices 150 real devices 152 Actual input 154 actual output 156 Actual machine input / output 200 clipboard 202,203 Camera monitor 204,205 PC camera 206 virtual wiring 300 Automatic verification control unit 302 recording control unit 304 Verification result writing unit 308 Event detector 310 Image data acquisition unit 312 bus slots 314 Scenario control unit 316 Scenario reading unit 318 Timing control unit 320 data transmitter 322 Execution status distribution unit 350 Verification result file 352 Scenario file 400 ICE 402 user RAM 404 synchronization RAM 410 Actual program 412 synchronization program 500 debugger 502 bus slot 504 bridge 506 ICE Debugger 600 E-mail sending and receiving unit 604 Personal digital assistant 606 Execution status monitor 608 remote control unit 610 Mail delivery control unit

   ─────────────────────────────────────────────────── ─── Continued front page    F term (reference) 5B042 GA13 GA36 HH06 HH07                 5B048 AA13 DD08 DD17

Claims (10)

[Claims] 1. A program verification system for verifying the operation of the program for the microcomputer by using an actual device and a virtual device as peripheral devices of the microcomputer, and an emulator for emulating the operation of the program on the microcomputer, A verification control unit that controls the emulator to perform a verification operation corresponding to an actual device, and is provided between the verification control unit and the virtual device,
A bridge unit that adapts the control signal and data from the virtual device to the verification control unit, a real machine RAM that stores input / output data between the real machine device and the program, the real machine RAM, and the virtual device A synchronization RAM provided between the synchronization RAM and the real machine device, and controls the data transfer between the synchronization RAM and the real machine RAM in synchronization with the input / output operation of the program with respect to the real machine device. A program verification system comprising a processing unit. 2. The program verification system according to claim 1, wherein the virtual device and the bridge unit are connected by virtual wiring. 3. The program verification system according to claim 1, comprising a plurality of the virtual devices. 4. A verification result of a photographing device for photographing an actual device monitor output image output by the actual device device, the actual device monitor output image, and a virtual monitor output image output by the virtual device monitor. The program verification system according to claim 1, further comprising a verification result writing unit that records the file in a file. 5. An event detection unit that detects a predetermined change in the peripheral device, and a timing according to a detection result of the event detection unit,
The program verification system according to claim 4, further comprising: an image acquisition unit that captures the real machine monitor output image and the virtual monitor output image. 6. According to the detection result of the event detection unit,
The program verification system according to claim 5, further comprising a verification status distribution unit that transmits a verification processing status including the real machine monitor output image or the virtual monitor output image to an external terminal. 7. The remote control unit further comprising a remote control unit that receives a message including a control signal and its destination from an external terminal, extracts the control signal from the received message, and delivers the control signal to the destination of the control signal. 6. The program verification system according to 6. 8. The apparatus according to claim 4, further comprising a plurality of the photographing devices.
The program verification system according to any one of items 1 to 7. 9. The scenario control unit according to claim 1, further comprising a scenario control unit that reads data from a scenario file recording an operation procedure for automatically verifying the program and transfers the data to the bridge unit. The program verification system described in the item. 10. The program verification system according to claim 9, further comprising a timing control unit that controls transfer of data read from the scenario file to the bridge unit in accordance with an operation status of the emulator.