JP2013149164A - Software verification support device, software verification support method, and software verification support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software verification support technique for providing software which has high safety and reusability and is capable of suppressing a program size.SOLUTION: In the case in which a condition described by a conditional branch instruction is always satisfied, a software verification support device allows instructions executed when the condition is satisfied to remain within a source code, while deleting instructions executed when the condition is not satisfied from the source code.

Description

  The present invention relates to a technique for supporting a task of verifying software source code.

  A control device such as an automobile executes a control operation using a microcontroller (hereinafter referred to as a microcomputer). The software installed in the microcomputer is generally configured by an application program that performs control processing, a device driver that performs data input / output, an operating system (OS), and the like. The vehicle control device is required to have high safety in order to perform control directly related to the safety of the vehicle occupant. Therefore, fail-safe processing is used in which failure diagnosis of the control device is performed and the control device is transitioned to a safe state when a failure is detected.

  In recent years, with the advancement of control and the increase in scale, the number of input / output devices related to vehicle safety has increased, and the development man-hours of diagnostic software has become a problem.

  Software used for vehicle control is configured to be reusable across a plurality of products in order to cope with many product variations, thereby improving software development efficiency.

  For example, a part having different processing contents depending on the environment in which the software is installed is separated as a module so that a common part can be reused without depending on the environment. Further, the module from which the part depending on the environment is separated is configured such that processing corresponding to each environment can be executed by changing a parameter delivered at the time of execution, thereby improving reusability.

  As described above, the software module whose operation is changed depending on the parameter may receive various parameters depending on the environment, and thus may receive a parameter that the module does not assume. In this case, in order to prevent the module from causing an unexpected operation due to an unexpected parameter, it is necessary to determine whether or not the parameter is appropriate before performing the operation related to the received parameter. is there.

  As a software design technique for performing such parameter pre-verification, there is a technique called “defensive programming”. Defensive programming is based on the belief that the module may be called under unexpected operating conditions, and checks the operating conditions before the module performs the intended function. Is a design method that performs exception handling such as error handling.

  Patent Document 1 listed below describes a technique for verifying the operation of software by inserting an assertion instruction into a source code as a technique for verifying the operation of engine control software.

JP 2008-276556 A

Steve McConnell, Code Complete 2nd Edition, Nikkei BP Soft Press, 2005

  Software that needs to perform real-time control, such as vehicle control, is required to have the correct control processing contents from the viewpoint of safety, but the control processing must be performed at an appropriate timing. Is also required at the same time. Therefore, there are many cases where a slight processing delay of about several microseconds is not allowed.

  On the other hand, software modules that employ the above-mentioned defensive programming use conditional branch instructions to ensure that the parameters match a predetermined condition so that they do not operate unexpectedly when called with unexpected parameters. It is configured to execute the process only when the condition is met. For this reason, it is necessary to describe the condition determination related to the conditional branch instruction, the processing when the condition is not met, and the amount of source code tends to increase. As a result, the program capacity increases and the execution speed tends to decrease.

  The present invention has been made in order to solve the above-described problems, and it is an object of the present invention to obtain a software verification support technique for obtaining software that has high safety and reusability and can reduce the program size. Objective.

  When the condition described by the conditional branch instruction is always satisfied, the software verification support apparatus according to the present invention leaves the instruction to be executed when the condition is satisfied in the source code, and then the condition is satisfied. The instruction executed when there is not is deleted from the source code.

  According to the software verification support apparatus of the present invention, unnecessary conditional branch instructions can be deleted from the source code, so that the program size can be suppressed while ensuring reusability of the original source code. Further, since the conditional branch instruction that is always satisfied is deleted, an unexpected parameter is not transferred to the conditional branch instruction, causing an unexpected result, and safety can be ensured.

It is a figure which shows the structural example of the motor vehicle engine control system carrying the software which the software verification assistance apparatus which concerns on this invention mounts. It is a figure which shows the structure of the software verification assistance apparatus 100 which concerns on this invention. It is an example of the source code which the software verification assistance apparatus 100 makes into verification object. It is a figure which shows the example which inserted the test instruction | indication into the source code of FIG. FIG. 10 is a diagram illustrating an example of a conditional expression pattern 1720 used when the test instruction generation unit 120 extracts a conditional expression part from a conditional branch instruction 1711. It is a figure which shows the pattern of the test | inspection command which the test | inspection command production | generation part 120 produces | generates. It is a figure which shows the example of source code after the software test | inspection assistance apparatus 100 deletes a conditional branch instruction. It is a figure which shows the operation | movement flow of the process in which the software test | inspection assistance apparatus 100 produces | generates a test | inspection command. It is a figure which shows the operation | movement flow of the process which the software inspection assistance apparatus 100 deletes a conditional branch instruction from a source code. 10 is an operation flow when the inspection execution unit 140 compiles and executes a source code to be inspected in the second embodiment.

<Embodiment 1>
FIG. 1 is a diagram showing a configuration example of an automobile engine control system in which software targeted by a software verification support apparatus according to the present invention is installed. The control unit 200 is a device that executes control software for controlling the operation of the engine, and includes a microcontroller 210, a drive circuit 220, a communication circuit 230, and a signal input / output circuit 240.

  The signal input / output circuit 240 acquires detection results from the acceleration sensor 311 and the yaw rate sensor 312, and outputs them to the microcontroller 210. The drive circuit 220 drives and controls the actuator 320 according to instructions from the microcontroller 210, thereby controlling the operation of the engine. The communication circuit 230 communicates with the diagnostic terminal 330 and the control device 340 via the communication line 350.

  The diagnosis terminal 330 is a terminal for diagnosing the control unit 200 via the communication line 350. The control device 340 is a device that performs control processing different from the control unit 200.

  The microcontroller 210 includes an input circuit 211, an arithmetic unit 212, a RAM (Random Access Memory) 213, a ROM (Read Only Memory) 214, an output circuit 215, and a communication control device 216.

  The input circuit 211 receives the detection result of each sensor from the signal input / output circuit 240 and outputs it to the arithmetic device 212. The arithmetic device 212 executes control software describing the control process. The RAM 213 stores data temporarily used when the arithmetic device 212 executes the control software. The ROM 214 stores control software executed by the arithmetic device 212. The output circuit 215 outputs a control signal to the drive circuit 220. The communication control device 216 communicates with the outside via the communication circuit 230.

  The acceleration sensor 311 and the yaw rate sensor 312 described above are examples of sensors connected to the control unit 200, and control the vehicle using detection results of other sensors, for example, sensors that detect temperature, current, and other physical quantities. Needless to say, the control unit can also execute software targeted by the software verification support apparatus according to the present invention.

  FIG. 2 is a diagram showing the configuration of the software verification support apparatus 100 according to the present invention. The software verification support apparatus 100 includes a control unit 110, a test command generation unit 120, a test command insertion unit 130, a test execution unit 140, a test result acquisition unit 150, a conditional branch deletion unit 160, and a storage unit 170.

  The control unit 110 is configured by an arithmetic device such as a CPU (Central Processing Unit), and controls each functional unit.

  The check instruction generation unit 120 generates a check instruction for checking whether or not a conditional branch instruction (typically an if-else statement) in the software source code is always satisfied. For example, an assert instruction to be described later can be used as the inspection instruction. The inspection instruction insertion unit 130 inserts the inspection instruction generated by the inspection instruction generation unit 120 immediately before or after the conditional branch instruction in the source code.

  The inspection execution unit 140 compiles and executes the source code in which the inspection instruction is inserted, and stores the result in the storage unit 170. When the inspection instruction is executed by the inspection execution unit 140, a log indicating whether or not the conditional expression in the conditional branch instruction is satisfied is stored in the storage unit 170. Therefore, when the test execution unit 140 compiles and executes the source code including the test instruction, a log indicating whether the conditional expression in the conditional branch instruction is satisfied is stored in the storage unit 170.

  The inspection result acquisition unit 150 acquires the execution result of the inspection execution unit 140 from the storage unit 170, and determines whether the conditional expression in the conditional branch instruction is always satisfied according to the log described above.

  If the conditional expression in the conditional branch instruction is always satisfied, the conditional branch deletion unit 160 leaves the instruction to be executed when the condition is satisfied (the instruction included in the if statement) in the source code. An instruction (an instruction included in an else statement) that is executed when the condition is not satisfied is deleted from the source code. If the conditional expression in the conditional branch instruction does not necessarily hold, both of the above are left in the source code.

  The storage unit 170 includes a source code storage unit 171, a conditional expression pattern storage unit 172, an inspection instruction storage unit 173, an inspection target source code storage unit 174, an inspection result storage unit 175, and a resource constraint condition storage unit 176.

  The source code storage unit 171 stores a source code to be inspected by the software inspection support apparatus 100. The conditional expression pattern storage unit 172 stores an extraction pattern used for extracting a conditional expression part from a conditional branch instruction when the check instruction generation unit 120 generates a check instruction. Details will be described later. The inspection instruction storage unit 173 stores the inspection instruction generated by the inspection instruction generation unit 120. The inspection source code storage unit 174 stores the source code into which the inspection instruction insertion unit 130 has inserted the inspection instruction. The inspection result storage unit 175 stores a result obtained by compiling and executing the source code into which the inspection instruction is inserted by the inspection execution unit 140. The resource constraint storage unit 176 stores data describing constraint conditions such as hardware resources required when the inspection execution unit 140 compiles and executes the source code.

  The configuration of the software verification support apparatus 100 has been described above. Next, a process for inserting a test instruction into the source code will be described together with an example of the source code.

  FIG. 3 is an example of source code to be verified by the software verification support apparatus 100. This source code includes a conditional branch instruction (if {) 1711, an instruction when condition is not satisfied (else {) 1712, and a conditional branch end instruction (}) 1713.

  In this source code, an array of the size LINETH is secured in the portion included in the conditional branch instruction 1711, and the elements from the first element of this array to the element of the number specified by the parameter iParam are initialized. In these processes, since the size of the array to be initialized differs depending on the environment in which the software is executed, this is generalized as a parameter iParam so that an array of an arbitrary size can be initialized and does not depend on the environment. It is intended to be a reusable module.

  In these processes, since it is assumed that the parameter iParam is less than the array size LIMITIT, the conditional branch instruction 1711 excludes iParam having a value greater than or equal to LINETH. In other words, at the time this source code is created, it is not determined what kind of environment this source code will be used for, so indeterminate parameters should be checked in advance so as not to make the operation of the software unstable. It is a thing. As a result, it is possible to ensure the safety of the operation while ensuring the reusability of the source code. Such a technique is referred to as the defensive programming described above.

  On the other hand, after the environment in which the source code is used is determined, there are cases where the value of the parameter iParam can be determined at the time of execution. In such a case, the conditional branch instruction 1711, the condition non-satisfied instruction 1712, and the conditional branch end instruction 1713 are redundantly described, and on the contrary, cause a software capacity to be increased unnecessarily.

  Therefore, in the present invention, the conditional branch instruction 1711, the condition non-satisfied instruction 1712, and the conditional branch end instruction 1713 are deleted from the source code for the conditional branch instructions such as those illustrated in FIG. In addition, unnecessary instructions such as error processing included in the instruction 1712 when the condition is not satisfied are also deleted.

  Specifically, the software verification support apparatus 100 incorporates parameters specific to the environment in which the source code is used, compiles and actually executes the source code, and the conditional branch instruction 1711 is described. It is verified whether or not the conditional expression is actually satisfied. Hereinafter, a specific method for this will be described.

  The parameters specific to the environment using this source code can be described in a data file such as a C language header file, or the source code describing the parameters specific to the environment together with this source code. It can also be incorporated into this source code by compiling and incorporating it into an execution module.

  In general, a source code includes a plurality of conditional branch instructions. Since not all conditional branch instructions are redundant instructions as described above, whether or not to delete only the part describing conditional expressions that may change depending on the environment in which the source code is used Can be determined. Therefore, in the source code shown in FIG. 3, in order to identify the conditional branch instruction to be determined whether or not to delete, the conditional branch instruction identification comment 1714, a condition not satisfied, is used as a comment statement that does not affect the contents of the source code. An instruction identification comment 1715 and a conditional branch end instruction identification comment 1716 are given.

  A conditional branch instruction identification comment 1714, a condition identification failure instruction identification comment 1715, and a conditional branch termination instruction identification comment 1716 are software locations where the conditional branch instruction 1711, conditional branch failure instruction 1712, and conditional branch termination instruction 1713 are described, respectively. This is for the verification support apparatus 100 to identify. The format of the comment sentence may be arbitrary, but in FIG. 3, as an example, comments are given in the form of “@CC_if_identification number”, “@CC_else_identification number”, and “@CC_endif_identification number”.

  In order to verify whether or not the conditional expression described in the conditional branch instruction 1711 is actually satisfied, in addition to compiling and executing the source code, when the conditional expression is satisfied It is desirable to record as a log. For example, it is conceivable to newly insert an instruction for recording an appropriate log in the conditional branch instruction 1711. The instruction in the conditional branch instruction 1711 is executed only when the conditional expression is satisfied. Therefore, if a log recording instruction is inserted in the conditional branch instruction 1711, it means that the instruction is executed. This is equivalent to the fact that the formula is established.

  In the first embodiment, an assert instruction often used in software operation verification is used as a function having the same function. The assert instruction is a function that returns true when a specified conditional expression is satisfied, and returns false when the specified conditional expression is not satisfied, or performs a similar operation. In the first embodiment, it is assumed that a check instruction called _COVER_assert shown in FIG. 4 is used. This is an instruction configured to store in the inspection result storage unit 175 a log indicating whether or not a specified conditional expression is satisfied.

  FIG. 4 is a diagram showing an example in which a test instruction is inserted into the source code of FIG. In FIG. 4, a check instruction 1717 is newly inserted immediately before the conditional branch instruction 1711.

  When the check instruction insertion unit 130 finds the conditional branch instruction identification comment 1714 in the source code, the check instruction insertion unit 130 generates a check instruction 1717 for verifying whether or not the corresponding conditional branch instruction 1711 is always established, immediately before the conditional branch instruction 1711. Insert (or immediately after).

  Since the check instruction 1717 is for verifying whether or not the conditional branch instruction 1711 is established, the conditional expression specified by the check instruction 1717 needs to be the same as the conditional expression in the conditional branch instruction 1711. The check instruction generation unit 120 extracts a conditional expression part from the conditional branch instruction 1711 and generates a check instruction 1717 that specifies this as a conditional expression.

  FIG. 5 is a diagram illustrating an example of a conditional expression pattern 1720 used when the test instruction generation unit 120 extracts a conditional expression portion from the conditional branch instruction 1711. The conditional expression pattern is a character string template for extracting a character string that specifies that the conditional expression starts or ends in the program code and a character string that describes the conditional expression itself, and a conditional expression pattern storage unit. 172 is stored as data. For example, the conditional expression pattern 1720 can be described using a regular expression. However, the present invention is not limited to this, and it is only necessary to extract a character string that matches a specified character string expression. FIG. 5 shows an example in which the conditional expression pattern 1720 is configured using regular expressions.

  The conditional expression pattern 1720 shown in FIG. 5 extracts an arbitrary character string described between a fixed pattern 1721 for extracting a character string specifying that the conditional expression starts or ends and a fixed pattern 1721. And an optional pattern 1722. Using the conditional expression pattern 1720, the test instruction generation unit 120 can extract a conditional expression described in the if statement (iParam <LINETH in the examples of FIGS. 3 to 4).

  The conditional expression pattern 1720 can also describe a plurality of extraction patterns. When the check instruction generation unit 120 finds a character string that matches any of the extraction patterns, the check instruction generation unit 120 generates the check instruction 1717 using the conditional expression, and the conditional branch instruction that does not match all the extraction patterns has an empty condition. Is specified, and the inspection instruction 1717 is generated.

  FIG. 6 is a diagram illustrating a pattern of inspection instructions generated by the inspection instruction generation unit 120. The inspection instruction generation unit 120 generates an inspection instruction according to the inspection instruction pattern 1730 shown in FIG. 6 and stores it in the inspection instruction storage unit 173. The inspection instruction insertion unit 130 reads the inspection instruction stored in the inspection instruction storage unit 173 and inserts it into the source code.

  The inspection instruction pattern 1730 includes a line number portion 1731, an insertion location instruction portion 1732, an inspection instruction fixing portion 1733, and a conditional expression portion 1734.

  The line number part 1731 designates a line number in the source code into which the inspection instruction is to be inserted. The insertion location instruction unit 1732 specifies whether the inspection instruction is inserted immediately before or immediately after the line designated by the line number part 1731. The inspection instruction fixing unit 1733 is a fixed part excluding the conditional expression in the character string describing the inspection instruction. The conditional expression unit 1734 is a part in which the conditional expression extracted from the conditional branch instruction by the check instruction generation unit 120 using the conditional expression pattern 1720 is embedded.

  FIG. 7 is a diagram illustrating an example of source code after the software inspection support apparatus 100 deletes the conditional branch instruction. 3 to 4, the conditional branch instruction 1711, the condition unsatisfied instruction 1712, the conditional branch end instruction 1713, the conditional branch instruction identification comment 1714, the condition unsatisfied instruction identification comment 1715, and the conditional branch end instruction identification. The comment 1716 and the inspection instruction 1717 are deleted from the source code, and unnecessary instructions such as error processing included in the instruction 1712 when the condition is not satisfied are also deleted. As a result, the object code corresponding to the deleted part is not generated, so that the program capacity and the program execution load can be reduced.

  The basic concept when the software inspection support apparatus 100 deletes the conditional branch instruction from the source code has been described above. Hereinafter, a specific operation procedure of the software inspection support apparatus 100 will be described.

FIG. 8 is a diagram illustrating an operation flow of processing in which the software inspection support apparatus 100 generates an inspection instruction. Hereinafter, each step of FIG. 8 will be described.
(FIG. 8: Step S800)
The software inspection support apparatus 100 executes this operation flow and generates an inspection instruction before compiling and executing the source code to be inspected.
(FIG. 8: Step S801)
The inspection instruction generation unit 120 reads one line of source code to be inspected from the source code storage unit 171. Further, the value of the row number portion 1731 described with reference to FIG.

(FIG. 8: Step S802)
The test instruction generation unit 120 determines whether or not the conditional branch instruction identification comment 1714 (@CC_if_identification number) is included in the source code for one line read in step S801. If it is included, the process proceeds to step S803. If it is not included, the process skips to step S805.
(FIG. 8: Step S803)
The test instruction generation unit 120 extracts the conditional expression included in the conditional branch instruction according to the conditional expression pattern described with reference to FIG.

(FIG. 8: Step S804)
The inspection instruction generation unit 120 generates an inspection instruction according to the conditional expression extracted in step S803 and the inspection instruction pattern described in FIG. 6 and stores the inspection instruction in the inspection instruction storage unit 173. The line number updated in step S801 is used for the line number portion 1731. The value of the insertion location instruction unit 1732 may be specified in advance, for example. Further, the identification number included in the conditional branch instruction identification comment 1714 is stored, and stored together with the execution result of the inspection instruction in the inspection result storage unit 175.
(FIG. 8: Step S805)
If the end of the source code read in step S801 has been reached, the process proceeds to step S806, and if a line that has not been read remains, the process returns to step S801 and the same processing is repeated.

(FIG. 8: Step S806)
After this operation flow ends, the test instruction insertion unit 130 inserts the test command generated by the test command generation unit 120 and stored in the test command storage unit 173 immediately before or after the line specified by the line number unit 1731. And stored in the inspection source code storage unit 174. The inspection execution unit 140 compiles and executes the source code in which the inspection instruction is inserted, and stores the execution result of the inspection instruction in the inspection result storage unit 175. Moreover, the restriction condition regarding the hardware resource is acquired from the resource restriction condition storage unit 176 as necessary, and the inspection is performed within a range satisfying the restriction condition.

FIG. 9 is a diagram illustrating an operation flow of processing in which the software inspection support apparatus 100 deletes the conditional branch instruction from the source code. Hereinafter, each step of FIG. 9 will be described.
(FIG. 9: Step S900)
The software inspection support apparatus 100 executes this operation flow after compiling and executing the source code to be inspected, and deletes the conditional branch instruction from the source code.
(FIG. 9: Step S901)
The inspection result acquisition unit 150 acquires the execution result of the inspection instruction from the inspection result storage unit 175. The execution result of the check instruction includes whether or not a conditional expression of each of the check instructions existing in the source code is satisfied, and the check instruction identification number (the identification number included in the conditional branch instruction identification comment 1714). . The inspection result acquisition unit 150 lists each inspection result after distinguishing each inspection instruction by an identification number.

(FIG. 9: Step S902)
The conditional branch deletion unit 160 reads the source code into which the inspection instruction is inserted from the inspection target source code storage unit 174 line by line.
(FIG. 9: Step S903)
The conditional branch deletion unit 160 determines whether or not the conditional branch instruction identification comment 1714 is included in the source code for one line read in step S902. If it is included, the process proceeds to step S904. If it is not included, the process proceeds to step S911.

(FIG. 9: Step S904)
The conditional branch deletion unit 160 acquires the inspection result of the inspection instruction corresponding to the conditional branch instruction from the inspection result storage unit 175 using the identification number included in the conditional branch instruction identification comment 1714 as a key.
(FIG. 9: Step S905)
If the inspection result acquired in step S904 is a successful inspection, the process proceeds to step S906, and if the inspection is unsuccessful, the process proceeds to step S911.
(FIG. 9: Step S905: Supplement)
If the check result in this step is a check success, it indicates that the conditional statement in the corresponding conditional branch instruction is established, and thus the process proceeds to the steps after step S906 to delete the redundant instruction statement. If the check result in this step is failure, it indicates that the conditional statement in the conditional branch instruction read in step S902 does not necessarily hold, so the process proceeds to step S911, where the conditional branch instruction is the source code. Leave in.

(FIG. 9: Step S906)
The conditional branch deletion unit 160 reads the next line of the source code line read immediately before from the inspection source code storage unit 174.
(FIG. 9: Step S907)
The conditional branch deletion unit 160 determines whether or not the instruction identification comment 1715 when the condition is not satisfied is included in the source code for one line read in step S906. If it is included, the process proceeds to step S909. If it is not included, the process proceeds to step S908.

(FIG. 9: Step S908)
The conditional branch deletion unit 160 writes the source code for one line read in step S906 as it is into the inspection source code storage unit 174. After this step, the process returns to step S906 and the same processing is repeated.
(FIG. 9: Step S909)
The conditional branch deletion unit 160 reads the next line of the source code line read immediately before from the inspection source code storage unit 174.

(FIG. 9: Step S910)
The conditional branch deletion unit 160 determines whether or not the conditional branch end instruction identification comment 1716 is included in the source code for one line read in step S909. If not included, the process returns to step S909 to repeat the same processing. If it is included, the process returns to step S902 and the same processing is repeated.
(FIG. 9: Step S911)
The conditional branch deletion unit 160 writes the source code for one line read in step S902 back to the inspection source code storage unit 174 as it is.
(FIG. 8: Step S912)
If the end of the source code has been reached, this operation flow is terminated. If there are any unread lines remaining, the process returns to step S902 to repeat the same processing.

<Embodiment 1: Summary>
As described above, the software verification support apparatus 100 according to the first embodiment compiles and executes the source code in which the check instruction is inserted, and when it is found that the conditional expression in the conditional branch instruction is always satisfied, Delete redundant conditional branch instructions from the source code. As a result, unnecessary conditional branch instructions, conditional failure instructions, conditional branch end instructions, and instructions included in conditional failure instructions can be removed, and the program capacity after compilation can be reduced. Also, by deleting redundant instructions, the processing load can be reduced and the real-time performance of the control processing can be improved.

  Further, the software verification support apparatus 100 according to the first embodiment takes in a data file describing parameters specific to the environment in which the source code is used when compiling and executing the source code in which the inspection instruction is inserted, Execute in combination with the source code to be verified. As a result, it is possible to simulate an environment in which the source code to be inspected is used, and to verify whether the conditional expression in the conditional branch instruction is reliably established in the environment.

<Embodiment 2>
In the first embodiment, it has been described that the inspection execution unit 140 compiles and executes the source code in which the inspection instruction is embedded. In general, the process of inspecting the behavior of source code by compiling and actually executing the source code consumes a lot of hardware resources such as CPU load and memory usage. May be imposed. In the second embodiment of the present invention, a specific example will be described. Since operations other than the operation of the inspection execution unit 140 are substantially the same as those in the first embodiment, the following description will focus on differences.

FIG. 10 is an operation flow when the inspection execution unit 140 compiles and executes the source code to be inspected in the second embodiment. Hereinafter, each step of FIG. 10 will be described.
(FIG. 10: Step S1000)
The inspection execution unit 140 starts this operation flow in step S806 of FIG.
(FIG. 10: Steps S1001 to S1002)
The inspection execution unit 140 reads the inspection target source code from the inspection target source code storage unit 174 (S1001). Further, the constraint condition related to the hardware resource is acquired from the resource constraint condition storage unit 176 (S1002).
(FIG. 10: Step S1002: Supplement)
In the second embodiment, the constraint conditions related to the hardware resources stored in the resource constraint storage unit 176 are the maximum value of the used memory amount and the maximum elapsed time from the start of inspection.

(FIG. 10: Step S1003)
The inspection execution unit 140 compiles the inspection target source code read in step S1001 and starts execution. The processing in this step can be executed using a general software verification tool. For example, a tool such as CBMC (see Edmund Clarke, ANSI-C Bounded Model Checker User Manual, 2006) can be used. This tool is software that comprehensively verifies whether or not the conditions described in the software source code are satisfied.
(FIG. 10: Step S1004)
The inspection execution unit 140 waits for a predetermined time while executing the inspection.

(FIG. 10: Step S1005)
The inspection execution unit 140 acquires the current memory usage. As a specific method for acquiring the memory usage, a system call of the operating system of the computer on which the inspection program is operating may be used. If the acquired memory usage exceeds the maximum usage specified by the resource constraint storage unit 176, the process proceeds to step S1007. If not, the process proceeds to step S1006.
(FIG. 10: Step S1006)
The inspection execution unit 140 acquires the current time and calculates the elapsed time since the start of the inspection.

(FIG. 10: Step S1007)
The inspection execution unit 140 interrupts the inspection started in step S1003 and executes the used memory amount excess error process. For example, the line number of the source code being executed when the inspection is interrupted is stored in the inspection result storage unit 175.
(FIG. 10: Step S1008)
The inspection execution unit 140 proceeds to step S1010 if the elapsed time from the start of inspection exceeds the maximum elapsed time specified by the resource constraint storage unit 176, and proceeds to step S1009 if it does not exceed the maximum elapsed time. .

(FIG. 10: Step S1009)
The inspection execution unit 140 ends the operation flow when the inspection started in step S1003 is completed, and returns to step S1004 to repeat the same processing when the inspection is in progress.
(FIG. 10: Step S1010)
The inspection execution unit 140 interrupts the inspection started in step S1003 and executes an elapsed time excess error process. For example, the line number of the source code being executed when the inspection is interrupted is stored in the inspection result storage unit 175.

(FIG. 10: Step S1011)
After this operation flow is completed, the software inspection support apparatus 100 executes the operation flow described with reference to FIG. If the inspection result indicating that each excess processing has been executed is recorded in step S1007 or S1010, the source code portion after the inspection is interrupted is left unconditionally. This is because it has not been verified whether the conditional expression is satisfied.

<Embodiment 2: Summary>
As described above, in the software inspection support apparatus 100 according to the second embodiment, when the amount of hardware resources necessary for the inspection execution unit 140 to compile and execute the source code exceeds a predetermined constraint condition, Suspend the inspection and record to that effect. As a result, it is possible to avoid a situation where the inspection does not end indefinitely due to insufficient hardware capability.

  Also, the software inspection support apparatus 100 according to the second embodiment leaves the subsequent source code unconditionally when the inspection execution unit 140 interrupts the inspection halfway. As a result, only conditional branch instructions and the like that have been reliably determined to be redundant can be deleted from the source code.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  In addition, each of the above-described configurations, functions, processing units, etc. can be realized as hardware by designing all or a part thereof, for example, with an integrated circuit, or the processor executes a program for realizing each function. By doing so, it can also be realized as software. Information such as programs and tables for realizing each function can be stored in a storage device such as a memory or a hard disk, or a storage medium such as an IC card or a DVD.

  DESCRIPTION OF SYMBOLS 100: Software verification assistance apparatus, 110: Control part, 120: Inspection instruction generation part, 130: Inspection instruction insertion part, 140: Inspection execution part, 150: Inspection result acquisition part, 160: Condition branch deletion part, 170: Storage part 171: Source code storage unit 172: Conditional expression pattern storage unit 173: Inspection instruction storage unit 174: Inspection target source code storage unit 175: Inspection result storage unit 176: Resource constraint condition storage unit 200: Control Unit: 210: Microcontroller, 211: Input circuit, 212: Arithmetic unit, 213: RAM, 214: ROM, 215: Output circuit, 216: Communication control device, 220: Drive circuit, 230: Communication circuit, 240: Signal input Output circuit, 311: acceleration sensor, 312: yaw rate sensor, 320: actuator, 330: diagnostic end , 340: controller, 350: communication line.

Claims (10)

A device that supports the work of verifying the source code of software,
An inspection unit for acquiring a result obtained by compiling and executing the source code;
A test result acquisition unit that determines whether or not a condition described by a conditional branch instruction in the source code is satisfied, according to the result;
If the condition is always satisfied, the instruction executed when the condition is satisfied is left in the source code, and the instruction executed when the condition is not satisfied is deleted from the source code. Conditional branch deletion section
A software verification support apparatus comprising: The inspection unit
Of the parameters that specify the conditions described by the conditional branch instruction, the parameter data describing the parameters specific to the environment in which the software is installed is incorporated into the source code, and the result of compiling and executing is obtained. Acquired,
The inspection result acquisition unit
The software verification support apparatus according to claim 1, wherein it is determined whether or not the condition is always satisfied in the environment by acquiring an execution result of the source code in which the parameter data is incorporated. A check instruction insertion unit for inserting a check instruction for checking whether or not the conditional branch instruction is always satisfied, immediately before or after the conditional branch instruction in the source code;
A storage unit for storing a log describing a result of compiling and executing the source code;
With
The inspection instruction is:
When the inspection unit executes the inspection instruction, the storage unit is configured to store a log indicating whether or not the conditional branch instruction is satisfied,
The inspection instruction insertion unit is
Before the inspection unit compiles and executes the source code, the inspection instruction is inserted into the source code,
The inspection result acquisition unit
The software verification support apparatus according to claim 1, wherein it is determined whether or not the condition is always satisfied based on a log of the inspection instruction stored in the storage unit. The inspection instruction insertion unit is
4. The software verification support apparatus according to claim 3, wherein the check instruction is inserted according to a comment sentence in the source code indicating a location where a conditional branch instruction to which the check instruction is to be inserted is described. The inspection unit
When the amount of hardware resources necessary for compiling and executing the source code exceeds a predetermined upper limit, the execution is interrupted,
The inspection result acquisition unit
The conditional branch instructions other than those already executed at the time of interruption are determined to be uncertain whether or not the condition is always satisfied,
The conditional branch deletion unit
For the conditional branch instruction that is uncertain whether or not the condition is satisfied, the instruction that is executed when the condition is satisfied, and the instruction that is executed when the condition is not satisfied, the source code The software verification support apparatus according to claim 1, wherein the software verification support apparatus is left without being deleted. The inspection unit
The software verification support apparatus according to claim 5, wherein the execution is interrupted when a memory capacity consumed when the source code is compiled and executed exceeds a predetermined upper limit value. The inspection unit
The software verification support apparatus according to claim 5, wherein the execution is interrupted when an elapsed time from the start of compiling and executing the source code exceeds a predetermined upper limit value. The inspection unit
6. The software verification support apparatus according to claim 5, wherein when the execution is interrupted, a line number of the source code which is about to be executed at that time is stored in the storage unit. A method for supporting the work of verifying the source code of software,
Obtaining a result of compiling and executing the source code;
Determining according to the result whether or not a condition described by a conditional branch instruction in the source code is necessarily satisfied,
If the condition is always satisfied, the instruction executed when the condition is satisfied is left in the source code, and the instruction executed when the condition is not satisfied is deleted from the source code. Step to do,
A software verification support method characterized by comprising:   A software verification support program that causes a computer to execute the software verification support method according to claim 9.

Images