WO2014199496A1 - Program verification device, program verification method, and program - Google Patents

Abstract

A verification scenario creation unit (102) analyzes an implementation code which is a program to be verified, and designates, as interruption points, a plurality of timings at which there is a possibility that interruption may occur when the implementation code is executed. An implementation code execution unit (1011) executes the implementation code. An interruption simulation unit (105) does not cause interruption at the interruption point if a setting has been made to prohibit interruption at said interruption point at the time of executing the implementation code, and causes interruption at the interruption point if a setting has been made to permit interruption at said interruption point. A verification item analysis unit (104) analyzes the result of executing the implementation code and determines whether or not a setting to prohibit interruption was made properly at timings, among said plurality of interruption points, at which interruption is to be prohibited.

Description

Program verification apparatus, program verification method, and program

The present invention relates to a technique for verifying a program (hereinafter also referred to as software).

Control S / W, which is a kind of embedded software (hereinafter also referred to as S / W), is rapidly increasing in scale and complexity in order to meet the demand for multi-function and high added value.
Moreover, functional safety standards for functionally ensuring the safety of products have been formulated in various fields due to the increasing safety orientation of users.
As an example, a functional safety standard ISO26262 for automobiles was formulated in November 2011, and in product development, it is required to comply with a standard that does not involve an increase in cost.

In ISO 26262, the development process and work items for achieving safety in order to cope with an increase in the risk of not only random failure of hardware (hereinafter also referred to as H / W) but also of S / W system failure, Specifies work item deliverables and recommended techniques.

In order to develop products while conforming to ISO 26262, work items and recommended techniques that are necessary and sufficient to realize safety requirements are selected and products are created, and various tools that have obtained ISO 26262 certification are used. Therefore, it is necessary from the viewpoint of quality and cost to verify the validity of the deliverables.

Also, in recent control S / W development projects, the number and types of I / O (Input / Output) devices to be controlled by the control S / W in order to meet the demand for higher functionality and higher added value. Has increased.
Due to the increase in the number and types of I / O devices, it is difficult to perform a test that covers all the processing order and execution timing.
For this reason, during actual machine operation after the S / W coupling test (when the control S / W is mounted on a control device and executed), the control S / W is executed under special conditions not assumed in the test. A problem with the H / W-S / W interface is a problem.

In the H / WS / W interface verification that is performed in the unit test of the control S / W, all conditions that occur rarely during actual machine operation after the test are assumed, and tests that correspond to all conditions must be performed without exception. Is required.
Specifically, it is required to realize the following requirements.
(1) In order to guarantee the verification result, the implementation code that is the program to be verified should not be modified as much as possible.
(2) It should be possible to verify all variations of processing by parallel operation of H / W and S / W.
(3) It must be possible to simulate the finite time operation of the implementation code.
In general, it is difficult to imagine a situation in which the operation is continued for an infinite time without stopping the device, so that it is possible to simulate a finite time operation.

As a conventional software parallel operation verification technique for H / W-S / W interface verification, a method for simulating the operation of an I / O device (for example, Patent Document 1) and an implementation code analysis by model checking (for example, non-patent) Document 1) is often used.

In the method of simulating the operation of the I / O device (for example, Patent Document 1), it is possible to simulate the finite time operation of the I / O device calculation and interrupt processing according to the operation condition of the I / O device set manually. Is possible.
In addition, in the implementation code analysis by model checking (for example, Non-Patent Document 1), the implementation code can be verified without any variation in parallel operation in a finite time by converting the implementation code into a dedicated description of SMT (Satfiability Modulo Theories) format. .

JP 2007-233675 A

The conventional software parallel operation verification technology has the following problems.

In the method of simulating the operation of the I / O device, it is possible to verify the finite time operation without modifying the mounting code (requirements (1) and (3) can be achieved).
However, when the tester manually sets the verification conditions, the tester can only perform tests within the conditions assumed by the tester, and can verify all the variations of the process due to the parallel operation of H / W and S / W. There is no limit (Requirement (2) cannot be achieved).

In the implementation code analysis by model checking, it is possible to verify processing variations due to parallel operations of H / W and S / W (requirements (2) and (3) can be achieved).
However, it is difficult to guarantee that the implementation code matches the dedicated description, and additional man-hours are generated to guarantee the consistency between the implementation code and the dedicated description (Requirement (1)). Cannot be achieved).

The present invention has been made in view of the above circumstances, and has as its main object to verify a verification target program under conditions that occur during actual machine operation without correcting the verification target program.

The program verification apparatus according to the present invention includes:
A program verification device for verifying a verification target program including an interrupt setting process for performing settings related to an interrupt,
Interrupt candidate timing that analyzes the verification target program and designates a plurality of timings at which an interrupt may occur when the verification target program is executed by a device that executes the verification target program as interrupt candidate timings, respectively A designated part;
A program execution unit for executing the verification target program;
When the program execution unit executes the verification target program, if the interrupt setting process is set to prohibit interrupt at the interrupt candidate timing, the interrupt setting process does not generate an interrupt at the interrupt candidate timing. If the setting for permitting an interrupt at the interrupt candidate timing is performed by the interrupt generation unit that generates an interrupt at the interrupt candidate timing,
Among the plurality of interrupt candidate timings, an interrupt candidate timing that is assumed to be appropriate to prohibit interrupts is selected as an interrupt prohibition assumption timing, the execution result of the verification target program is analyzed, and the interrupt prohibition assumption timing is selected. And a verification unit for determining whether or not the setting for prohibiting the interrupt has been performed by the interrupt setting process.

In the present invention, the verification target program is analyzed, the interrupt candidate timing at which an interrupt may occur when the verification target program is executed on the device is specified, and the interrupt is set according to the interrupt setting processing setting at the interrupt candidate timing. Adjust the occurrence.
Therefore, for the interrupt control, the verification target program can be verified under the same conditions as when the actual machine is operating.

FIG. 3 is a diagram illustrating a configuration example of a simulator device according to the first embodiment. The figure which shows the relationship between the simulator apparatus which concerns on Embodiment 1, an installation code, and an I / O device simulation program. FIG. 3 is a diagram showing an S / W architecture of an implementation code according to the first embodiment. FIG. 4 is a flowchart showing an operation example of the simulator device according to the first embodiment. FIG. 6 shows an example of a verification scenario generation procedure according to the first embodiment. FIG. 4 is a diagram illustrating an example of interrupt points according to the first embodiment. FIG. 4 shows an example of input sequence information according to the first embodiment. FIG. 4 is a diagram illustrating an example of interrupt point information according to the first embodiment. FIG. 6 is a diagram illustrating an example of scheduler setting according to the first embodiment. FIG. 4 is a diagram showing an example of I / O device state information (interrupt) according to the first embodiment. FIG. 4 is a diagram showing an example of I / O device state information (timer) according to the first embodiment. FIG. 6 is a diagram illustrating an example of control operation count information (cooperation operation) according to the first embodiment. FIG. 6 is a diagram showing an example of control operation count information (I / O operation) according to the first embodiment. FIG. 6 is a diagram showing an example of control operation count information (interrupt operation) according to the first embodiment. FIG. 5 is a diagram showing an example of control operation count information (timer operation) according to the first embodiment. FIG. 3 is a diagram showing an example of a control signal access log according to the first embodiment. FIG. 10 is a diagram illustrating an example of scheduler setting according to the second embodiment. FIG. 10 is a diagram illustrating an example of control operation count information (interrupt operation) according to the third embodiment. FIG. 4 is a diagram illustrating an example of control operation information according to the first embodiment. FIG. 4 is a diagram illustrating a hardware configuration example of a simulator device according to the first to third embodiments.

Embodiment 1 FIG.
In the present embodiment, a simulator device that verifies processing variations by parallel operation of H / W and S / W without modifying the implementation code as the verification target program as much as possible will be described.
More specifically, in the present embodiment, a simulator device that verifies a mounting code using an I / O device simulation program that simulates the operation of an I / O device in a unit test will be described.
The simulator device according to the present embodiment makes it possible to reduce the number of reworking steps after the S / W coupling test.

FIG. 2 shows the relationship between the simulator apparatus 100 according to the present embodiment, the implementation code 500 to be verified, and the I / O device simulation program 600 that simulates an I / O device.
The simulator device 100 corresponds to an example of a program verification device.

The implementation code 500 is a program in which an operation algorithm of the control device 200 is described.
The mounting code 500 is mounted on the control device 200 and executed by the control device 200 after a test including verification using the simulator device 100.
The mounting code 500 is a program to be verified by the simulator device 100, and corresponds to an example of the verification target program.

As shown in FIG. 2, the control device 200 controls the sensor device 300 and the drive device 400 that are control targets.
The control device 200 includes an I / O port 204, an I / O port 205, an interrupt 206, and a timer 207 as hardware.
Although not shown in FIG. 2, the control device 200 is equipped with a CPU (Central Processing Unit), hardware such as a microcomputer, and memory.
The control device 200 is connected to a control target such as the sensor device 300 or the drive device 400 via I / O ports 204 and 205 for transmitting and receiving digital signals or analog signals, and via the I / O ports 204 and 205. Thus, the sensor device 300 and the driving device 400 are controlled.
As shown in FIG. 2, the I / O device simulation program 600 is a program that simulates the sensor device 300, the drive device 400, the I / O port 204, the I / O port 205, the interrupt 206, and the timer 207.
The simulator apparatus 100 executes the mounting code 500 and the I / O device simulation program 600 to simulate the operation of the control device 200.

The S / W included in the mounting code 500 includes a control process A201, a control process B202, and a hardware driver 203.
The control process A201 and the control process B202 realize a control logic for applying physical control to the control target.
The hardware driver 203 is a program that mediates between the control process A 201 and the control process B 202 and the H / W (I / O port 204, I / O port 205, interrupt 206, timer 207).
In the hardware driver 203, the I / O process 2031 mediates register access to the I / O ports 204 and 205 of the control process A 201 and the control process B 202.
The interrupt process 2032 functions as a handler for occurrence of an interrupt from the H / W.
The timer process 2033 functions as a handler for occurrence of timeout from the H / W.

Note that the configuration of the control device 200 and the device connected to the control device 200 shown in FIG. 2 are examples, and the scope of application of the present embodiment is not limited to the example of FIG.

The simulator apparatus 100 executes the mounting code 500 together with the I / O device simulation program 600 to verify the mounting code 500.
The simulator device 100 includes a scheduler 101, a verification scenario creation unit 102, a control monitoring unit 103, a verification item analysis unit 104, an interrupt simulation unit 105, and a timer simulation unit 106.
Details of each element will be described later with reference to FIG.

The simulator device 100 mainly performs verification for interrupts and verification for the number of event occurrences.
The following outlines the verification of interrupts and the number of event occurrences.
In the following, for the sake of convenience of explanation, the verification for the interrupt and the verification for the event occurrence count will be described separately. However, the simulator apparatus 100 performs the verification for the interrupt and the verification for the event occurrence count in parallel. Can do.

When the implementation code 500 is executed, each control process or each process in the hardware driver is exclusively (interrupted) to a plurality of variables (a cooperation signal 251, an I / O port signal 252, a state variable 253, and a counter variable 254 described later). There is an aspect that should be accessed continuously (without intervening).
In such an aspect, the control process or each process in the hardware driver needs to prohibit the interrupt and access the plurality of variables.
In the verification of the interrupt, the simulator device 100 verifies whether or not the control process A201 appropriately prohibits the interrupt at a timing when it is assumed that prohibiting such an interrupt is appropriate (referred to as an interrupt prohibition expected timing). To do.

As described above, the control process and each process in the hardware driver are processes for accessing a variable, and correspond to an example of a variable access process.
In addition, the control process and each process in the hardware driver are configured to permit interrupts (hereinafter also referred to as permission settings) and to prohibit interrupts (hereinafter also referred to as prohibition settings). It corresponds to an example.

In the following, an example of verifying whether the control process A201 appropriately controls the interrupt will be described. However, it is verified whether the control process B202 and each process in the hardware driver appropriately control the interrupt. Follow the same procedure.

In the simulator device 100, first, the verification scenario creation unit 102 analyzes the mounting code 500.
The verification scenario creation unit 102 designates a plurality of timings (referred to as interrupt candidate timings or interrupt points) at which an interrupt may occur when the mounting code 500 is mounted on the control device 200 and executed by the control device 200. .
Next, the scheduler 101 executes the implementation code 500 for verification.
Each time the interrupt candidate timing arrives during the execution of the implementation code 500, the interrupt simulation unit 105 investigates whether the control process A201 is performing permission setting or prohibition setting.
The interrupt simulation unit 105 generates an interrupt if permission is set at the interrupt candidate timing.
On the other hand, if the prohibition setting is performed at the interrupt candidate timing, the interrupt simulation unit 105 does not generate an interrupt.
When the execution of the implementation code 500 is completed, the verification item analysis unit 104 determines, from among a plurality of interrupt candidate timings, an interrupt candidate timing that is expected to be appropriate to prohibit an interrupt (the user determines whether the prohibition setting by the control process is appropriate). Interrupt candidate timing that is considered desirable to be received) is selected as the interrupt prohibition assumption timing, and based on the execution result of the implementation code 500, whether or not the control process A201 appropriately prohibits the interrupt at the interrupt prohibition assumption timing is determined. Validate.

In the verification of the number of event occurrences, the simulator device 100 verifies whether the number of occurrences of two or more related events is appropriate.

The simulator device 100 stores two or more related events among a plurality of events generated by the execution of the implementation code 500 as related events and stores them in association with each other.
The related event is two or more events having a causal relationship such as a request event and a response event.
Further, the simulator device 100 stores the relationship of the number of occurrences between related events when the mounting code 500 is appropriate.
For example, it is assumed that the simulator device 100 stores event A and event B in association with each other as related events.
In this case, the simulator device 100 stores, for example, a relationship that the number of occurrences of the event A is equal to the number of occurrences of the event B as the relationship of the number of occurrences of related events.

The scheduler 101 executes the implementation code 500, and the control monitoring unit 103 counts the number of occurrences of events that occur due to the execution of the implementation code 500.
Then, after the execution of the mounting code 500 is completed, the verification item analysis unit 104 verifies whether or not the number of occurrences of the related event is appropriate.
In the above example, the control monitoring unit 103 counts the number of occurrences of the event A and the number of occurrences of the event B, and the verification item analysis unit 104 determines whether the counted number of occurrences of the event A is equal to the number of occurrences of the event B. Verify whether or not.

FIG. 3 shows the S / W architecture of the implementation code 500.
The scheduler 101 periodically activates each process in the control process A 201, the control process B 202, and the hardware driver 203.
Data is transmitted and received between these processes via a shared variable called a control signal, and a control operation is executed.
Note that the relationship between the processing and the signal shown in FIG. 3 is an exemplification, and the application range of the present embodiment is not limited to the example of FIG.
The control operation and the control signal will be described below.

The control operation includes a cooperative operation between control processes, an I / O operation performed on the hardware driver from the control process, an interrupt operation, and a timer operation.
The cooperative operation includes a request operation in which a certain control process (for example, control process A201) requests a predetermined calculation from another control process (for example, control process B202), and a control process in which the calculation is requested (for example, control process B202). A response operation of responding to the calculation result is included in the control process (for example, control process A201) of the request source.
The I / O operation includes an operation in which the control process reads data from the I / O device and an operation in which the control process writes data to the I / O device.
The interrupt operation includes an operation in which the control process sets interrupt permission and an operation in which the control process sets interrupt prohibition.
The timer operation includes an operation in which the control process notifies the timer start, an operation in which the control process notifies the timer end, and an operation in which the control process receives a timeout notification.

The control signal includes a cooperation signal 251 transmitted / received between the control processes and an I / O signal transmitted / received between the control process and the hardware driver.
The I / O signal includes an I / O port signal 252 for information transmission between the control processing and the I / O processing 2031, a state variable 253 for information transmission between the control processing and the interrupt processing 2032, A counter signal 254 for information transmission between the control process and the timer process 2033 is included.
Note that a signal not shown in FIG. 3 may be added as the I / O signal.

For example, the simulator device 100 manages a request operation and a response operation in a cooperative operation as related events.
The simulator device 100 also manages, for example, an I / O read operation and an I / O write operation in an I / O operation as related events.
The simulator device 100 also manages, for example, an interrupt permission setting operation and an interrupt prohibition setting operation in an interrupt operation as related events.
Furthermore, the simulator device 100 manages, for example, an operation for notifying a timer start in a timer operation, an operation for receiving a timer end notification, and an operation for receiving a timeout notification as related events.

The hardware driver 203 controls the I / O processing 2031, the interrupt processing 2032, and the timer processing 2033 in order to process I / O port register access, H / W interrupt generation, and H / W timeout generation. Operates in parallel with processing.

The scheduler 101 manages execution of control processing A 201, control processing B 202, I / O processing 2031, interrupt processing 2032, and timer processing 2033.
For example, if the execution priority of the hardware driver 203 is higher than that of the control process, the scheduler 101 interrupts the execution of the control process and starts the execution of the hardware driver 203, and after the execution of the hardware driver 203 ends. Resume execution of control processing.
The control process and the hardware driver 203 change the contents of each process based on the value of the control signal.

Next, the configuration of the simulator device 100 according to the present embodiment will be described with reference to FIG.

The verification scenario creation unit 102 reads the implementation code 500 from the program storage unit 108, reads the cooperation variable from the cooperation variable storage unit 107, analyzes the implementation code 500 and the cooperation variable, and creates a verification scenario.
The verification scenario includes input sequence information and interrupt point information.
The input sequence information is information indicating a transition of an input value input to the mounting code 500.
The input sequence information is, for example, information shown in FIG.
The interrupt point information is information indicating an interrupt point.
The interrupt point information is, for example, information shown in FIG.
Details of the input sequence information and the interrupt point information will be described later.
The verification scenario generated by the verification scenario creation unit 102 is stored in the verification scenario storage unit 110.
The verification scenario creation unit 102 corresponds to an example of an interrupt candidate timing designation unit.

The implementation code execution unit 1011 reads the implementation code 500 from the program storage unit 108, reads the scheduler setting from the scheduler setting storage unit 109, and executes the implementation code 500 according to the scheduler setting.
The scheduler setting is information indicating the activation code and the activation sequence of the implementation code 500 and the I / O device simulation program 600.
The scheduler setting is, for example, information shown in FIG.
Details of the scheduler setting will be described later.
The implementation code execution unit 1011 corresponds to an example of a program execution unit.

The I / O device simulation program execution unit 1012 reads the I / O device simulation program 600 from the program storage unit 108, reads the verification scenario from the verification scenario storage unit 110, and reads the scheduler setting from the scheduler setting storage unit 109.
Then, the I / O device simulation program execution unit 1012 executes the I / O device simulation program 600 according to the verification scenario and the scheduler setting.
The I / O device simulation program execution unit 1012 also uses the timer notification from the timer simulation unit 106 when executing the I / O device simulation program 600.
Also, the I / O device simulation program execution unit 1012 simulates the interrupt 206 based on the H / W interrupt from the interrupt simulation unit 105 and requests an interrupt to the interrupt processing 2032 in the hardware driver 203.
The I / O device simulation program execution unit 1012 corresponds to an example of a program execution unit, and also corresponds to an example of an interrupt generation unit.

The implementation code execution unit 1011 and the I / O device simulation program execution unit 1012 are details of the scheduler 101 shown in FIG.

The interrupt simulation unit 105 reads the verification scenario from the verification scenario storage unit 110 and reads I / O device state information (interrupt) from the I / O device state storage unit 111.
The interrupt simulation unit 105 simulates the operation of the H / W interrupt according to the verification scenario and the I / O device status information (interrupt).
The I / O device status information (interrupt) indicates whether interrupt is permitted or interrupt is prohibited.
The I / O device status information (interrupt) is information shown in FIG. 10, for example.
The interrupt simulation unit 105 refers to the I / O device status information (interrupt) when the interrupt point indicated in the verification scenario arrives, and if the interrupt is permitted, the interrupt simulation unit 105 sends the H / W interrupt to the I / O device. The simulation program execution unit 1012 is notified.
Details of the I / O device status information (interrupt) will be described later.
The interrupt simulation unit 105 corresponds to an example of an interrupt generation unit.

The timer simulation unit 106 reads I / O device state information (timer) from the I / O device state storage unit 111 and simulates the operation of the H / W timer according to the I / O device state information (timer).
The I / O device status information (timer) shows details of timer setting.
The I / O device status information (timer) is information shown in FIG.
Details of the I / O device status information (timer) will be described later.

The control monitoring unit 103 reads the control operation information from the control operation information storage unit 115, and counts the number of control operations, which is the number of event occurrences, according to the control operation information during the execution of the mounting code 500.
Further, the control monitoring unit 103 monitors the access status to the control signal (variable) by the control process A 201 or the like during the execution of the mounting code 500.
Furthermore, the control monitoring unit 103 records the number of control operations in the control operation number storage unit 112 and records the variable access status in the control signal access log storage unit 113 as a control signal access log.
The number of control operations is recorded in the control operation number storage unit 112, for example, in the format shown in FIGS.
The control signal access log is information shown in FIG. 16, for example.
In the control operation information, a related operation that is a related event is shown, and a condition about the relationship of the number of occurrences between related operations is shown.
The control operation information is, for example, information shown in FIG.

FIG. 19 shows a related operation in the cooperative operation between the control process A201 and the control process B202.
In the example of FIG. 19, a cooperative operation X and a cooperative operation Y with different types of computation are shown.
In the cooperative operation X, the request operation from the control process A201 and the response operation from the control process B202 are defined as related operations. In the cooperative operation Y, the request operation from the control process B202 and the response operation from the control process A201 are related operations. Is defined as
In the example of FIG. 19, the relational condition is “± 0”, and the condition is that the number of occurrences of the requested operation is equal to the number of occurrences of the response operation.
The relationship condition defines the relationship of the number of occurrences between related operations when the mounting code 500 is appropriate. In the example of FIG. 19, when the mounting code 500 is appropriate, the number of occurrences of the requested operation and the response operation It is defined that the number of occurrences is equal.
Although not shown in FIG. 19, the same contents as in FIG. 19 are defined in the control operation information for the I / O operation, the interrupt operation, and the timer operation.
In the example of FIG. 19, the condition is that the number of occurrences of the requested operation is equal to the number of occurrences of the response operation, but other conditions may be defined.
For example, a condition that the mounting code 500 determines that it is appropriate if [number of requested operations] ≧ [number of response operations] may be defined.
The control monitoring unit 103 corresponds to an example of a counting unit.
The control operation information corresponds to an example of related event information.
The control operation information storage unit 115 corresponds to an example of a related event information storage unit.

The verification item analysis unit 104 reads the number of control operations from the control operation number storage unit 112, and verifies whether the number of control operations matches the relation condition indicated in the control operation information.
Further, the verification item analysis unit 104 reads the control signal access log from the control signal access log storage unit 113.
Then, the verification item analysis unit 104 analyzes the access status to the control signal (variable) by the control process A201 and the like, and verifies whether or not the interrupt is appropriately prohibited at the interrupt prohibition assumed timing.
The verification item analysis unit 104 creates a verification report indicating the verification result, and stores the created verification report in the verification report storage unit 114.
The verification item analysis unit 104 corresponds to an example of a verification unit.

Next, an operation example of the simulator device 100 according to the present embodiment will be described using the flowchart of FIG.
The input of the flowchart of FIG. 4 is information for identifying the mounting code 500 and the linkage variable.
The output of the flowchart of FIG. 4 is a verification report that is a result of verification of the execution result of the mounting code 500 by the verification item analysis unit 104.

In order to simulate the operation of the I / O devices such as the sensor device 300 and the driving device 400, the I / O device simulation program 600 needs to be executed in a short cycle different from the mounting code 500.
Hereinafter, each step of the flowchart of FIG. 4 will be described in order, but each step is not executed in the description order.
Each step from the execution of the mounting code 500 (S102) to the execution of the interrupt process (S106) is sequentially executed, and each step from the execution of the I / O device simulation program 600 (S107) to the execution of the timer process (S109) is performed. These two flows are executed in parallel.

First, the verification scenario creation unit 102 analyzes the mounting code 500 and the linkage variable, and creates a verification scenario (S101).
As described above, the verification scenario includes input sequence information and interrupt point information.
The input sequence information is information in which input values to be given to the mounting code 500 via the hardware driver 203 are arranged in time series.
The interrupt point information is information for designating a timing (interrupt point) for simulating the occurrence of an interrupt at H / W.

As shown in FIG. 5, the verification scenario creation unit 102 inputs, for example, an existing method based on an input product for creating an implementation code 500 such as a customer specification, a control specification, and a function specification. Create sequence information.
Alternatively, the verification scenario creation unit 102 uses, for example, an existing method for input sequence information based on the coverage standard of the implementation code 500 (for example, C0, C1, C2, MC / DC (Modified Condition / Decision Coverage)). You may create it.
Or you may create combining these two methods.

In creating the interrupt point information, the verification scenario creating unit 102 accesses the same control signal (variable) in a plurality of processes (multiple control processes, control processes and processes in the hardware driver) in the implementation code 500. A control signal (variable) accessed by a plurality of processes is extracted as a competition control signal (competition variable).
Then, the verification scenario creation unit 102 designates before and after access to the contention control signal as interrupt points.
FIG. 6 illustrates contention control signals and interrupt points.
In FIG. 6, the control process A 201 and the interrupt process 2032 access the state variables 1 to 3, and the timer process 2033 accesses the state variable 3.
As described above, the state variables 1 to 3 are accessed by a plurality of processes, and the verification scenario creating unit 102 extracts the state variables 1 to 3 as the competition control signal.
Then, the verification scenario creation unit 102 designates the timing before and after the access to each state variable as an interrupt point.
In the example of FIG. 6, the verification scenario creation unit 102 designates four timings as interrupt points.

FIG. 7 shows an example of input sequence information.
In the example of FIG. 7, the input variables of the implementation code 500 are i and j, and the values assigned to the input variables i and j are shown in time series.
Each row in FIG. 7 shows a pattern of input values in one test.
In the present embodiment, since the simulator device 100 simulates a finite time operation, the maximum number of steps is specified in the input sequence information.
The maximum number of steps is the maximum value of the number of activations, that is, the number of activations for determining the operation end point.
FIG. 8 shows an example of the interrupt point information.
FIG. 8 shows interrupt point information corresponding to the example of FIG.
As described above, the timing before and after the access to the state variables 1 to 3 is an interrupt point.
The simulator device 100 performs the test for the number of rows in FIG.
That is, if the input sequence information is composed of n rows, the interrupt simulation unit 105 repeats the execution of the implementation code 500 n times using the input value pattern of each row of the input sequence information.
Then, the interrupt simulation unit 105 generates an H / W interrupt if the interrupt is not prohibited at the interrupt point shown in FIG.

The description returns to the flowchart of FIG.
When the verification scenario is generated, the control process and the I / O device simulation program 600 in the implementation code 500 are executed in accordance with the start cycle and start order specified in the scheduler settings (S102, S107).

In the execution of the I / O device simulation program 600 (S107), the I / O device simulation program execution unit 1012 reads the input value of the corresponding step from the input sequence information of the verification scenario and sets it as the input variable of the implementation code 500. To do.
The scheduler settings are shown in FIG.

FIG. 9 shows scheduler settings when two types of I / O device simulation programs 600 are executed in the simulator apparatus 100, two types of I / O processing 2031 are executed, and two types of control processing are executed. Yes.
The activation order represents an execution priority when there are a plurality of processes having the same activation cycle.
The process with the activation order “1” is executed with priority.

In the execution of the mounting code 500 (S102), the mounting code execution unit 1011 reads the input value, reads / writes each control signal, and executes the control operation in accordance with the control logic described in the mounting code 500. Write the output value that is the result of the operation to the output variable.
During execution of the mounting code 500, permission of interrupt or prohibition of interrupt is set by the control process.
Specifically, permission of interrupt or prohibition of interrupt is set in the I / O device status information (interrupt) in the I / O device status storage unit 111.

FIG. 10 shows an example of I / O device status information (interrupt).
FIG. 10 shows I / O device state information (interrupt) when two interrupts 206 of X and Y are arranged.
Further, when timer start or timer end occurs in the control process, information for timer management is described in I / O device status information (timer) in the I / O device status storage unit 111.
FIG. 11 shows an example of I / O device status information (timer).
FIG. 11 shows I / O device state information (timer) when two timers 207 of X and Y are arranged.
In the I / O device status information (timer), the timer type is one-shot (the timer is automatically terminated when it times out once) or continues (timeout occurs repeatedly until the timer is terminated), or the timer status is started or End is set.
In the I / O device status information (timer), a timer value and a counter are also set.

The description returns to the flowchart of FIG.
The control monitoring unit 103 monitors the control operation and control signal access during the execution of the implementation code 500 (S102) (S103).
When the control monitoring unit 103 detects a control operation, the control monitoring unit 103 increments the number of control operations of the corresponding control operation (S104).
If the control monitoring unit 103 detects a control signal access, the control monitoring unit 103 adds the control signal name, the access type, and the access value to the control signal access log in order of time (S105).

12 to 15 show the control operation frequency information.
FIG. 12 is control operation number information (cooperation operation) indicating the number of control operations in the cooperation operation.
FIG. 13 is control operation number information (I / O operation) indicating the number of control operations in the I / O operation.
FIG. 14 is control operation count information (interrupt operation) indicating the number of control operations in the interrupt operation.
FIG. 15 is control operation number information (timer operation) indicating the number of control operations in the timer operation.
In the control operation count information (cooperation operation) and the control operation count information (I / O operation), two control operations whose “relationship condition” is “YES” are related operations.
That is, two control operations whose “relationship condition” is “YES” are defined as related operations in the control operation information of FIG.
Further, in the control operation count information (interrupt operation) and the control operation count information (timer operation), a pair of control operations described in the same line is a related operation.

FIG. 16 shows a control signal access log.
In the control signal access log, “process name”, “control signal name”, “access type”, and “access value” are described.
In the “Process Name” column, the name of the process that has accessed the control signal is described.
In the “control signal name” column, the name of the control signal to be accessed is described.
In the “access type” column, the type of access performed is described.
In the “access value” column, a value read from the control signal or written to the control signal is described.

The description returns to the flowchart of FIG.
The interrupt simulation unit 105 refers to the I / O device status information (interrupt) in FIG. 10 at the interrupt point shown in FIG. 8, and generates an H / W interrupt when the interrupt status is “permitted”. (S106).
When the interrupt simulation unit 105 generates an H / W interrupt, the I / O device simulation program execution unit 1012 simulates the I / O port 205 and generates an interrupt to the interrupt processing 2032 of the implementation code 500.
The interrupt process 2032 accesses a target control signal (for example, state variable 1).
On the other hand, if the interrupt state at the interrupt point is “prohibited”, the interrupt simulation unit 105 does not generate an H / W interrupt.

Also, the timer simulation unit 106 refers to the I / O device state information (timer) in FIG. 11 and counts up the corresponding timer when the timer state is “start” (S108).
When the counter reaches the timer value or more and the timer expires, the implementation code execution unit 1011 executes the corresponding timer process 2033.

When the number of activations of the implementation code 500 and the I / O device simulation program 600 reaches the maximum number of steps in FIG. 7, the verification item analysis unit 104 verifies the number of control investigations and the control signal access log, and creates a verification report. (S110).

More specifically, the verification item analysis unit 104 refers to the control operation number information in FIGS. 12 to 15 and determines that the number of control operations is appropriate if the number of occurrences between related operations is balanced.
A method for determining each control operation is shown below.
Number of occurrences of "request operation" = number of occurrences of "response operation" (when the relation condition is YES)
Number of occurrences of “I / O read” = number of occurrences of “I / O write” (when the relational condition is YES)
Number of occurrences of "Allow interrupt" = Number of occurrences of "Interrupt prohibited" Number of occurrences of "Timer start" = Number of occurrences of "Timer end" + Number of occurrences of "Timeout" (in case of one shot)
Number of occurrences of "Timer start" = Number of occurrences of "Timer end" (if continued)
12 to 15, the verification item analysis unit 104 determines that the cooperative operation X of the control process A is appropriate, and also determines that the cooperative operation Y of the control process B is appropriate.
Further, it is determined that the I / O operation X of the control process A is not appropriate.
Further, it is determined that the interrupt operation X of the control process A is appropriate, and the interrupt operation Y of the control process B is determined not appropriate.
It is determined that the timer operation X of the control process A is appropriate and the timer operation Y of the control process B is not appropriate.

Further, the verification item analysis unit 104 refers to the control signal access log in FIG. 16, and access to the contention control signal by other processing is not mixed between access to the contention control signal by the control processing A or the like. Judge that interrupt control is appropriate.
In the example of FIG. 16, the verification item analysis unit 104 pays attention to the state variable 1, the state variable 2, and the state variable 3 that are competition control signals.
In the example of FIG. 16, the access from the interrupt process to the state variable 1 (No. 3) is mixed between the access from the control process A to these state variables (No. 2, No. 4, No. 5). Therefore, the verification item analysis unit 104 determines that the interrupt has not been properly prohibited at the expected interrupt prohibition timing.
That is, the verification item analysis unit 104 selects the timing between the access from the control process A to the state variable 1, the state variable 2, and the state variable 3 among the plurality of interrupt candidate timings as the interrupt prohibition assumption timing, It is checked whether or not any of the state variable 1, the state variable 2, and the state variable 3 has been accessed from another process at the assumed timing.
Then, the verification item analysis unit 104 determines that the interrupt is not properly prohibited if any of the state variable 1, the state variable 2, and the state variable 3 is accessed from other processing at the interrupt prohibition assumption timing. To do.

In addition, the verification item analysis unit 104 determines whether or not the access value indicated in the control signal access log is correct in view of an input product for creating the implementation code 500 such as a customer specification, control specification, and function specification. Judging.

Then, the verification item analysis unit 104 outputs a verification report.
In the verification report, at least items (control operation count, interrupt control) that are not determined to be appropriate by the verification item analysis unit 104 are described.
For example, the user of the simulator device 100 uses the verification report generated by the simulator device 100 to check the operation of the mounted code with a microcomputer emulator that has acquired ISO 26262 certification.
In this way, the mounting code can be easily adapted to the ISO26262 standard.

According to the simulator device 100 according to the present embodiment, the following effects can be obtained.

Since the implementation code is operated and verified on the computer, it is not necessary to generate a dedicated description as in the prior art.
Therefore, it is not necessary to guarantee the consistency between the implementation code and the dedicated description, and it is easy to guarantee the correctness of the verification result.

By exhaustively executing the input sequence and interrupt points to the S / W by executing the I / O device simulation program, it is possible to verify all processing variations due to the parallel operation of H / W and S / W.

Detecting defects related to the H / W-S / W interface by unit testing can reduce the number of reworking steps after the S / W coupling test.

As described above, in the present embodiment,
A configuration that analyzes the implementation code and linkage variables to create a verification scenario consisting of an input sequence and interrupt points,
Configuration that executes the implementation code according to the startup cycle and startup order specified in the scheduler settings,
A configuration for executing an I / O device simulation program according to a scheduler setting and a verification scenario;
A configuration for simulating the operation of the H / W timer according to the timer type, timer status, and timer value specified by the I / O device status information;
A configuration that monitors the control operation during execution of the implementation code and records the number of control operations,
A configuration for monitoring the access to the control signal during execution of the implementation code and recording the control signal access log,
A configuration for simulating H / W interrupt operation according to the verification scenario and the interrupt status specified by the I / O device status information;
A configuration for checking whether a request and a response correspond correctly in recording the number of control operations;
A configuration for verifying whether or not the conflicting control signal is exclusively accessed in the recording of the control signal access log; and
A configuration for creating a verification report from the number of control operations and control signal access log check results,
A software parallel operation verification apparatus provided with the above has been described.

Embodiment 2. FIG.
In the first embodiment, the method of verifying the mounting code 500 by constantly operating the control process to be verified has been described.
In the present embodiment, a method for verifying the implementation code 500 by dynamically generating or deleting a control process to be verified will be described.

In the present embodiment, the scheduler setting of FIG. 17 is used instead of the scheduler setting of FIG.
In the scheduler setting of FIG. 17, compared with the scheduler setting of FIG. 9, columns of an activation trigger and an activation state are added.
An event for starting or ending the control process is shown in the start trigger column.
In the example of FIG. 17, a cooperation signal, an I / O port, a state variable, and a counter are described.
In the example of FIG. 17, the control process C starts its operation when an event for inputting a predetermined cooperation signal 251 occurs, for example.

The mounted code execution unit 1011 periodically executes the control process and the hardware driver 203 whose activation state is “always”.
When a state that matches a start trigger of a certain control process occurs, if the start state is “start”, the implementation code execution unit 1011 starts the periodic execution of the control process.
Further, when a state that matches a start trigger of a certain control process occurs, if the start state is “end”, the mounted code execution unit 1011 ends the periodic execution of the control process.

As described above, according to the present embodiment, it is possible to verify the implementation code including the control process that operates only for a limited time.

As described above, in this embodiment, a start trigger is set in advance in the scheduler setting, and when a state that matches the start trigger occurs during execution of the implementation code, the corresponding control process is dynamically generated, and the corresponding A software parallel operation verification device that terminates the control processing to be performed has been described.

Embodiment 3 FIG.
In the first embodiment, the method of verifying the number of control operations for each control process has been described.
In the present embodiment, a method for verifying the number of control operations in units of groups in which a plurality of control processes are combined will be described.
That is, in this embodiment, the verification item analysis unit 104 verifies whether the relationship between the number of control operations is appropriate across a plurality of control processes.

There is a case where a request / response is dealt with in a plurality of control processes such that a certain control process permits an interrupt and another control process prohibits an interrupt.
In order to deal with such a case, the simulator device 100 according to the present embodiment creates a group of control processes, and determines that the number is appropriate if the number of requested operations and the number of response operations are equal in the group.
In the present embodiment, as in the first embodiment, the interrupt simulation unit 105 counts the number of control operations in units of control processing, but the verification by the verification item analysis unit 104 is performed in units of control processing.
In the present embodiment, for example, the control operation frequency information shown in FIG. 18 is used.
In FIG. 18, a “group name” column is added to the control operation count information (interrupt operation) in FIG. 14.
That is, in the example of FIG. 18, the control process A and the control process B are grouped.
In FIG. 18, only the control operation count information (interrupt operation) is shown, but the control operation count information (cooperation operation), the control operation count information (I / O operation), and the control operation count information (timer operation) are also similar. Add information.
In FIG. 18, in each of the control process A and the control process B, the number of interrupts allowed is not equal to the number of interrupts disabled. However, when verified in units of group α, the number of interrupts allowed = the number of interrupts disabled. Therefore, the verification item analysis unit 104 determines that the number of control operations is appropriate.

Thus, in this embodiment, flexible verification can be performed according to the occurrence state of the control operation.

As described above, in the present embodiment, the software parallel operation verification device that verifies whether the number of the plurality of control operations corresponds correctly in a group unit in which the plurality of control processes are collected has been described.

Finally, a hardware configuration example of the simulator apparatus 100 shown in the first to third embodiments will be described with reference to FIG.
The simulator device 100 is a computer, and each element of the simulator device 100 can be realized by a program.
As a hardware configuration of the simulator device 100, an arithmetic device 901, an external storage device 902, a main storage device 903, a communication device 904, and an input / output device 905 are connected to the bus.

The arithmetic device 901 is a CPU that executes a program.
The external storage device 902 is, for example, a ROM (Read Only Memory), a flash memory, or a hard disk device.
The main storage device 903 is a RAM (Random Access Memory).
1 is implemented by the external storage device 902 or the main storage device 903.
The communication device 904 is, for example, a NIC (Network Interface Card).
The input / output device 905 is, for example, a mouse, a keyboard, or a display device.

The program is normally stored in the external storage device 902, and is loaded into the main storage device 903 and sequentially read into the arithmetic device 901 and executed.
The program is a program that realizes the functions described as “˜unit” (excluding “˜storage unit” shown in FIG. 1; the same applies hereinafter).
Further, an operating system (OS) is also stored in the external storage device 902. At least a part of the OS is loaded into the main storage device 903, and the arithmetic device 901 executes “OS” shown in FIG. ”Is executed.
In the description of the first to third embodiments, “determining”, “determining”, “verifying”, “extracting”, “detecting”, “specifying”, “ ”Setting”, “Count of”, “Simulation of”, “Execution of”, “Selection of”, “Generation of”, “Input of”, “Output of”, etc. Information, data, signal values, and variable values indicating the results of processing are stored in the main storage device 903 as files.
Further, the encryption key / decryption key, random number value, and parameter may be stored in the main storage device 903 as a file.

Note that the configuration of FIG. 20 is merely an example of the hardware configuration of the simulator device 100, and the hardware configuration of the simulator device 100 is not limited to the configuration illustrated in FIG. 20, but may be other configurations. .

Further, the program verification method according to the present invention can be realized by the procedure shown in the first to third embodiments.

As mentioned above, although embodiment of this invention was described, you may implement in combination of 2 or more among these embodiment.
Alternatively, one of these embodiments may be partially implemented.
Alternatively, two or more of these embodiments may be partially combined.
In addition, this invention is not limited to these embodiment, A various change is possible as needed.

100 simulator device, 101 scheduler, 102 verification scenario creation unit, 103 control monitoring unit, 104 verification item analysis unit, 105 interrupt simulation unit, 106 timer simulation unit, 107 linked variable storage unit, 108 program storage unit, 109 scheduler setting storage unit , 110 Verification scenario storage unit, 111 I / O device state storage unit, 112 Control operation count storage unit, 113 Control signal access log storage unit, 114 Verification report storage unit, 115 Control operation information storage unit, 1011 Implementation code execution unit, 1012 I / O device simulation program execution unit, 200 control device, 201 control process A, 202 control process B, 203 hardware driver, 204 I / O port, 205 I / O port, 206 interrupt, 207 timer 2031 I / O processing, 2032 interrupt processing, 2033 timer processing, 251 linkage signal, 252 I / O port signal, 253 status variable, 254 counter signal, 300 sensor device, 400 driving device, 500 mounting code, 600 I / O device Mock program.

Claims (14)

1. A program verification device for verifying a verification target program including an interrupt setting process for performing settings related to an interrupt,
   Interrupt candidate timing that analyzes the verification target program and designates a plurality of timings at which an interrupt may occur when the verification target program is executed by a device that executes the verification target program as interrupt candidate timings, respectively A designated part;
   A program execution unit for executing the verification target program;
   When the program execution unit executes the verification target program, if the interrupt setting process is set to prohibit interrupt at the interrupt candidate timing, the interrupt setting process does not generate an interrupt at the interrupt candidate timing. If the setting for permitting an interrupt at the interrupt candidate timing is performed by the interrupt generation unit that generates an interrupt at the interrupt candidate timing,
   Among the plurality of interrupt candidate timings, an interrupt candidate timing that is assumed to be appropriate to prohibit interrupts is selected as an interrupt prohibition assumption timing, the execution result of the verification target program is analyzed, and the interrupt prohibition assumption timing is selected. And a verification unit for determining whether or not the setting for prohibiting the interrupt is performed by the interrupt setting process.
2. The program execution unit is
   Execute the verification target program that includes the variable access process that is the process to access the variable,
   The interrupt candidate timing designation unit
   A variable that is accessed by the variable access process and that is accessed by the interrupt generator when the interrupt generator generates an interrupt, is extracted as a conflict variable;
   The program verification apparatus according to claim 1, wherein timings before and after access to the contention variable by the variable access processing are respectively designated as interrupt candidate timings.
3. The verification unit
   Among the plurality of interrupt candidate timings, an interrupt candidate timing that falls between accesses to the conflicting variable by the variable access processing is selected as the interrupt prohibition assumption timing, and interrupts are prohibited by the interrupt setting processing at the interrupt prohibition assumption timing. The program verifying apparatus according to claim 2, wherein it is determined whether or not a setting to be performed has been performed.
4. The verification unit
   When an access history to the conflict variable is analyzed as an execution result of the verification target program, and it is detected that there is an access to the conflict variable by an interrupt between accesses to the conflict variable by the variable access processing 4. The program verification apparatus according to claim 3, wherein it is determined that the setting for prohibiting an interrupt at the interrupt prohibition assumed timing has not been performed by the interrupt setting process.
5. A program verification device for verifying a verification target program,
   Number of occurrences between related events when two or more related events among a plurality of events generated by execution of the verification target program are associated with each other as related events and the verification target program is appropriate A related event information storage unit for storing related event information indicating the relationship of
   A program execution unit for executing the verification target program;
   A counting unit that counts the number of occurrences of each related event during execution of the verification target program by the program execution unit;
   A program verification apparatus comprising: a verification unit that determines whether a relationship between related events of the number of occurrences counted by the counting unit matches a relationship indicated in the related event information.
6. The related event information storage unit
   Stores related event information indicating that the number of occurrences is balanced between related events as the relationship of the number of occurrences between related events,
   The verification unit
   6. The program verification apparatus according to claim 5, wherein it is determined whether or not the number of occurrences counted by the counting unit is balanced among related events.
7. The related event information storage unit
   Two or more related events generated by execution of the control process included in the verification target program;
   Two or more related events generated by executing an I / O (Input / Output) process included in the verification target program;
   Two or more related events generated by execution of an interrupt process included in the verification target program;
   7. The related event information in which at least one of two or more related events generated by execution of a timer process included in the verification target program is indicated as a related event is stored. The program verification apparatus as described.
8. The program execution unit is
   A verification target program in which an operation algorithm of a control device that controls an I / O (Input / Output) device is described simulates the operation of the I / O device and the operation of the interface of the control device to the I / O device. 8. The program verification apparatus according to claim 1, wherein the program verification apparatus is executed together with the I / O device simulation program.
9. The program execution unit is
   Including a plurality of control processes, executing a verification target program in which a start event is defined for a specific control process among the plurality of control processes;
   9. The program verification apparatus according to claim 1, wherein the specific control process is started when a start event of the specific control process occurs during execution of the verification target program. .
10. The program execution unit is
    Including a plurality of control processes, executing a verification target program in which an end event is defined for a specific control process among the plurality of control processes;
    10. The program verification apparatus according to claim 1, wherein when the end event of the specific control process occurs during the execution of the verification target program, the specific control process is ended. .
11. The program execution unit is
    Execute the verification target program including multiple control processes,
    The counting unit is
    Counting the number of occurrences of each related event during execution of the verification target program by the program execution unit in units of control processing,
    The verification unit
    A determination is made as to whether or not the relationship between the related events of the number of occurrences counted by the counting unit matches the relationship indicated in the related event information across two or more control processes. Item 6. The program verification device according to Item 5.
12. A computer verification method for verifying a verification target program including an interrupt setting process for performing settings related to an interrupt,
    The computer analyzes the verification target program and designates a plurality of timings at which an interrupt may occur when the verification target program is executed on a device that executes the verification target program as interrupt candidate timings, respectively. And
    The computer executes the verification target program,
    If the computer is set to prohibit interrupts at the interrupt candidate timing by the interrupt setting process when the verification target program is executed, the interrupt setting process does not generate an interrupt and the interrupt setting process If a setting is made to allow an interrupt at the interrupt candidate timing, an interrupt is generated at the interrupt candidate timing,
    The computer selects an interrupt candidate timing that is assumed to be appropriate to prohibit an interrupt from the plurality of interrupt candidate timings as an interrupt prohibition assumption timing, analyzes the execution result of the verification target program, and A program verification method comprising: determining whether or not a setting for prohibiting an interrupt has been made by the interrupt setting process at an interrupt prohibition assumption timing.
13. A computer verification method for verifying a verification target program,
    Number of occurrences between related events when two or more related events among a plurality of events generated by execution of the verification target program are associated with each other as related events and the verification target program is appropriate The related event information indicating the relationship is read from a predetermined storage area by the computer,
    The computer executes the verification target program,
    The computer counts the number of occurrences of each related event during execution of the verification target program,
    The program verification method, wherein the computer determines whether or not a relationship between the related events of the counted number of occurrences matches a relationship indicated in the related event information.
14. A program that causes a computer to function as the program verification device according to claim 1 or 5.

Images