WO2013108730A1 - ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム - Google Patents

ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム Download PDF

Info

Publication number
WO2013108730A1
WO2013108730A1 PCT/JP2013/050503 JP2013050503W WO2013108730A1 WO 2013108730 A1 WO2013108730 A1 WO 2013108730A1 JP 2013050503 W JP2013050503 W JP 2013050503W WO 2013108730 A1 WO2013108730 A1 WO 2013108730A1
Authority
WO
WIPO (PCT)
Prior art keywords
instruction
source code
inspection
conditional branch
satisfied
Prior art date
Application number
PCT/JP2013/050503
Other languages
English (en)
French (fr)
Inventor
成沢　文雄
祐 石郷岡
統宙 月舘
渉 永浦
櫻井　康平
正裕 松原
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Publication of WO2013108730A1 publication Critical patent/WO2013108730A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G06F8/4434—Reducing the memory space required by the program code
    • G06F8/4435—Detection or removal of dead or redundant code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Definitions

  • the present invention relates to a technology that supports the work of verifying the source code of software.
  • 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.
  • the software used for vehicle control is configured to be reusable across multiple products in order to deal with many product variations, thereby improving the software development efficiency.
  • parts that differ in processing contents depending on the environment in which the software is installed are separated as modules, and a common part can be reused without depending on the environment.
  • 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.
  • a software module that changes its operation depending on a parameter may receive various parameters depending on the environment, and therefore may receive a parameter that the module does not expect.
  • it is necessary to determine whether or not the parameter is appropriate before performing the operation related to the received parameter. is there.
  • 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.
  • 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.
  • the software verification support apparatus 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.
  • unnecessary conditional branch instructions can be deleted from the source code, so that the program size can be reduced while ensuring the 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.
  • 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
  • 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.
  • Diagnostic terminal 330 is a terminal for diagnosing control unit 200 via 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 device 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 unit 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 a 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.
  • a CPU Central Processing 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.
  • 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.
  • 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.
  • FIG. 3 shows 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.
  • an array of the size LINETH is secured in the part included in the conditional branch instruction 1711, and the elements from the first element of this array to the number specified by the parameter iParam are initialized.
  • 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.
  • the conditional branch instruction 1711 excludes iParam having a value greater than or equal to LINETH.
  • this source code 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.
  • the value of the parameter iParam may be determined at the time of execution.
  • 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.
  • 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.
  • unnecessary instructions such as error processing included in the instruction 1712 when the condition is not satisfied are also deleted.
  • 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.
  • the conditional branch instruction 1711 is 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.
  • source code includes multiple 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”.
  • conditional branch instruction 1711 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.
  • an assert instruction that is 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.
  • 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 an inspection instruction is inserted into the source code of FIG.
  • a check instruction 1717 is newly inserted immediately before the conditional branch instruction 1711.
  • 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).
  • 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.
  • the conditional expression pattern 1720 can be described using a regular expression.
  • 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.
  • the test instruction generating unit 120 can extract the 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.
  • 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 command pattern 1730 includes a line number portion 1731, an insertion location instruction portion 1732, an inspection command fixing portion 1733, and a conditional expression portion 1734.
  • the line number part 1731 specifies the line number in the source code where 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 showing an example of source code after the software inspection support apparatus 100 deletes the conditional branch instruction.
  • a conditional branch instruction 1711 a condition unsatisfied instruction 1712, a conditional branch end instruction 1713, a conditional branch instruction identification comment 1714, a condition non-satisfied instruction identification comment 1715, and a 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.
  • FIG. 8 is a diagram illustrating an operation flow of processing in which the software inspection support apparatus 100 generates an inspection instruction.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S905 Supplement
  • 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.
  • 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.
  • 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.
  • 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.
  • the software verification support apparatus 100 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.
  • 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.
  • the processing load can be reduced and the real-time performance of the control processing can be improved.
  • the software verification support apparatus 100 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.
  • the inspection execution unit 140 compiles and executes the source code in which the inspection instruction is embedded.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • CBMC see Edmund Clarke, ANSI-C Bounded Model Checker User Manual, 2006
  • This tool is software that comprehensively verifies whether or not the conditions described in the software source code are satisfied.
  • the inspection execution unit 140 waits for a predetermined time while executing the inspection.
  • 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.
  • 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.
  • 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. .
  • 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.
  • 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.
  • 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.
  • the software inspection support apparatus 100 leaves the source code after that 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.
  • 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 be realized as software.
  • Information such as a program and a table 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: diagnosis End, 340: controller, 350: communication line.

Abstract

高い安全性と再利用性を備え、プログラムサイズを抑えることのできるソフトウェアを得るためのソフトウェア検証支援技術を得ることを目的とする。 本発明に係るソフトウェア検証支援装置は、条件分岐命令が記述している条件が必ず成立する場合は、条件が成立したときに実行される命令をソースコード内に残した上で、条件が成立しなかったときに実行される命令をソースコードから削除する。

Description

ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム
　本発明は、ソフトウェアのソースコードを検証する作業を支援する技術に関する。
　自動車などの制御装置は、マイクロコントローラ（以下マイコンと表記）を用いて制御動作を実行する。マイコンに搭載されるソフトウェアは、一般的には制御処理を実施するアプリケーションプログラムとデータ入出力を実施するデバイスドライバやオペレーティングシステム（ＯＳ）などによって構成されている。車両制御装置は、車両乗員の安全性に直接関わる制御を実施するため、高い安全性を要求されている。そのため、制御装置の故障診断を実施し、故障が検出された場合には制御装置を安全な状態へ遷移させる、フェールセーフ処理が用いられている。
　また、近年制御の高度化と規模の増大にともない、車両の安全に関わる入出力装置の数が増大し、その診断ソフトウェアの開発工数が課題となっている。
　車両制御に用いるソフトウェアは、多くの製品バリエーションに対応するため、複数の製品に亘って再利用することができるように構成されており、これによりソフトウェアの開発効率を高めている。
　例えば、ソフトウェアが搭載される環境に依拠して処理内容が異なる部分については、モジュールとして切り離しておき、環境に依拠せず共通する部分を再利用することができるように構成する。また、環境に依拠する部分を切り離したモジュールについても、実行時に引き渡すパラメータを変えることによって各環境に対応した処理を実行することができるように構成し、再利用性を高めている。
　上記のようにパラメータによって動作を変えるソフトウェアモジュールは、環境に応じて様々なパラメータを受け取る場合があるため、当該モジュールが想定していないパラメータを受け取る可能性がある。この場合、想定外のパラメータによって当該モジュールが想定外の動作を引き起こさないようにするため、受け取ったパラメータに関連する動作を実行する前に、そのパラメータが適正であるか否かを判定する必要がある。
　このようなパラメータの事前検証を実施するためのソフトウェア設計手法として、「防御的プログラミング」と呼ばれる手法がある。防御的プログラミングとは、当該モジュールが想定外の動作条件で呼び出されるかもしれない、との考えに立ち、モジュールが目的とする機能を実施する前に動作条件をチェックし、条件に合致しない場合にはエラー処理などの例外処理を実施する設計手法である。
　下記特許文献１には、エンジン制御用ソフトウェアの動作検証に関する技術として、ソースコードにアサーション命令を挿入することにより、ソフトウェアの動作を検証する技術が記載されている。
特開２００８－２７６５５６号公報
スティーブ・マコネル著，コードコンプリート第２版， 日経ＢＰソフトプレス，２００５年
　車両制御のようにリアルタイム制御を実施する必要があるソフトウェアは、安全の観点から制御処理の内容が正しいことが要求されるのはもちろんであるが、その制御処理が適正なタイミングで実施されることも同時に求められる。そのため、数マイクロ秒程度の僅かな処理遅延も許されない場合も多い。
　一方、上述の防御的プログラミングを採用したソフトウェアモジュールは、想定外のパラメータを用いて呼び出された場合にも想定外の動作をしないように、条件分岐命令を用いてパラメータが所定の条件に合致しているか否かを判定し、条件に合致する場合のみ処理を実行するように構成される。そのため、条件分岐命令に係る条件判定、条件に合致しないときの処理等を記述する必要があり、ソースコードの量が増大する傾向がある。その結果、プログラム容量の増大と実行速度の低下を招きやすい。
　本発明は、上記のような課題を解決するためになされたものであり、高い安全性と再利用性を備え、プログラムサイズを抑えることのできるソフトウェアを得るためのソフトウェア検証支援技術を得ることを目的とする。
　本発明に係るソフトウェア検証支援装置は、条件分岐命令が記述している条件が必ず成立する場合は、条件が成立したときに実行される命令をソースコード内に残した上で、条件が成立しなかったときに実行される命令をソースコードから削除する。
　本発明に係るソフトウェア検証支援装置によれば、不要な条件分岐命令をソースコードから削除することができるので、元のソースコードの再利用性を確保しつつプログラムサイズを抑えることができる。また、必ず成立する条件分岐命令を削除するので、想定外のパラメータが条件分岐命令に引き渡されて不測の結果を生じることはなく、安全性を確保することができる。
本発明に係るソフトウェア検証支援装置が対象とするソフトウェアを搭載する自動車エンジン制御システムの構成例を示す図である。 本発明に係るソフトウェア検証支援装置１００の構成を示す図である。 ソフトウェア検証支援装置１００が検証対象とするソースコードの例である。 図３のソースコードに検査命令を挿入した例を示す図である。 検査命令生成部１２０が条件分岐命令１７１１から条件式部分を抽出する際に用いる条件式パターン１７２０の例を示す図である。 検査命令生成部１２０が生成する検査命令のパターンを示す図である。 ソフトウェア検査支援装置１００が条件分岐命令を削除した後のソースコード例を示す図である。 ソフトウェア検査支援装置１００が検査命令を生成する処理の動作フローを示す図である。 ソフトウェア検査支援装置１００がソースコードから条件分岐命令を削除する処理の動作フローを示す図である。 実施形態２において検査実行部１４０が検査対象のソースコードをコンパイルして実行する際の動作フローである。
＜実施の形態１＞
　図１は、本発明に係るソフトウェア検証支援装置が対象とするソフトウェアを搭載する自動車エンジン制御システムの構成例を示す図である。コントロールユニット２００は、エンジンの動作を制御する制御ソフトウェアを実行する装置であり、マイクロコントローラ２１０、駆動回路２２０、通信回路２３０、信号入出力回路２４０を備える。
　信号入出力回路２４０は、加速度センサ３１１とヨーレートセンサ３１２からそれぞれ検出結果を取得し、マイクロコントローラ２１０に出力する。駆動回路２２０は、マイクロコントローラ２１０からの指示にしたがってアクチュエータ３２０を駆動制御し、これによりエンジンの動作を制御する。通信回路２３０は、通信線３５０を介して診断端末３３０および制御装置３４０と通信する。
　診断端末３３０は、通信線３５０を介してコントロールユニット２００を診断するための端末である。制御装置３４０は、コントロールユニット２００とは別の制御処理を実施する装置である。
　マイクロコントローラ２１０は、入力回路２１１、演算装置２１２、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２１３、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）２１４、出力回路２１５、通信制御装置２１６を備える。
　入力回路２１１は、信号入出力回路２４０から各センサの検出結果を受け取り、演算装置２１２に出力する。演算装置２１２は、制御処理を記述した制御ソフトウェアを実行する。ＲＡＭ２１３は、演算装置２１２が制御ソフトウェアを実行する際に一時的に使用するデータなどを格納する。ＲＯＭ２１４は、演算装置２１２が実行する制御ソフトウェアを格納している。出力回路２１５は、駆動回路２２０に対して制御信号を出力する。通信制御装置２１６は、通信回路２３０を介して外部と通信する。
　上述の加速度センサ３１１、ヨーレートセンサ３１２は、コントロールユニット２００に接続されるセンサの１例でありその他のセンサ、例えば温度、電流、その他の物理量を検知するセンサの検出結果を用いて車両を制御するコントロールユニットについても、本発明に係るソフトウェア検証支援装置が対象とするソフトウェアを実行することができることはいうまでもない。
　図２は、本発明に係るソフトウェア検証支援装置１００の構成を示す図である。ソフトウェア検証支援装置１００は、制御部１１０、検査命令生成部１２０、検査命令挿入部１３０、検査実行部１４０、検査結果取得部１５０、条件分岐削除部１６０、記憶部１７０を備える。
　制御部１１０は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などの演算装置で構成され、各機能部を制御する。
　検査命令生成部１２０は、ソフトウェアソースコード内の条件分岐命令（典型的には、ｉｆ－ｅｌｓｅ文）が必ず成立するか否かを検査するための検査命令を生成する。例えば後述するａｓｓｅｒｔ命令を、検査命令として用いることができる。検査命令挿入部１３０は、ソースコード内の条件分岐命令の直前または直後に、検査命令生成部１２０が生成した検査命令を挿入する。
　検査実行部１４０は、検査命令を挿入したソースコードをコンパイルして実行し、その結果を記憶部１７０に格納する。検査命令は、検査実行部１４０が実行すると、条件分岐命令内の条件式が成立するか否かを示すログを記憶部１７０に格納するように構成されている。したがって、検査実行部１４０が検査命令を含むソースコードをコンパイルして実行すると、条件分岐命令内の条件式が成立するか否かを示すログが記憶部１７０に格納される。
　検査結果取得部１５０は、検査実行部１４０の実行結果を記憶部１７０から取得し、上述のログにしたがって、条件分岐命令内の条件式が必ず成立するか否かを判定する。
　条件分岐削除部１６０は、条件分岐命令内の条件式が必ず成立する場合は、条件が成立したときに実行される命令（ｉｆ文内に含まれる命令）をソースコード内に残した上で、条件が成立しなかったときに実行される命令（ｅｌｓｅ文に含まれる命令）をソースコードから削除する。条件分岐命令内の条件式が必ずしも成立しない場合は、上記いずれもソースコード内に残す。
　記憶部１７０は、ソースコード記憶部１７１、条件式パターン記憶部１７２、検査命令記憶部１７３、検査対象ソースコード記憶部１７４、検査結果記憶部１７５、資源制約条件記憶部１７６を備える。
　ソースコード記憶部１７１は、ソフトウェア検査支援装置１００が検査対象とするソースコードを記憶する。条件式パターン記憶部１７２は、検査命令生成部１２０が検査命令を生成する際に、条件分岐命令から条件式部分を抽出するために用いる抽出パターンを記憶する。詳細は後述する。検査命令記憶部１７３は、検査命令生成部１２０が生成した検査命令を記憶する。検査対象ソースコード記憶部１７４は、検査命令挿入部１３０が検査命令を挿入したソースコードを記憶する。検査結果記憶部１７５は、検査実行部１４０が検査命令を挿入したソースコードをコンパイルして実行した結果を記憶する。資源制約条件記憶部１７６は、検査実行部１４０がソースコードをコンパイルして実行する際に必要となるハードウェアリソースなどの制約条件を記述したデータを記憶する。
　以上、ソフトウェア検証支援装置１００の構成について説明した。次に、ソースコードに検査命令を挿入する処理について、ソースコードの例とともに説明する。
　図３は、ソフトウェア検証支援装置１００が検証対象とするソースコードの例である。本ソースコードには、条件分岐命令（ｉｆ｛）１７１１、条件不成立時命令（ｅｌｓｅ｛）１７１２、条件分岐終了命令（｝）１７１３が含まれている。
　本ソースコードでは、条件分岐命令１７１１に含まれる部分において、サイズＬＩＮＩＴＨの配列を確保し、この配列の最初の要素からパラメータｉＰａｒａｍが指定する番号の要素までを初期化している。これらの処理は、配列を初期化すべきサイズがソフトウェアを実行する環境によって異なるため、これをパラメータｉＰａｒａｍとして汎用化し、任意サイズの配列を初期化することができるように構成して、環境に依拠しない再利用可能なモジュールとすることを図ったものである。
　これらの処理においては、パラメータｉＰａｒａｍが配列サイズＬＩＮＩＴＨ未満であることを前提としているため、条件分岐命令１７１１によって、ＬＩＮＩＴＨ以上の値を有するｉＰａｒａｍを排除している。すなわち、本ソースコードが作成された時点では、いかなる環境を対象として本ソースコードが用いられるか確定していないため、ソフトウェアの動作を不安定にしないように、不確定なパラメータをあらかじめチェックするようにしたものである。これにより、本ソースコードの再利用性を確保しつつ、動作の安全性を確保することができる。このような手法を、前述の防御的プログラミングと呼ぶ。
　一方、本ソースコードを利用する環境が確定した以降は、パラメータｉＰａｒａｍの値が実行時にとり得る値も確定している場合がある。このような場合には、条件分岐命令１７１１、条件不成立時命令１７１２、条件分岐終了命令１７１３は冗長な記載となり、却ってソフトウェア容量を不要に増大させる原因となる。
　そこで本発明では、図３に例示するような条件分岐命令のうち、条件式が必ず成立するものについては、条件分岐命令１７１１、条件不成立時命令１７１２、および条件分岐終了命令１７１３をソースコードから削除し、さらには条件不成立時命令１７１２内に含まれるエラー処理などの不要な命令も併せて削除することとした。
　具体的には、ソフトウェア検証支援装置１００は、本ソースコードを利用する環境に固有のパラメータを組み込んだ上で、本ソースコードをコンパイルして実際に実行し、条件分岐命令１７１１が記述している条件式が実際に成立するか否かを検証する。以下、そのための具体的な手法を説明する。
　なお、本ソースコードを利用する環境に固有のパラメータは、例えばＣ言語のヘッダファイルなどのデータファイルに記述することもできるし、環境固有のパラメータを一括して記述したソースコードを本ソースコードとともにコンパイルして実行モジュール内に組み込むことによって本ソースコード内に取り込むこともできる。
　一般にソースコードには、条件分岐命令が複数含まれている。必ずしも全ての条件分岐命令が、上述のような冗長命令であるわけではないので、ソースコードが利用される環境に依拠して変わる可能性がある条件式を記述した部分のみ、削除するか否かを判定すればよい。そこで図３に示すソースコードには、削除するか否かを判定する対象とする条件分岐命令を識別するため、ソースコードの内容に影響しないコメント文として、条件分岐命令識別コメント１７１４、条件不成立時命令識別コメント１７１５、条件分岐終了命令識別コメント１７１６が付与されている。
　条件分岐命令識別コメント１７１４、条件不成立時命令識別コメント１７１５、条件分岐終了命令識別コメント１７１６はそれぞれ、条件分岐命令１７１１、条件不成立時命令１７１２、および条件分岐終了命令１７１３が記述されている箇所をソフトウェア検証支援装置１００が識別するためのものである。コメント文の形式は任意でよいが、図３では例として、「＠ＣＣ＿ｉｆ＿識別番号」「＠ＣＣ＿ｅｌｓｅ＿識別番号」「＠ＣＣ＿ｅｎｄｉｆ＿識別番号」という形式でコメントを付与した。
　条件分岐命令１７１１が記述している条件式が実際に成立するか否かを検証するためには、ソースコードをコンパイルして実行することに加えて、条件式が成立した際にその旨を何らかのログとして記録することが望ましい。例えば、条件分岐命令１７１１内に、適当なログを記録する命令を新たに挿入することが考えられる。条件分岐命令１７１１内の命令は、その条件式が成立した場合に限って実行されるので、条件分岐命令１７１１内にログ記録命令を挿入しておけば、その命令が実行されたということは条件式が成立したということと等価だからである。
　本実施形態１では、これと同様の機能を備えた関数として、ソフトウェアの動作検証においてよく用いられるａｓｓｅｒｔ命令を用いる。ａｓｓｅｒｔ命令は、指定した条件式が成立したときはｔｒｕｅを返し、成立しなかったときはｆａｌｓｅを返す、またはこれと同様の動作をする関数である。本実施形態１では、次の図４に示す＿ＣＰＲＯＶＥＲ＿ａｓｓｅｒｔという検査命令を用いることとする。これは、指定した条件式が成立したか否かを示すログを、検査結果記憶部１７５に格納するように構成された命令である。
　図４は、図３のソースコードに検査命令を挿入した例を示す図である。図４において、条件分岐命令１７１１の直前に、検査命令１７１７が新たに挿入されている。
　検査命令挿入部１３０は、条件分岐命令識別コメント１７１４をソースコード内に見つけると、対応する条件分岐命令１７１１が必ず成立するか否かを検証するための検査命令１７１７を、条件分岐命令１７１１の直前（または直後）に挿入する。
　検査命令１７１７は、条件分岐命令１７１１が成立するか否かを検証するためのものであるため、検査命令１７１７が指定する条件式は条件分岐命令１７１１内の条件式と同一である必要がある。検査命令生成部１２０は、条件分岐命令１７１１から条件式部分を抽出し、これを条件式として指定した検査命令１７１７を生成する。
　図５は、検査命令生成部１２０が条件分岐命令１７１１から条件式部分を抽出する際に用いる条件式パターン１７２０の例を示す図である。条件式パターンとは、プログラムコード内において条件式が開始または終了する旨を指定する文字列と、条件式そのものを記述した文字列とを抽出するための文字列テンプレートであり、条件式パターン記憶部１７２内にデータとして記憶されている。例えば正規表現を用いて条件式パターン１７２０を記述することができるが、これに限られるものではなく、指定した文字列表現に合致する文字列を抽出することができればよい。図５では、正規表現を用いて条件式パターン１７２０を構成した例を示した。
　図５に示す条件式パターン１７２０は、条件式が開始または終了する旨を指定する文字列を抽出するための定型パターン１７２１と、定型パターン１７２１の間に記述されている任意の文字列を抽出するための任意パターン１７２２とを有する。検査命令生成部１２０は、条件式パターン１７２０を用いて、ｉｆ文内に記述されている条件式（図３～図４の例では、ｉＰａｒａｍ＜ＬＩＮＩＴＨ）を抽出することができる。
　なお、条件式パターン１７２０は、複数の抽出パターンを記述することもできる。検査命令生成部１２０は、いずれかの抽出パターンに合致する文字列を発見したときはその条件式を用いて検査命令１７１７を生成し、全ての抽出パターンに合致しない条件分岐命令については空の条件を指定して検査命令１７１７を生成する。
　図６は、検査命令生成部１２０が生成する検査命令のパターンを示す図である。検査命令生成部１２０は、図６に示す検査命令パターン１７３０に準じて検査命令を生成し、検査命令記憶部１７３に格納する。検査命令挿入部１３０は、検査命令記憶部１７３が格納している検査命令を読み出し、ソースコードに挿入する。
　検査命令パターン１７３０は、行番号部１７３１、挿入箇所指示部１７３２、検査命令固定部１７３３、条件式部１７３４を有する。
　行番号部１７３１は、検査命令を挿入すべきソースコード内の行番号を指定する。挿入箇所指示部１７３２は、行番号部１７３１が指定する行の直前に検査命令を挿入するか、直後に挿入するかを指定する。検査命令固定部１７３３は、検査命令を記述した文字列のうち、条件式を除いた固定部分である。条件式部１７３４は、検査命令生成部１２０が条件式パターン１７２０を用いて条件分岐命令から抽出する条件式を埋め込む部分である。
　図７は、ソフトウェア検査支援装置１００が条件分岐命令を削除した後のソースコード例を示す図である。図３～図４で例示したソースコードのうち、条件分岐命令１７１１、条件不成立時命令１７１２、条件分岐終了命令１７１３、条件分岐命令識別コメント１７１４、条件不成立時命令識別コメント１７１５、条件分岐終了命令識別コメント１７１６、検査命令１７１７がソースコードから削除され、さらには条件不成立時命令１７１２内に含まれるエラー処理などの不要な命令も併せて削除されている。この結果、削除した部分に対応するオブジェクトコードは生成されないので、プログラム容量およびプログラム実行負荷を低減することができる。
　以上、ソフトウェア検査支援装置１００がソースコードから条件分岐命令を削除する際の基本的な考え方について説明した。以下では、ソフトウェア検査支援装置１００の具体的な動作手順を説明する。
　図８は、ソフトウェア検査支援装置１００が検査命令を生成する処理の動作フローを示す図である。以下、図８の各ステップについて説明する。
（図８：ステップＳ８００）
　ソフトウェア検査支援装置１００は、検査対象であるソースコードをコンパイルして実行する前に、本動作フローを実行して検査命令を生成する。
（図８：ステップＳ８０１）
　検査命令生成部１２０は、ソースコード記憶部１７１から検査対象であるソースコードを１行分読み出す。また、図６で説明した行番号部１７３１の値を１加算して更新する。
（図８：ステップＳ８０２）
　検査命令生成部１２０は、ステップＳ８０１で読み込んだ１行分のソースコード内に、条件分岐命令識別コメント１７１４（＠ＣＣ＿ｉｆ＿識別番号）が含まれているか否かを判定する。含まれている場合はステップＳ８０３へ進み、含まれていない場合はステップＳ８０５へスキップする。
（図８：ステップＳ８０３）
　検査命令生成部１２０は、条件分岐命令に含まれる条件式を、図５で説明した条件式パターンにしたがって抽出する。
（図８：ステップＳ８０４）
　検査命令生成部１２０は、ステップＳ８０３で抽出した条件式と、図６で説明した検査命令パターンにしたがって、検査命令を生成し、検査命令記憶部１７３に格納する。行番号部１７３１には、ステップＳ８０１で更新した行番号を用いる。挿入箇所指示部１７３２の値は、例えばあらかじめ指定しておけばよい。また、条件分岐命令識別コメント１７１４に含まれている識別番号を記憶しておき、検査命令の実行結果を検査結果記憶部１７５に格納する際に、併せて格納する。
（図８：ステップＳ８０５）
　ステップＳ８０１で読み込んだソースコードの終端に達している場合はステップＳ８０６へ進み、読み込んでいない行が残っている場合はステップＳ８０１に戻って同様の処理を繰り返す。
（図８：ステップＳ８０６）
　本動作フローが終了した後、検査命令挿入部１３０は、検査命令生成部１２０が生成して検査命令記憶部１７３に格納した検査命令を、行番号部１７３１が指定する行の直前または直後に挿入し、検査対象ソースコード記憶部１７４に格納する。検査実行部１４０は、検査命令が挿入されたソースコードをコンパイルして実行し、検査命令の実行結果を検査結果記憶部１７５に格納する。また、必要に応じて資源制約条件記憶部１７６からハードウェアリソースに関する制約条件を取得し、これを満たす範囲内で検査を実施する。
　図９は、ソフトウェア検査支援装置１００がソースコードから条件分岐命令を削除する処理の動作フローを示す図である。以下、図９の各ステップについて説明する。
（図９：ステップＳ９００）
　ソフトウェア検査支援装置１００は、検査対象であるソースコードをコンパイルして実行した後に本動作フローを実行し、条件分岐命令をソースコードから削除する。
（図９：ステップＳ９０１）
　検査結果取得部１５０は、検査結果記憶部１７５から検査命令の実行結果を取得する。検査命令の実行結果は、ソースコード内に複数存在する検査命令それぞれの条件式が成立したか否か、および検査命令の識別番号（条件分岐命令識別コメント１７１４に含まれている識別番号）を含む。検査結果取得部１５０は、各検査命令を識別番号によって区別した上で、それぞれの検査結果をリストアップする。
（図９：ステップＳ９０２）
　条件分岐削除部１６０は、検査命令を挿入したソースコードを、検査対象ソースコード記憶部１７４から１行ずつ読み出す。
（図９：ステップＳ９０３）
　条件分岐削除部１６０は、ステップＳ９０２で読み込んだ１行分のソースコード内に、条件分岐命令識別コメント１７１４が含まれているか否かを判定する。含まれている場合はステップＳ９０４に進み、含まれていない場合はステップＳ９１１へ進む。
（図９：ステップＳ９０４）
　条件分岐削除部１６０は、条件分岐命令識別コメント１７１４に含まれている識別番号をキーにして、検査結果記憶部１７５から当該条件分岐命令に対応する検査命令の検査結果を取得する。
（図９：ステップＳ９０５）
　ステップＳ９０４で取得した検査結果が検査成功である場合はステップＳ９０６へ進み、検査失敗である場合はステップＳ９１１へ進む。
（図９：ステップＳ９０５：補足）
　本ステップにおける検査結果が検査成功である場合は、対応する条件分岐命令内の条件文が成立していることを示しているので、ステップＳ９０６以降のステップに進んで冗長な命令文を削除する。本ステップにおける検査結果が失敗である場合は、ステップＳ９０２で読み込んだ条件分岐命令内の条件文が必ずしも成立するとは限らないことを示しているので、ステップＳ９１１に進んでその条件分岐命令はソースコード内に残す。
（図９：ステップＳ９０６）
　条件分岐削除部１６０は、直前に読み込んだソースコード行の次行を、検査対象ソースコード記憶部１７４から読み出す。
（図９：ステップＳ９０７）
　条件分岐削除部１６０は、ステップＳ９０６で読み込んだ１行分のソースコード内に、条件不成立時命令識別コメント１７１５が含まれているか否かを判定する。含まれている場合はステップＳ９０９に進み、含まれていない場合はステップＳ９０８へ進む。
（図９：ステップＳ９０８）
　条件分岐削除部１６０は、ステップＳ９０６で読み込んだ１行分のソースコードを、そのまま検査対象ソースコード記憶部１７４に書き戻す。本ステップの後はステップＳ９０６に戻り、同様の処理を繰り返す。
（図９：ステップＳ９０９）
　条件分岐削除部１６０は、直前に読み込んだソースコード行の次行を、検査対象ソースコード記憶部１７４から読み出す。
（図９：ステップＳ９１０）
　条件分岐削除部１６０は、ステップＳ９０９で読み込んだ１行分のソースコード内に、条件分岐終了命令識別コメント１７１６が含まれているか否かを判定する。含まれていない場合はステップＳ９０９へ戻って同様の処理を繰り返す。含まれている場合はステップＳ９０２に戻って同様の処理を繰り返す。
（図９：ステップＳ９１１）
　条件分岐削除部１６０は、ステップＳ９０２で読み込んだ１行分のソースコードを、そのまま検査対象ソースコード記憶部１７４に書き戻す。
（図８：ステップＳ９１２）
　ソースコードの終端に達している場合は本動作フローを終了し、読み込んでいない行が残っている場合はステップＳ９０２に戻って同様の処理を繰り返す。
＜実施の形態１：まとめ＞
　以上のように、本実施形態１に係るソフトウェア検証支援装置１００は、検査命令を挿入したソースコードをコンパイルして実行し、条件分岐命令内の条件式が必ず成立することが判明した場合は、冗長な条件分岐命令などをソースコード内から削除する。これにより、不要な条件分岐命令、条件不成立時命令、条件分岐終了命令、および条件不成立時命令内に含まれる命令を除去し、コンパイル後のプログラム容量を抑えることができる。また、冗長な命令を削除することにより、処理負荷を軽減して制御処理のリアルタイム性を高めることができる。
　また、本実施形態１に係るソフトウェア検証支援装置１００は、検査命令を挿入したソースコードをコンパイルして実行する際に、ソースコードが利用される環境に固有のパラメータを記述したデータファイルを取り込み、検証対象であるソースコードと組み合わせて実行する。これにより、検査対象のソースコードが利用される環境を模擬し、条件分岐命令内の条件式が当該環境下で確実に成立するか否かを、シミュレーション環境下で検証することができる。
＜実施の形態２＞
　実施の形態１では、検査実行部１４０が検査命令を埋め込んだソースコードをコンパイルして実行することを説明した。一般に、ソースコードをコンパイルして実際に実行することによりソースコードの挙動を検査する処理は、ＣＰＵ負荷やメモリ使用量などのハードウェアリソースを多大に消費するため、ハードウェアリソースに関する何らかの制約条件が課される場合がある。本発明の実施形態２では、その具体例を説明する。検査実行部１４０の動作以外については実施形態１と概ね同様であるため、以下では差異点を中心に説明する。
　図１０は、本実施形態２において検査実行部１４０が検査対象のソースコードをコンパイルして実行する際の動作フローである。以下、図１０の各ステップについて説明する。
（図１０：ステップＳ１０００）
　検査実行部１４０は、図８のステップＳ８０６において、本動作フローを開始する。
（図１０：ステップＳ１００１～Ｓ１００２）
　検査実行部１４０は、検査対象ソースコード記憶部１７４から検査対象のソースコードを読み出す（Ｓ１００１）。また、資源制約条件記憶部１７６からハードウェアリソースに関する制約条件を取得する（Ｓ１００２）。
（図１０：ステップＳ１００２：補足）
　本実施形態２において、資源制約条件記憶部１７６が記憶しているハードウェアリソースに関する制約条件は、使用メモリ量の最大値と、検査開始からの最大経過時間である。
（図１０：ステップＳ１００３）
　検査実行部１４０は、ステップＳ１００１で読み出した検査対象ソースコードをコンパイルし、実行開始する。本ステップの処理は、一般的なソフトウェア検証ツールを用いて実行することができる。例えば、ＣＢＭＣ（Ｅｄｍｕｎｄ　Ｃｌａｒｋｅ著，ＡＮＳＩ－Ｃ　Ｂｏｕｎｄｅｄ　Ｍｏｄｅｌ　Ｃｈｅｃｋｅｒ　Ｕｓｅｒ　Ｍａｎｕａｌ，２００６年を参照）などのツールを用いることができる。同ツールは、ソフトウェアソースコード内に記載された条件が満たされているか否かを網羅的に検証するソフトウェアである。
（図１０：ステップＳ１００４）
　検査実行部１４０は、検査を実行しながら所定時間待機する。
（図１０：ステップＳ１００５）
　検査実行部１４０は、現在のメモリ使用量を取得する。メモリ使用量を取得する具体的な方法としては、検査プログラムが動作している計算機のオペレーティングシステムのシステムコールなどを用いればよい。取得したメモリ使用量が資源制約条件記憶部１７６によって規定されている最大使用量を超えている場合はステップＳ１００７へ進み、超えていない場合はステップＳ１００６へ進む。
（図１０：ステップＳ１００６）
　検査実行部１４０は、現在時刻を取得し、検査を開始してからの経過時間を算出する。
（図１０：ステップＳ１００７）
　検査実行部１４０は、ステップＳ１００３で開始した検査を中断し、使用メモリ量超過エラー処理を実行する。例えば、検査を中断した時点で実行していたソースコードの行番号を、検査結果記憶部１７５に格納する。
（図１０：ステップＳ１００８）
　検査実行部１４０は、検査を開始してからの経過時間が資源制約条件記憶部１７６によって規定されている最大経過時間を超えている場合はステップＳ１０１０へ進み、超えていない場合はステップＳ１００９へ進む。
（図１０：ステップＳ１００９）
　検査実行部１４０は、ステップＳ１００３で開始した検査が終了している場合は本動作フローを終了し、検査途中である場合はステップＳ１００４に戻って同様の処理を繰り返す。
（図１０：ステップＳ１０１０）
　検査実行部１４０は、ステップＳ１００３で開始した検査を中断し、経過時間超過エラー処理を実行する。例えば、検査を中断した時点で実行していたソースコードの行番号を、検査結果記憶部１７５に格納する。
（図１０：ステップＳ１０１１）
　本動作フローが終了した後、ソフトウェア検査支援装置１００は、図９で説明した動作フローを実行する。ステップＳ１００７またはＳ１０１０においてそれぞれの超過処理を実行した旨の検査結果が記録されている場合は、検査を中断した以降のソースコード部分については無条件に残すこととする。条件式が成立するか否かを検証できていないからである。
＜実施の形態２：まとめ＞
　以上のように、本実施形態２に係るソフトウェア検査支援装置１００は、検査実行部１４０がソースコードをコンパイルして実行するために必要なハードウェアリソース量が所定の制約条件を超過したときは、検査を中断してその旨を記録する。これにより、ハードウェア能力不足のため検査がいつまでも終了しないような事態を避けることができる。
　また、本実施形態２に係るソフトウェア検査支援装置１００は、検査実行部１４０が検査を途中で中断したときは、それ以降のソースコードを無条件に残す。これにより、冗長であることが確実に判明している条件分岐命令等のみをソースコードから削除することができる。
　以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
　また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ＩＣカード、ＤＶＤなどの記憶媒体に格納することができる。
　１００：ソフトウェア検証支援装置、１１０：制御部、１２０：検査命令生成部、１３０：検査命令挿入部、１４０：検査実行部、１５０：検査結果取得部、１６０：条件分岐削除部、１７０：記憶部、１７１：ソースコード記憶部、１７２：条件式パターン記憶部、１７３：検査命令記憶部、１７４：検査対象ソースコード記憶部、１７５：検査結果記憶部、１７６：資源制約条件記憶部、２００：コントロールユニット、２１０：マイクロコントローラ、２１１：入力回路、２１２：演算装置、２１３：ＲＡＭ、２１４：ＲＯＭ、２１５：出力回路、２１６：通信制御装置、２２０：駆動回路、２３０：通信回路、２４０：信号入出力回路、３１１：加速度センサ、３１２：ヨーレートセンサ、３２０：アクチュエータ、３３０：診断端末、３４０：制御装置、３５０：通信線。

Claims (10)

  1. 　ソフトウェアのソースコードを検証する作業を支援する装置であって、
    　前記ソースコードをコンパイルして実行した結果を取得する検査部、
    　前記ソースコード内の条件分岐命令が記述している条件が必ず成立するか否かを前記結果にしたがって判定する検査結果取得部、
    　前記条件が必ず成立する場合は、前記条件が成立したときに実行される命令を前記ソースコード内に残した上で、前記条件が成立しなかったときに実行される命令を前記ソースコードから削除する条件分岐削除部、
    　を備えることを特徴とするソフトウェア検証支援装置。
  2. 　前記検査部は、
    　　前記条件分岐命令が記述している条件を指定するパラメータのうち、前記ソフトウェアが搭載される環境に固有のものを記述したパラメータデータを、前記ソースコードに組み込んだ上でコンパイルして実行した結果を取得し、
    　前記検査結果取得部は、
    　　前記パラメータデータを組み込んだ前記ソースコードの実行結果を取得することにより、前記環境において前記条件が必ず成立するか否かを判定する
    　ことを特徴とする請求項１記載のソフトウェア検証支援装置。
  3. 　前記条件分岐命令が必ず成立するか否かを検査するための検査命令を前記ソースコード内の前記条件分岐命令の直前または直後に挿入する検査命令挿入部と、
    　前記ソースコードをコンパイルして実行した結果を記述したログを記憶する記憶部と、　を備え、
    　前記検査命令は、
    　　前記検査部が前記検査命令を実行したとき、前記条件分岐命令が成立したか否かを示すログを前記記憶部に格納するように構成されており、
    　前記検査命令挿入部は、
    　　前記検査部が前記ソースコードをコンパイルして実行前に、前記検査命令を前記ソースコード内に挿入し、
    　前記検査結果取得部は、
    　　前記記憶部に格納されている前記検査命令のログに基づき、前記条件が必ず成立するか否かを判定する
    　ことを特徴とする請求項１記載のソフトウェア検証支援装置。
  4. 　前記検査命令挿入部は、
    　　前記検査命令を挿入すべき条件分岐命令が記述されている箇所を示す前記ソースコード内のコメント文にしたがって、前記検査命令を挿入する
    　ことを特徴とする請求項３記載のソフトウェア検証支援装置。
  5. 　前記検査部は、
    　　前記ソースコードをコンパイルして実行するために必要なハードウェアリソース量が所定の上限値を超えたときは前記実行を中断し、
    　前記検査結果取得部は、
    　　前記条件分岐命令のうち前記中断時点で既に実行されたもの以外については、前記条件が必ず成立するか否か不確定であるものと判定し、
    　前記条件分岐削除部は、
    　　前記条件が必ず成立するか否か不確定である前記条件分岐命令、その条件が成立したときに実行される命令、およびその条件が成立しなかったときに実行される命令については、前記ソースコードから削除せずに残したままにする
    　ことを特徴とする請求項１記載のソフトウェア検証支援装置。
  6. 　前記検査部は、
    　　前記ソースコードをコンパイルして実行する際に消費するメモリ容量が所定の上限値を超えたときは前記実行を中断する
    　ことを特徴とする請求項５記載のソフトウェア検証支援装置。
  7. 　前記検査部は、
    　　前記ソースコードをコンパイルして実行することを開始してからの経過時間が所定の上限値を超えたときは前記実行を中断する
    　ことを特徴とする請求項５記載のソフトウェア検証支援装置。
  8. 　前記検査部は、
    　　前記実行を中断したときはその時点で実行しようとしていた前記ソースコードの行番号を前記記憶部に格納する
    　ことを特徴とする請求項５記載のソフトウェア検証支援装置。
  9. 　ソフトウェアのソースコードを検証する作業を支援する方法であって、
    　前記ソースコードをコンパイルして実行した結果を取得するステップ、
    　前記ソースコード内の条件分岐命令が記述している条件が必ず成立するか否かを前記結果にしたがって判定するステップ、
    　前記条件が必ず成立する場合は、前記条件が成立したときに実行される命令を前記ソースコード内に残した上で、前記条件が成立しなかったときに実行される命令を前記ソースコードから削除するステップ、
    　を有することを特徴とするソフトウェア検証支援方法。
  10. 　請求項９記載のソフトウェア検証支援方法をコンピュータに実行させることを特徴とするソフトウェア検証支援プログラム。
PCT/JP2013/050503 2012-01-20 2013-01-15 ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム WO2013108730A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012010333A JP5865091B2 (ja) 2012-01-20 2012-01-20 ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム
JP2012-010333 2012-01-20

Publications (1)

Publication Number Publication Date
WO2013108730A1 true WO2013108730A1 (ja) 2013-07-25

Family

ID=48799155

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/050503 WO2013108730A1 (ja) 2012-01-20 2013-01-15 ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム

Country Status (2)

Country Link
JP (1) JP5865091B2 (ja)
WO (1) WO2013108730A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3547141A4 (en) * 2016-11-22 2019-10-16 Mitsubishi Electric Corporation INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD AND INFORMATION PROCESSING PROGRAM

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6364332B2 (ja) * 2014-11-19 2018-07-25 株式会社エヌ・ティ・ティ・データ 仕様生成方法、仕様生成装置、及びプログラム
JP7447044B2 (ja) * 2021-03-18 2024-03-11 株式会社日立製作所 プログラム分析装置、プログラム分析方法およびトレース処理追加装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05181685A (ja) * 1992-01-07 1993-07-23 Oki Electric Ind Co Ltd コンパイル実行方法
JP2005535055A (ja) * 2002-08-07 2005-11-17 ペーアーツェーテー　イクスペーペー　テクノロジーズ　アクチエンゲゼルシャフト データ処理方法およびデータ処理装置
JP2006164294A (ja) * 2005-12-26 2006-06-22 Fujitsu Ltd Ｊｉｔコンパイラを備えた仮想計算機
JP2007241426A (ja) * 2006-03-06 2007-09-20 Hitachi Software Eng Co Ltd アプリケーションの障害原因の特定作業支援システム
JP2008015665A (ja) * 2006-07-04 2008-01-24 Hitachi Ltd プログラム解析方法及びプログラム解析装置
JP2011100420A (ja) * 2009-11-09 2011-05-19 Toshiba Corp テストプログラム作成装置
JP2011113317A (ja) * 2009-11-26 2011-06-09 Fujitsu Ltd 検査装置、サーバ装置及び検査プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193190A (en) * 1989-06-26 1993-03-09 International Business Machines Corporation Partitioning optimizations in an optimizing compiler
JPH0744397A (ja) * 1993-07-30 1995-02-14 Nec Corp プログラム処理高速化方式

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05181685A (ja) * 1992-01-07 1993-07-23 Oki Electric Ind Co Ltd コンパイル実行方法
JP2005535055A (ja) * 2002-08-07 2005-11-17 ペーアーツェーテー　イクスペーペー　テクノロジーズ　アクチエンゲゼルシャフト データ処理方法およびデータ処理装置
JP2006164294A (ja) * 2005-12-26 2006-06-22 Fujitsu Ltd Ｊｉｔコンパイラを備えた仮想計算機
JP2007241426A (ja) * 2006-03-06 2007-09-20 Hitachi Software Eng Co Ltd アプリケーションの障害原因の特定作業支援システム
JP2008015665A (ja) * 2006-07-04 2008-01-24 Hitachi Ltd プログラム解析方法及びプログラム解析装置
JP2011100420A (ja) * 2009-11-09 2011-05-19 Toshiba Corp テストプログラム作成装置
JP2011113317A (ja) * 2009-11-26 2011-06-09 Fujitsu Ltd 検査装置、サーバ装置及び検査プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3547141A4 (en) * 2016-11-22 2019-10-16 Mitsubishi Electric Corporation INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD AND INFORMATION PROCESSING PROGRAM

Also Published As

Publication number Publication date
JP2013149164A (ja) 2013-08-01
JP5865091B2 (ja) 2016-02-17

Similar Documents

Publication Publication Date Title
US20100180263A1 (en) Apparatus and method for detecting software error
JP5865091B2 (ja) ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム
US9129137B2 (en) Method, computer program and device for providing security for intermediate programming code for its execution by a virtual machine
JP2009211503A (ja) ソースコード検証装置、及びソースコード検証方法
JP6248008B2 (ja) ソフトウェア検証システムおよび制御装置
JP5233355B2 (ja) プロパティ生成システムおよびプロパティ検証システム
JP4915362B2 (ja) 静的検証ツールのアノテーション自動挿入方法
US8739091B1 (en) Techniques for segmenting of hardware trace and verification of individual trace segments
CN113742252B (zh) 一种检测内存乱序的方法及装置
US20100077383A1 (en) Simulation method and storage medium for storing program
US9632912B1 (en) Method and system for debugging a program
WO2016103229A1 (en) A method for verifying a safety logic in an industrial process
JP2013003633A (ja) 故障再現装置、故障再現方法
JP5093508B2 (ja) ループ最適化システム、ループ最適化方法、及びループ最適化用プログラム
JP2005174045A (ja) ソースプログラム変換装置、ソースプログラム変換方法、ソースプログラム変換プログラム、および、プログラム記録媒体
US10534691B2 (en) Apparatus and method to improve accuracy of performance measurement for loop processing in a program code
JP6724673B2 (ja) テスト支援プログラム、テスト支援方法及びテスト支援装置
CN117236277B (zh) 用于检查寄存器的方法及装置、电子设备
JP5233354B2 (ja) プロパティ検証システム、プロパティ検証方法、及びプログラム
JP2011242888A (ja) システム開発支援装置及びプログラム並びに方法
JP2009217720A (ja) プログラム生成装置およびプログラム生成方法
JP2007265098A (ja) マクロ定義情報取得装置
JP2007041777A (ja) 言語処理方法
JP6668808B2 (ja) 未テスト箇所検出装置、未テスト箇所検出方法、および、プログラム
JP2007034650A (ja) ソフトウェア開発システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13738896

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13738896

Country of ref document: EP

Kind code of ref document: A1