JP6771413B2 - Software verification device and software verification program - Google Patents

Description

The present invention relates to a software verification device and a software verification program.

Conventionally, in the embedded control software development process, after the actual hardware is completed, the control software implemented in advance is mounted on the completed actual hardware for debugging work, specifically, hardware defect detection and operation. Check or modify the control software. This is because the purpose of embedded software is to control the hardware, and therefore, functional verification such as operation check cannot be performed without the actual hardware to be controlled.

However, in such a development process, it is not possible to check the functions of the control software to be implemented, such as debugging, and a failure related to the actual hardware is discovered in the latter stage of development, resulting in a large rework man-hour. There is a problem that it ends up.

As a solution to such a problem, there is a conventional technique of constructing an environment simulator that simulates actual hardware and verifying the operation of software by using an operation verification processing unit and an environment simulator.

In the technique described in Patent Document 1, when verifying the operation of software, an environment simulator that enables verification of software operation is used when the actual hardware can be used as the device to be verified and when the actual hardware is not available. Assuming a case, a common interface library unit is prepared between the operation verification processing unit and the verification target device. The common interface library section is a library that absorbs the differences between the actual hardware and the environment simulator. In the technique described in Patent Document 1, by using the common interface library unit, changes depending on the difference in the verification target are efficiently performed.

JP-A-2010-157103

In the technique described in Patent Document 1, when the internal configuration of the environment simulator itself is changed, the common interface library part must be changed.

An object of the present invention is to enable a common interface function to be used without change even when a model change occurs in the environment simulator.

The software verification device according to one aspect of the present invention is
Multiple hardware components provided in the hardware on which the software is installed are simulated as individual models, and at the time of simulation, one or more resources holding the values given to each model by the operation of the software are assigned to each model. Environmental simulator department and
By calling a common interface function, an operation verification unit having a plurality of functional units that access a resource named as a parameter of the interface function and verify the operation of the software by an individual method, and an operation verification unit.
The mapping information indicating the correspondence between each model and the resource allocated by the environment simulator unit is acquired and stored in the memory, the name of each resource is notified to the plurality of functional units, and each time the interface function is called. , The model corresponding to the resource whose name is specified as the parameter of the interface function is specified by referring to the mapping information stored in the memory, the specified model is requested to access the resource, and the response to the request is made. Is provided with a monitor unit that receives the above and returns it to the functional unit that calls the interface function.

In the present invention, each time a common interface function for accessing the resource of each model is called from each functional unit, the monitoring unit that mediates the access to the resource refers to the mapping information indicating the correspondence between the model and the resource. Let me. Therefore, even if the model is changed in the environment simulator section, the common interface function can be used without change.

The block diagram which shows the structure of the software verification apparatus which concerns on Embodiment 1. FIG. The figure which shows the mapping example of the resource name and a model which concerns on Embodiment 1. FIG. The flowchart which shows the operation of the software verification apparatus which concerns on Embodiment 1. The figure which shows the calling example of the common interface function which concerns on Embodiment 1. FIG. The block diagram which shows the structure of the software verification apparatus which concerns on Embodiment 2.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. In each figure, the same or corresponding parts are designated by the same reference numerals. In the description of the embodiment, the description will be omitted or simplified as appropriate for the same or corresponding parts. The present invention is not limited to the embodiments described below, and various modifications can be made as needed. For example, among the embodiments described below, two or more embodiments may be combined and implemented. Alternatively, of the embodiments described below, one embodiment or a combination of two or more embodiments may be partially implemented.

Embodiment 1.
The present embodiment will be described with reference to FIGS. 1 to 4.

*** Explanation of configuration ***
The configuration of the software verification device 40 according to the present embodiment will be described with reference to FIGS. 1 and 2.

The software verification device 40 is a computer. The software verification device 40 includes a processor 41 and other hardware such as a memory 42, an input interface 43, and an output interface 44. The processor 41 is connected to other hardware via a signal line and controls these other hardware.

The software verification device 40 includes an operation verification unit 10, a monitor unit 20, and an environment simulator unit 30 as functional elements. The functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30 are realized by software.

The operation verification unit 10 has a plurality of functional units such as a manual test function unit 11, an automatic test function unit 12, a debug function unit 13, and a performance analysis function unit 14.

The environment simulator unit 30 has a plurality of models such as a CPU model 31, a device A model 32, a device B model 33, and a plant model 34. "CPU" is an abbreviation for Central Processing Unit.

From the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, and the performance analysis function unit 14, the CPU model 31, the device A model 32, the device B model 33, and the plant model 34 have each resource. The acquisition and setting of the value is realized by calling the common interface function prepared in the monitor unit 20. Each function unit of the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, and the performance analysis function unit 14 calls a common interface function with the target resource name as a parameter. In the present embodiment, as a common interface function, there are a getValue () function for acquiring a value and a setValue () function for setting a value.

The processor 41 is an IC that performs various processes. "IC" is an abbreviation for Integrated Circuit. The processor 41 is, for example, a CPU.

The mapping information 50 is stored in the memory 42. As will be described later, the mapping information 50 is information indicating the correspondence between each model of the environment simulator unit 30 and the resources allocated by the environment simulator unit 30. The memory 42 is, for example, a flash memory or a RAM. "RAM" is an abbreviation for Random Access Memory.

The input interface 43 is an interface to which an input device (not shown) is connected. The input device is, for example, a mouse, keyboard or touch panel.

The output interface 44 is an interface to which an output device (not shown) is connected. The output device is, for example, a display or a printer.

The software verification device 40 may include a communication device as hardware.

Communication equipment includes a receiver that receives data and a transmitter that transmits data. The communication device is, for example, a communication chip or a NIC. "NIC" is an abbreviation for Network Interface Card.

The memory 42 stores a software verification program that is a program that realizes the functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30. The software verification program is read into the processor 41 and executed by the processor 41. The OS is also stored in the memory 42. "OS" is an abbreviation for Operating System. The processor 41 executes the software verification program while executing the OS. A part or all of the software verification program may be incorporated in the OS.

The software verification program and the OS may be stored in the auxiliary storage device. The auxiliary storage device is, for example, a flash memory or an HDD. "HDD" is an abbreviation for Hard Disk Drive. The software verification program and the OS stored in the auxiliary storage device are loaded into the memory 42 and executed by the processor 41.

The software verification device 40 may include a plurality of processors that replace the processor 41. These multiple processors share the execution of the software verification program. Each processor is an IC that performs various processes in the same manner as the processor 41.

Information, data, signal values and variable values indicating the processing results of the operation verification unit 10, the monitor unit 20 and the environment simulator unit 30 are stored in the memory 42, the auxiliary storage device, or the register or cache memory in the processor 41. To.

The software verification program may be stored on a portable recording medium such as a magnetic disk or an optical disk.

The mapping between the resource name and the model will be described with reference to FIG.

The resource name is defined in the resource name tree. In the present embodiment, among the resources held by the CPU model 31, the resource name of a certain register is "CPU.Register1". Among the resources held by the device A model 32, the resource name of a certain register is "IO. DevA. Register2". Among the resources held by the device B model 33, the resource name of a certain register is “IO.DevB.Register3”. The resource name of the resource held by each model is shown in the resource information held by each model.

The resource information held by each model changes according to the change in the configuration of the simulation target of the environment simulator unit 30. For example, suppose that there is a change in the environment simulator unit 30 so that the device A model 32 and the device B model 33 are configured as one IO model. In this case, in the resource information held by the IO model, the resource names of the two registers "IO.DevA.Register2" and "IO.DevB.Register3" are indicated. "IO" is an abbreviation for Input Output.

When a new register is added to the device A model 32, "IO. DevA. Register4" is newly added to the resource information held by the device A model 32.

In the software verification device 40, the monitor unit 20 has a mechanism for holding the mapping information 50 between the model and the resource notified from the environment simulator unit 30 at the time of initialization. Therefore, it is not necessary to change the monitor unit 20 in response to changes such as configuration changes of the environment simulator unit 30 and addition of resources.

*** Explanation of operation ***
The operation of the software verification device 40 according to the present embodiment will be described with reference to FIGS. 1 to 4. The operation of the software verification device 40 corresponds to the software verification method according to the present embodiment.

In step S1 of FIG. 3, the environment simulator unit 30 starts a process of simulating a plurality of hardware components provided in the hardware on which the software to be verified is installed as individual models. At the time of simulation, the environment simulator unit 30 allocates one or more resources holding values given to each model by the operation of the software to be verified to each model. In the present embodiment, each time the software verification device 40 is initialized, the environment simulator unit 30 generates information indicating the correspondence between the model that started the simulation and the resources allocated to the model as mapping information 50. Provided to the monitor unit 20.

Specifically, at the time of initializing the software verification device 40, each model of the CPU model 31, the device A model 32, the device B model 33, and the plant model 34 in the environment simulator unit 30 is connected to the monitor unit 20. Notifies the combination of the resource information of the model itself and the model name of each model. The CPU model 31 is a model for simulating a CPU provided in hardware equipped with software to be verified. The device A model 32 and the device B model 33 are models for simulating a device such as a controller provided in the hardware, respectively. The plant model 34 is a model for simulating parts such as a motor provided in the hardware.

In step S2 of FIG. 3, the monitor unit 20 acquires the mapping information 50 and stores it in the memory 42. In the present embodiment, the monitor unit 20 acquires the mapping information 50 from the environment simulator unit 30 and stores it in the memory 42 each time the software verification device 40 is initialized.

Specifically, the monitor unit 20 holds the combination of the resource information and the model name notified from each model in step S1 as the mapping information 50.

The monitor unit 20 may acquire the mapping information 50 from the external file and store it in the memory 42 each time the software verification device 40 is initialized.

In step S3 of FIG. 3, the monitor unit 20 extracts the name of each resource from the mapping information 50 stored in the memory 42 and notifies a plurality of functional units of the operation verification unit 10.

Specifically, the monitor unit 20 extracts the resource information of the resource capable of setting or acquiring the value from the mapping information 50 held in step S2, and the manual test function unit 11 in the operation verification unit 10 automatically. Notify the test function unit 12, the debug function unit 13, and the performance analysis function unit 14.

In step S4 of FIG. 3, a plurality of functional units of the operation verification unit 10 call a common interface function. At this time, each functional unit specifies the name of the resource as a parameter of the interface function.

Specifically, as shown in FIG. 4, the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, and the performance analysis function unit 14 have the resource information notified from the monitor unit 20 as parameters. In addition, the getValue () function for acquiring the value is called to the monitor unit 20. Alternatively, the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, and the performance analysis function unit 14 have the resource information notified from the monitor unit 20 as parameters, and set the value to the monitor unit 20. Call the setValue () function to set.

In step S5 of FIG. 3, the monitor unit 20 refers to the mapping information 50 stored in the memory 42 each time the interface function is called, and identifies the model corresponding to the resource whose name is specified as the parameter of the interface function. To do.

Specifically, the monitor unit 20 identifies a model that manages resources corresponding to the resource information notified as a parameter from the mapping information 50 held by the monitor unit 20 itself.

In step S6 of FIG. 3, the monitor unit 20 requests the specified model to access the resource whose name is specified as a parameter of the interface function, and receives a response to the request.

Specifically, as shown in FIG. 4, the monitor unit 20 is used from the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, or the performance analysis function unit 14 with respect to the model specified in step S5. Call the getValue () function to get the value with the notified resource information as a parameter. Alternatively, the monitor unit 20 has the resource information notified from the manual test function unit 11, the automatic test function unit 12, the debug function unit 13, or the performance analysis function unit 14 as parameters for the model specified in step S5. Then call the setValue () function to set the value. The callee model acquires a value or sets a value for the resource corresponding to the resource information notified as a parameter, and notifies the monitor unit 20 of the result.

In step S7 of FIG. 3, the monitor unit 20 returns the received response to the functional unit that calls the interface function. As a result, the functional unit has accessed the resource for which the resource name is specified as the parameter of the interface function, and the operation of the software to be verified can be verified.

Specifically, the monitor unit 20 receives the result notified from the CPU model 31, the device A model 32, the device B model 33, or the plant model 34 in the environment simulator unit 30 in the operation verification unit 10 according to the corresponding functional unit. Notify to.

In the present embodiment, the plurality of functional units of the operation verification unit 10 verify the operation of the software to be verified by an individual method.

Specifically, the manual test function unit 11 tests the software to be verified according to the operation of the user. The automatic test function unit 12 automatically tests the software to be verified. The debug function unit 13 debugs the software to be verified. The performance analysis function unit 14 analyzes the performance of the software to be verified.

*** Explanation of the effect of the embodiment ***
In the present embodiment, each time a common interface function for accessing the resource of each model is called from each functional unit, the monitoring unit 20 that mediates the access to the resource is mapped to indicate the correspondence between the model and the resource. Refer to information 50. Therefore, even when the model is changed in the environment simulator unit 30, the common interface function can be used without change.

It is assumed that the peripheral IO portion is implemented as one model in the environment simulator unit 30. Since the number of devices included in the peripheral IO model implemented in the environment simulator unit 30 has increased, it may be necessary to divide the peripheral IO model into models for the number of devices. Even in such a case, in the present embodiment, the operation verification unit 10 can access various resources managed by each model in the environment simulator unit 30 by using a common interface function. That is, it is not necessary to modify the interface of the operation verification unit 10 each time there is a change in the environment simulator unit 30 as described above.

In the present embodiment, the interface function is not prepared for each model but is shared, so that the operation verification unit 10 is based on the mapping between the uniquely determined model and the resource information held by the model. In addition, it is possible to access necessary resources by using a common interface function. Specifically, when each function unit of the operation verification unit 10 calls the getValue () function or the setValue () function, the resource can be accessed by specifying the resource name to be accessed with a parameter.

In the present embodiment, it is possible to cope with the change of mapping. As a specific example, in the environment simulator unit 30, when the model called the IO model is changed to two models, the device A model 32 and the device B model 33, the mapping between each model and the resources managed by the model is also changed. can do.

In the present embodiment, the environment simulator unit 30 simulates the actual hardware on which the control software is installed. The operation verification unit 10 verifies the control software that operates in the environment simulator unit 30. The monitor unit 20 combines the interface functions for accessing the environment simulator unit 30 from each function unit of the operation verification unit 10 into one as a common interface function, and each model of the environment simulator unit 30 and the resources included in each model. The mapping information 50 with and is managed. Even if the resource information managed by each model of the environment simulator unit 30 or each model itself is changed, it is not necessary to add or delete the interface function of the monitor unit 20, and the parameters of the interface function of the monitor unit 20 are not required. By changing only the target resource name specified in, the operation verification unit 10 can access the resources held by each model of the environment simulator unit 30. The mapping information 50 is dynamically registered at the time of initialization.

As described above, in the present embodiment, the operation verification unit 10 and the monitor unit having a common interface for accessing the resources held by each model in the environment simulator unit 30 are connected to each model at the time of initialization. The mapping information 50 with the resource held by each model is registered. As a result, even if the configuration of the model or resource in the environment simulator unit 30 is changed, it is not necessary to change the common interface, and the operation verification unit 10 needs to be aware of the configuration change of the environment simulator unit 30. Is gone. Therefore, it is possible to obtain the effect of increasing the design flexibility for changing the configuration of the environment simulator unit 30.

*** Other configurations ***
In the present embodiment, the functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30 are realized by software, but as a modification, the functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30 are software. It may be realized by a combination of and hardware. That is, a part of the functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30 may be realized by a dedicated electronic circuit, and the rest may be realized by software.

Dedicated electronic circuits are, for example, single circuits, composite circuits, programmed processors, parallel programmed processors, logic ICs, GAs, FPGAs or ASICs. "GA" is an abbreviation for Gate Array. "FPGA" is an abbreviation for Field-Programmable Gate Array. "ASIC" is an abbreviation for Application Specific Integrated Circuit.

The processor 41, the memory 42, and the dedicated electronic circuit are collectively referred to as a "processing circuit". That is, regardless of whether the functions of the operation verification unit 10, the monitor unit 20, and the environment simulator unit 30 are realized by software or a combination of software and hardware, the operation verification unit 10, monitor unit 20, and The function of the environment simulator unit 30 is realized by the processing circuit.

Embodiment 2.
The difference between the present embodiment and the first embodiment will be mainly described with reference to FIG.

As shown in FIG. 5, in the present embodiment, each model of the environment simulator unit 30 is implemented as a dynamic link library and linked to the monitor unit 20 as a plug-in 52.

Specifically, a program that realizes the functions of the operation verification unit 10 and the monitor unit 20 is configured as one executable file 51, and the CPU model 31, device A model 32, device B model 33 unit, and plant model 34 are each configured. Individual. It is configured as a dll file.

CPU model 31, device A model 32, device B model 33, and plant model 34. The dll file is stored in a specific folder, and the executable file 51 is stored in that folder. If the dll files are dynamically linked, it is not necessary to rebuild the executable file 51 side even when the configuration of the environment simulator unit 30 is changed or changes such as the addition of resources are made.

10 Operation verification unit, 11 Manual test function unit, 12 Automatic test function unit, 13 Debug function unit, 14 Performance analysis function unit, 20 Monitor unit, 30 Environment simulator unit, 31 CPU model, 32 Device A model, 33 Device B model , 34 plant model, 40 software verification device, 41 processor, 42 memory, 43 input interface, 44 output interface, 50 mapping information, 51 executable file, 52 plug-in.

Claims (6)

Multiple hardware components provided in the hardware on which the software is installed are simulated as individual models, and at the time of simulation, one or more resources holding the values given to each model by the operation of the software are assigned to each model. Environmental simulator department and
By calling a common interface function, an operation verification unit having a plurality of functional units that access a resource named as a parameter of the interface function and verify the operation of the software by an individual method, and an operation verification unit.
The mapping information indicating the correspondence between each model and the resource allocated by the environment simulator unit is acquired and stored in the memory, the name of each resource is notified to the plurality of functional units, and each time the interface function is called. , The model corresponding to the resource whose name is specified as the parameter of the interface function is specified by referring to the mapping information stored in the memory, the specified model is requested to access the resource, and the response to the request is made. A software verification device including a monitor unit that receives a signal and returns it to the functional unit that calls the interface function. The software verification device according to claim 1, wherein each model is implemented as a dynamic link library and linked to the monitor unit as a plug-in. The software verification device according to claim 1 or 2, wherein the monitor unit acquires the mapping information from the environment simulator unit each time the software verification device is initialized. Each time the software verification device is initialized, the environment simulator unit generates information indicating the correspondence between the model that started the simulation and the resources allocated to the model as the mapping information, and provides it to the monitor unit. The software verification device according to claim 3. The software verification device according to claim 1 or 2, wherein the monitor unit acquires the mapping information from an external file each time the software verification device is initialized. On the computer
Multiple hardware components provided in the hardware on which the software is installed are simulated as individual models, and at the time of simulation, one or more resources holding the values given to each model by the operation of the software are assigned to each model. Environmental simulator and
By calling a common interface function, a process having a plurality of functional parts that access a resource whose name is specified as a parameter of the interface function and verify the operation of the software by an individual method, and
The mapping information indicating the correspondence between each model and the resource allocated by the environment simulator is acquired and stored in the memory, the name of each resource is notified to the plurality of functional units, and each time the interface function is called. By referring to the mapping information stored in the memory, the model corresponding to the resource whose name is specified as the parameter of the interface function is specified, the specified model is requested to access the resource, and the response to the request is made. A software verification program that executes processing that receives and returns to the functional unit that calls the interface function.

Images