Program, debugging device, debugging system, and debugging method

Abstract

This debugging device (10) comprises a simulation unit (102) for outputting an operation signal to an HMI (20) and simulating the operation of a user with respect to the HMI (20) in order to debug the screen image design of the HMI (20), and a performance document generation unit (106) for generating a debug test performance document on the basis of a log outputted by the HMI (20) in accordance with the operation signal.

Description

Program, debugging device, debugging system and debugging method

[0001] The present disclosure relates to a program, a debugging device, a debugging system, and a debugging method.

[0002] When designing the screen of a programmable display (Human Machine Interface: hereafter also referred to as "HMI"), screen design software called drawing software is used. The data related to the screen design created by the drawing software is called project data.

[0003] Project data created with drawing software requires debugging. When debugging, it is necessary to thoroughly check all conditions for transitions to the created full screen, pressing all created switches, boundary values ​​for numerical input, and conditional branching of script statements.

[0004] Patent Document 1 discloses a debugging device that outputs coverage screen data that combines items including objects, devices, and execution conditions displayed on the operation screen of a display device, and can confirm whether all set execution conditions have actually been met using a simulation function based on the coverage screen data. The debugging device of Patent Document 1 makes debugging verification easy. Note that coverage indicates whether all items to be tested have been tested without omission, or whether there are any omissions in items to be tested.

[0005] Japanese Patent Application Laid-Open No. 2006-155158

[0006] However, when debugging using the debugging device of Patent Document 1, it is necessary to manually set in advance which items will be the targets of coverage measurement and create a test plan. Furthermore, in order to create evidence of the debugging, it is necessary to create a test report reflecting the results of the debugging after the debugging. A test plan is a summary of the items to be tested. A test report is a document that shows that all items to be tested have been tested without omission and indicates the test results of each test item. Therefore, creating evidence of the debugging requires a lot of effort.

[0007] In view of the above circumstances, an object of the present disclosure is to provide a program or the like that can easily generate a test report when debugging the screen design of a programmable display.

[0008] In order to achieve the above object, the program of the present disclosure causes a computer to function as: a simulation means that outputs an operation signal to a programmable display to simulate a user's operation on the programmable display in order to debug the screen design of the programmable display; and a report generation means that generates a test report of the debugging based on a log output by the programmable display in response to the operation signal.

[0009] According to the present disclosure, a test report can be easily generated when debugging the screen design of a programmable display.

[0010] FIG. 1 is a diagram showing the overall configuration of a debugging system according to an embodiment of the present disclosure. FIG. 2 is a diagram showing an example of project data in a debugging system according to an embodiment of the present disclosure. FIG. 3 is a diagram showing an example of a log output by an HMI according to an embodiment of the present disclosure. FIG. 4 is a diagram showing an example of a test report output by a debugging device according to an embodiment of the present disclosure. FIG. 5 is a diagram showing an example of the hardware configuration of a debugging device according to an embodiment of the present disclosure.

[0011] A debugging system according to an embodiment of the present disclosure will be described below with reference to the drawings. In each drawing, the same or equivalent parts are denoted by the same reference numerals.

[0012] (Embodiment) A debugging system 1 according to an embodiment will be described with reference to Fig. 1. The debugging system 1 includes an HMI 20, which is a programmable display, and a debugging device 10 for debugging the screen design of the HMI 20. The debugging system 1 is an example of a debugging system according to the present disclosure.

[0013] The debugging device 10 is a debugging device for debugging the screen design of the HMI 20. The debugging device 10 is, for example, a personal computer on which drawing software is installed. The debugging device 10 simulates operations on the HMI 20 by outputting operation signals to the HMI 20 based on input operations by a user to the debugging device 10 and project data related to the screen design of the HMI 20. As described below, the HMI 20 executes various operations in response to the operation signals and outputs a log of the execution results to the debugging device 10. The debugging device 10 generates and outputs a test report based on the log and project data output by the HMI 20. The debugging device 10 also determines whether any test items have been omitted based on the log and project data. If any test items have been omitted, the debugging device 10 notifies the user that there is an omission in the user's input operation. If no test items have been omitted, the debugging device 10 notifies the user that debugging has been completed. The functional configuration of the debugging device 10 will be described below. The debugging device 10 is an example of a debugging device according to the present disclosure.

[0014] The HMI 20 is a programmable display (HMI). The HMI 20 displays a screen based on project data created by drawing software and accepts operations from a user. However, when debugging the HMI 20 using the debugging system 1, the HMI 20 accepts operation signals from the debugging device 10 instead of accepting operations from a user. This allows the user to simulate operations on the HMI 20 by inputting operations to the debugging device 10. The HMI 20 performs various operations in response to the operation signals. For example, when the project data includes data related to multiple screens and the operation signal is a screen transition operation, the HMI 20 performs a screen transition operation. The HMI 20 outputs a log of the execution results of the operation to the debugging device 10. The HMI 20 is an example of a programmable display according to the present disclosure.

[0015] Referring to FIG. 2, an example of project data related to screen design created by drawing software will be described. The project data shown in FIG. 2 includes data related to screen switching settings, data related to screen group settings, data related to object settings, and data related to script settings. The screen switching settings data and screen group settings data allow switching between multiple screens via operations on the HMI 20. The object settings allow objects that can accept user operations, such as switches and numeric input objects, to be displayed on the screen. The script settings are settings related to script statements executed on the HMI 20. While only one script statement is set in FIG. 2, the script settings may include settings related to multiple script statements. Furthermore, one script statement typically includes one or more conditional branches. Note that character strings such as GD100 and GB100 shown in FIG. 2 represent device names.

[0016] An example of a log output by the HMI 20 in response to an operation signal will be described with reference to Fig. 3. The log shown in Fig. 3 includes elements such as screen switching, objects, and scripts that were the targets of operations in response to the operation signal, the target device name indicating the target device, input values ​​input to the target device, and output information output as a result of the operation. The debugging device 10 analyzes this log against the project data, generates a test report, and determines whether there are any omissions in the user's input operations.

[0017] For example, by analyzing the screen switching settings and screen group settings indicated by the project data and the screen switching items indicated by the log, it is possible to obtain test results regarding the comprehensiveness of screen transitions and determine whether there are any missing input operations related to screen transitions.

[0018] Similarly, by analyzing the object settings indicated by the project data and the object items indicated by the log, it is possible to obtain test results for the comprehensiveness of switch presses displayed on the screen, and determine whether all switches have been pressed or whether there are any switches that have not been pressed and therefore whether there are any missing input operations. For example, the project data shown in FIG. 2 includes two switches, one with a device name GB100 and the other with a device name GB101. Meanwhile, the log shown in FIG. 3 indicates that the switch with the device name GB100 is on and off, but the press status of the switch with the device name GB101 is unknown. If the log shown in FIG. 3 does not include a log related to the switch with the device name GB101, then a switch press operation is missing. Examples of switches displayed on the screen include pushbutton switches, slide switches, rotary switches, and the like. Examples of switch operations include touch operations and swipe operations. Because all of these operations involve pressing the screen, these operations are collectively referred to as "pressing."

[0019] Similarly, by analyzing the object settings indicated by the project data and the object items indicated by the log, it is possible to obtain test results for the coverage of boundary values ​​in a numeric input object and determine whether there are any omissions in the entry of boundary values. Boundary values ​​are the lower and upper limits that can be entered into a numeric input object. Comprehensive boundary value coverage means entering a boundary value and the next value beyond the boundary value into a numeric input object to check its operation. For example, as shown in Figure 2, because a numeric input object is an unsigned 16-bit object, only values ​​between 0 and 65535 are correctly accepted. Therefore, the boundary values ​​are 0 and 65535, and the next values ​​beyond the boundary value are -1 and 65536.

[0020] Similarly, by analyzing the script settings indicated by the project data and the script items indicated by the log, it is possible to obtain test results for the comprehensiveness of the conditions of the conditional branches included in the script statements, and to determine whether any input operations have been omitted. For example, as shown in Figure 2, the script statement of script number 1 indicated by the script settings includes a conditional branch of whether to execute Path1 or Path2 depending on whether device GB100 is 1. From the script items shown in Figure 3, it can be seen that execution is performed both when GB100 is 1 and when it is not, so in this case, each condition of the conditional branch is covered.

[0021] An example of a test report generated by the debugging device 10 will be described with reference to Fig. 4. The test report shown in Fig. 4 is generated based on the log shown in Fig. 3, but differs from the log in that it has a "Verification Result" item with the same content as the "Output Information" item shown in Fig. 3, and also has a "Judgment Result" item. The "Judgment Result" is compared with the project data shown in Fig. 2, and if there are no problems with the verification results, it is judged as "OK."

[0022] 1 , the functional configuration of the debugging device 10 will be described. The debugging device 10 includes a project storage unit 100, an input unit 101, a simulation unit 102, a communication unit 103, a log acquisition unit 104, a log storage unit 105, a test report generation unit 106, a test report output unit 107, an error determination unit 108, a notification unit 109, and a display unit 110.

[0023] The project storage unit 100 stores project data created by drawing software and related to the screen design of the HMI 20. As described above, when the debugging device 10 is a personal computer on which drawing software is installed, the project data is usually created by the debugging device 10. However, the project data may also be created by drawing software executed on a device other than the debugging device 10.

[0024] The input unit 101 receives an input operation from a user and outputs a signal corresponding to the user's input operation to the simulation unit 102. The input unit 101 includes input devices such as a keyboard and a mouse. Alternatively, the input unit 101 may be a touch screen integrated with the display unit 110 described below.

[0025] The simulation unit 102 generates an operation signal for simulating a user's operation on the HMI 20 based on the signal corresponding to the user's input operation output by the input unit 101 and the project data stored in the project storage unit 100, and outputs the operation signal to the communication unit 103. The simulation unit 102 is an example of a simulation means according to the present disclosure.

[0026] The communication unit 103 communicates with the HMI 20. In particular, the communication unit 103 transmits operation signals output by the simulation unit 102 to the HMI 20, receives logs output by the HMI 20, and outputs them to a log acquisition unit 104 described below.

[0027] The log acquisition unit 104 acquires the log received by the communication unit 103 from the HMI 20 and stores it in the log storage unit 105 described below.

[0028] The log storage unit 105 stores the logs acquired and stored by the log acquisition unit 104 .

[0029] The test report generation unit 106 generates a test report based on the log stored in the log storage unit 105 and the project data stored in the project storage unit 100. However, the test report is generated only when the omission determination unit 108, which will be described later, determines that there are no omissions in the user's input operations. This is because the test report indicates that all items that should be tested have been tested without omissions. The test report generation unit 106 outputs the generated test report to the test report output unit 107. The test report generation unit 106 is an example of a test report generation means according to the present disclosure.

[0030] The test report output unit 107 controls the display unit 110 (described later) to display the test report output by the test report generation unit 106 on the display unit 110. This allows the user to check the test report. The test report output unit 107 may also store data indicating the test report in a storage unit (not shown).

[0031] The leak determination unit 108 determines whether there is a missing test item required for debugging based on the log stored in the log storage unit 105 and the project data stored in the project storage unit 100. For example, when the project data is as shown in FIG. 2 , the leak determination unit 108 checks the log for comprehensiveness of transitions to all screens, comprehensiveness of all switch presses, comprehensiveness of boundary values ​​for numerical inputs, and comprehensiveness of conditions for conditional branches in script statements, and determines whether there is a missing test item. For example, when some switches are not pressed, it determines that there is a missing switch press. The leak determination unit 108 outputs a signal indicating the determination result to the notification unit 109. The leak determination unit 108 is an example of a leak determination means according to the present disclosure.

[0032] When the omission determination unit 108 determines that there is an omission in a required test item, the notification unit 109 controls the display unit 110 (described below) to display on the display unit 110 that there is an omission in the user's input operation, thereby notifying the user. As described above, the log is output by the HMI 20 in response to an operation signal output by the simulation unit 102, and the operation signal is based on the user's input operation on the input unit 101. Therefore, when there is an omission in a required test item, it means that there is an omission in the user's input operation. The notification unit 109 is an example of a notification means according to the present disclosure.

[0033] In addition, when the omission determination unit 108 determines that there are no omissions in the required test items, the notification unit 109 controls the display unit 110 described below to display on the display unit 110 that debugging has been completed, thereby notifying the user.

[0034] The display unit 110 displays the test report under the control of the report output unit 107. The display unit 110 displays information indicating that the user has omitted an input operation and that debugging has been completed under the control of the notification unit 109. The display unit 110 is, for example, a liquid crystal display. The display unit 110 may also be a touch screen integrated with the input unit 101.

[0035] An example of the hardware configuration of the debugging device 10 will be described with reference to Fig. 5. The debugging device 10 shown in Fig. 5 is realized by a computer such as a personal computer or a microcontroller.

[0036] The debugging device 10 includes a processor 1001 , a memory 1002 , an interface 1003 , and a secondary storage device 1004 , which are connected to each other via a bus 1000 .

[0037] The processor 1001 is, for example, a CPU (Central Processing Unit). The processor 1001 loads an operating program stored in a secondary storage device 1004 into a memory 1002 and executes the program, thereby realizing each function of the debugging device 10.

[0038] The memory 1002 is a main storage device configured, for example, by a RAM (Random Access Memory). The memory 1002 stores the operating program that the processor 1001 reads from the secondary storage device 1004. The memory 1002 also functions as a working memory when the processor 1001 executes the operating program.

[0039] The interface 1003 is an I / O (Input / Output) interface such as a serial port, a USB (Universal Serial Bus) port, a network interface, etc. The interface 1003 realizes the function of the communication unit 103.

[0040] The secondary storage device 1004 is, for example, a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The secondary storage device 1004 stores the operating programs executed by the processor 1001. The secondary storage device 1004 realizes the functions of the project storage unit 100 and the log storage unit 105.

[0041] An example of the operation of generating a test report by the debugging device 10 will be described with reference to Fig. 6. The operation shown in Fig. 6 is executed, for example, when a user operates the debugging device 10 to start debugging. It is also assumed that project data has already been saved in the project storage unit 100 before the operation shown in Fig. 6 is executed.

[0042] The simulation unit 102 of the debugging device 10 generates an operation signal based on an input operation by a user to the input unit 101 and project data stored in the project storage unit 100 (step S1). In this step, an operation signal corresponding to an input operation performed by the user on the debugging device 10 for debugging is generated.

[0043] The simulation unit 102 outputs the operation signal generated in step S1 to the HMI 20 via the communication unit 103 of the debugging device 10, thereby simulating a user operation on the HMI 20 (step S2). In this step, the input operation performed by the user on the debugging device 10 for debugging is simulated by the HMI 20, and the HMI 20 executes an operation corresponding to the operation signal and outputs a log.

[0044] The log acquisition unit 104 of the debugging device 10 acquires the log output by the HMI 20 in response to the operation signal via the communication unit 103 and stores it in the log storage unit 105 (step S3).

[0045] The omission determination unit 108 of the debugging device 10 determines whether there are any omissions in the test items required for debugging based on the log stored in the log memory unit 105 in step S3 and the project data stored in the project memory unit 100 (step S4).

[0046] If it is determined in step S4 that there is a omission (step S5: Yes), the notification unit 109 of the debugging device 10 controls the display unit 110 to notify the user that there is a omission in the input operation (step S6).The debugging device 10 then repeats the operations from step S1 to reflect the new input operation by the user in the debugging.

[0047] If it is determined in step S4 that there is no omission (step S5: No), the notification unit 109 controls the display unit 110 to notify that the debugging has been completed (step S7).

[0048] The report generation unit 106 of the debugging device 10 generates a test report based on the log stored in the log storage unit 105 and the project data stored in the project storage unit 100 (step S8).

[0049] The test report output unit 107 of the debugging device 10 controls the display unit 110 to display the test report generated in step S8 (step S9), and the debugging device 10 then ends the debugging operation.

[0050] The debugging system 1 according to the embodiment has been described above. The debugging device 10 simulates user operations on the HMI 20 by outputting operation signals to the HMI 20 for debugging based on the user's input operations on the debugging device 10 and project data related to the screen design of the HMI 20. The debugging device 10 generates a test report based on the log output by the HMI 20 in response to the operation signals and the project data. Therefore, the debugging system 1 makes it easy to generate a test report when debugging the screen design of the HMI 20.

[0051] Furthermore, the debugging device 10 determines whether or not there are any missing required test items based on the log and project data, and if there are any missing items, notifies the user of the missing input operations. This allows the user to easily recognize any missing input operations during debugging, making it easier to perform additional operations during debugging.

[0052] (Modification) In the debugging system 1 according to the first embodiment, the focus is on only one debugging session, but the debugging system 1 can also be used for subsequent debugging sessions. Furthermore, in subsequent debugging sessions, the test report generated during the previous debugging session can be used as a test plan. This allows the results of the test report from the previous debugging session to be used for parts that have not changed since the previous debugging session, eliminating the need to repeat the same operations during the current debugging session.

[0053] 5, the debugging device 10 includes a secondary storage device 1004. However, the present invention is not limited to this, and the secondary storage device 1004 may be provided outside the debugging device 10, and the debugging device 10 and the secondary storage device 1004 may be connected via an interface 1003. In this configuration, removable media such as a USB flash drive or a memory card may also be used as the secondary storage device 1004.

[0054] 5, the debugging device 10 may be configured by a dedicated circuit using an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), etc. In the hardware configuration shown in FIG. 5, some of the functions of the debugging device 10 may be realized by a dedicated circuit connected to the interface 1003, for example.

[0055] The program used in the debugging device 10 can be stored and distributed on a computer-readable recording medium such as a CD-ROM (Compact Disc Read Only Memory), a DVD (Digital Versatile Disc), a USB flash drive, a memory card, or a HDD. By installing such a program on a specific or general-purpose computer, the computer can function as the debugging device 10.

[0056] Furthermore, the above-mentioned program may be stored in a storage device owned by another server on the Internet, and the program may be downloaded from that server.

[0057] The present disclosure allows various embodiments and modifications without departing from the broad spirit and scope of the present disclosure. Furthermore, the above-described embodiments are intended to explain the present disclosure and do not limit the scope of the present disclosure. In other words, the scope of the present disclosure is defined by the claims, not the embodiments. Various modifications made within the scope of the claims and the meaning of equivalent disclosures are considered to be within the scope of the present disclosure.

[0058] 1 Debugging system, 10 Debugging device, 20 HMI, 100 Project storage unit, 101 Input unit, 102 Simulation unit, 103 Communication unit, 104 Log acquisition unit, 105 Log storage unit, 106 Report generation unit, 107 Report output unit, 108 Leak determination unit, 109 Notification unit, 110 Display unit, 1000 Bus, 1001 Processor, 1002 Memory, 1003 Interface, 1004 Secondary storage device.

Claims

1. A program that causes a computer to function as: a simulation means that outputs operation signals to a programmable display to simulate user operations on the programmable display in order to debug the screen design of the programmable display; and a report generation means that generates a test report of the debugging based on a log output by the programmable display in response to the operation signals.

2. The program described in claim 1, wherein the simulation means generates the operation signal based on the input operation by the user to the computer and project data related to the screen design, and the report generation means generates the test report based on the log and the project data.

3. The program according to claim 2, wherein the project data includes data relating to a plurality of screens, and the test report includes information relating to the comprehensiveness of transitions of the plurality of screens.

4. The program according to claim 2 or 3, wherein the project data includes data relating to a plurality of switches, and the test report includes information relating to the comprehensiveness of pressing the plurality of switches.

5. The program according to any one of claims 2 to 4, wherein the project data includes data relating to numerical input, and the test report includes information relating to the coverage of boundary values ​​in the numerical input.

6. The program according to any one of claims 2 to 5, wherein the project data includes data relating to script statements including conditional branches, and the test report includes information relating to the comprehensiveness of the conditions of the conditional branches.

7. The program according to any one of claims 2 to 6, further causing the computer to function as: an omission determination means for determining whether or not there is a omission in the test items required for the debugging based on the log and the project data; and a notification means for notifying the user that there is a omission in the input operation performed by the user when the omission determination means determines that there is a omission in the required test items.

8. The program according to claim 7, wherein the notification means further notifies the user that the debugging has been completed when the omission determination means determines that there are no omissions in the required test items.

9. A debugging device comprising: a simulation means for outputting an operation signal to a programmable display to simulate a user's operation on the programmable display, in order to debug the screen design of the programmable display; and a report generation means for generating a test report of the debugging based on a log output by the programmable display in response to the operation signal.

10. A debugging system comprising the debugging device according to claim 9 and the programmable display.

11. A debugging method in which a computer outputs operation signals to a programmable display to simulate user operations on the programmable display in order to debug the screen design of the programmable display, and generates a test report of the debugging based on a log output by the programmable display in response to the operation signals.

Images