WO2016039076A1 - プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体 - Google Patents

プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体 Download PDF

Info

Publication number
WO2016039076A1
WO2016039076A1 PCT/JP2015/072980 JP2015072980W WO2016039076A1 WO 2016039076 A1 WO2016039076 A1 WO 2016039076A1 JP 2015072980 W JP2015072980 W JP 2015072980W WO 2016039076 A1 WO2016039076 A1 WO 2016039076A1
Authority
WO
WIPO (PCT)
Prior art keywords
condition
value
inspection
constraint
input value
Prior art date
Application number
PCT/JP2015/072980
Other languages
English (en)
French (fr)
Japanese (ja)
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 WO2016039076A1 publication Critical patent/WO2016039076A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • the present invention relates to a technique for inspecting software.
  • the model checking method builds a software model in which the output value is dynamically determined by the input value to the software and the internal state of the software, and the dynamic behavior of the software observed as the output value sequence output in time series from the model It is a method to evaluate the validity of. Thereby, it is searched that there exists an input value or an internal state corresponding to a defect that violates the functional requirement and the safety requirement.
  • a model checking method for source code is effective as a means for reliably detecting a potential malfunction of in-vehicle software. This is because the in-vehicle software calculates the internal state value sequence for the input value sequence given along the time series and outputs the output value sequence, which is in good agreement with the characteristics of the model checking method described above.
  • software having elements that change in time series as described above or software simulating the behavior thereof may be referred to as a dynamic program.
  • a model checking method is requested as means for proving that the software authentication requirement is satisfied.
  • the model checking method defines internal state values that describe the internal state of software, and uses a state transition model that implements state transition rules corresponding to the input / output relationship of software to find a state transition sequence that corresponds to a defect. In this sense, it is a dynamic input / output relationship analysis method.
  • Patent Documents 1 to 3 listed below describe conventional techniques related to a model checking method.
  • simulations often used as checking methods include internal state values and input value sequences that satisfy the constraints on the initial values of internal state values in the model checking method and the constraints on the input value sequence for software. This is a method for inspecting whether or not the output value string violates the inspection condition by individually executing the software by setting the inspection operator individually and evaluating the output value string obtained as a result.
  • the cause of this increase in the amount of calculation is the huge number of initial internal state values that need to be set to cover the state transition paths, and it is necessary to construct the state transition paths by setting the initial state values individually. Due to being.
  • the number of state transition paths obtained from a suitably selected initial state value corresponding to the input value string is at least polynomially the worst exponent in relation to the length of the time-series input value string to be searched. It increases functionally.
  • the increase in calculation amount due to such a search method is also a factor that hinders the application of the model checking method.
  • the input value sequence received by a dynamic program designed for travel control is engine temperature, travel speed, vehicle body acceleration, etc., and these input value sequences are subject to the constraints corresponding to the correlation in time series. Only the inspection conditions (ie functional requirements and safety requirements) need to be met.
  • an abnormal input value sequence as described above When an abnormal input value sequence as described above is input to the software to be inspected, the output value sequence of the software to be inspected also becomes abnormal, so the model checking apparatus regards this as abnormal. However, such an inspection is essentially unnecessary. Therefore, when software is checked using a model checking method (or simulation), an abnormal input value sequence (for example, a random number sequence) that deviates from time-series constraints as described above is a viewpoint that suppresses consumption of computing resources. Therefore, it is desirable to eliminate before entering the dynamic program.
  • an abnormal input value sequence for example, a random number sequence
  • the present invention has been made in view of the problems as described above, and is a computational resource necessary for inspecting the behavior of software by eliminating in advance an abnormal input value string to be input to the inspection target software. It aims at suppressing.
  • the program inspection apparatus includes an input value sequence, an internal state value sequence, and an output value sequence of a dynamic program to be inspected, and a check condition describing software requirements, and a constraint condition for a satisfiability problem And an input value string suitable for the inspection is calculated in reverse from the output value string by searching for a solution satisfying the desired inspection condition.
  • calculation resources for inspecting software of a practical scale can be suppressed.
  • an abnormal output value sequence is output due to an input of an abnormal input value sequence, it is possible to suppress erroneous determinations that regard this as abnormal.
  • FIG. 5 is a flowchart for explaining processing in which the program inspection device according to the present invention performs satisfiability determination on software 100. It is a block diagram of the software inspection apparatus 400 which concerns on Embodiment 2.
  • FIG. 5 is a flowchart for explaining a procedure for an inspection program construction unit 410 to construct an inspection program 405 using software 100. It is a figure which shows the structure of the dynamic program 601 in Embodiment 3.
  • the internal state value sequence and output value sequence of the software When an abnormal input value sequence that is unnatural in time series is input to the software to be inspected, the internal state value sequence and output value sequence of the software also become abnormal values due to the abnormal input value sequence. From the viewpoint of improving the inspection efficiency, it is desirable to provide the software with an input value sequence that can obtain only an internal state value sequence and output value sequence that are valid in time series. However, it is not always clear at the time prior to the inspection whether an appropriate internal state value sequence or output value sequence can be obtained if any input value sequence is given in time series. Therefore, in the conventional software inspection, even if the input value string is limited, it is limited only to the extent that the input value string falls within the range of the upper and lower limit values. Since it becomes a test object, it was not desirable from the viewpoint of inspection efficiency.
  • the satisfiability problem is a problem of obtaining a variable group that satisfies a certain logical expression. This will be described in accordance with the problem of the present invention. This is equivalent to describing an internal state value sequence or output value sequence that is valid in time series as a logical expression, and obtaining an input value sequence that satisfies this. Since a SAT solver that solves a satisfiability problem is known, a desired input value sequence can be obtained by giving the above logical expression as a constraint condition of the SAT solver and causing the SAT solver to search for the solution. By performing software inspection using the input value string, it is possible to inspect software of a practical scale under limited calculation resources.
  • the SAT solver is generally implemented so as to obtain a solution satisfying a logical expression in the bit logical operation format, but the present invention can also be applied to SAT problems expressed by other formal logical expressions.
  • Constraints given to the SAT solver can be changed according to the type of software inspection to be performed. Thereby, it is possible to cope with a plurality of types of software inspections using the same mechanism.
  • Examples of constraints include (a) correlation between time-series input value strings, (b) correlation between time-series output value strings, and (c) between time-series input value strings and output value strings. (D) A combination of these correlations with the initial value of the internal state value is conceivable, but is not limited to this.
  • FIG. 1A is a conceptual diagram of a state transition model describing the operation of software to be inspected.
  • an input value sequence DATA_IN [t] that changes in time series is given to the software 100
  • the software 100 has an internal state value sequence STATE [t] that changes in time series according to this
  • a time-series output value sequence DATA_OUT [t] corresponding to the input value sequence is output. Since the internal state of the software 100 dynamically changes in time series, it may be called a dynamic program.
  • Software 100 is regarded as a function for determining an output value from an input value and an internal state, and the function is combined with an input value sequence DATA_IN [t], an internal state value sequence STATE [t], and an output value sequence DATA_OUT [t].
  • a state transition model representing the dynamic behavior of the software 100 can be constructed.
  • the program inspection apparatus according to the present invention solves the above satisfiability problem using this state transition model and each parameter described below.
  • FIG. 1B is a table showing parameters used by the program inspection apparatus according to the present invention.
  • the input value string, output value string, and internal state are as described with reference to FIG. 1A.
  • the state value S [t] is a combination of these three variables.
  • the function PROGRAM_STATE and the function PROGRAM_OUT are functions describing a state transition model of the software 100.
  • the initial value constraint condition CONDITION_INIT is a condition that regulates a possible value as the initial value of the internal state value.
  • the input value string constraint condition CONDITION_INPUT describes restrictions similar to those in the past, such as the range of the input value string DATA_IN [t].
  • the inspection condition CONDITION_CHECK describes an inspection performed on the software 100 as a constraint condition.
  • initial value constraint condition CONDITION_INIT normal initial internal state values that the software 100 can take may be listed.
  • inspection condition CONDITION_CHECK functional requirements, operation restrictions, hazard conditions, and the like defined in accordance with the operation mode of the software 100 may be set.
  • FIG. 2 is a diagram illustrating how each value string is obtained by recursively executing the software 100.
  • checking whether the software 100 violates the inspection condition means that there is a value string that does not satisfy the inspection condition with the specified inspection condition and the actual value of each value string in the time series as a constraint condition. Resulting in a SAT problem searching for no.
  • the specified inspection condition and the actual value of each value string in the time series can be used as a constraint condition in the SAT problem by expressing it as a logical expression.
  • FIG. 3 is a flowchart for explaining a process in which the program inspection apparatus according to the present invention performs a satisfiability determination on the software 100. Hereinafter, each step of FIG. 3 will be described.
  • the program checking apparatus is configured to program the initial value constraint condition, the input value string constraint condition, the check condition, the input value string DATA_IN [] and the initial value (STATE [0]) of the internal state value string STATE [] described in FIG. Obtained as input to the inspection device. These values may be entered in, for example, an appropriate data file.
  • the program checking apparatus includes the initial value constraint condition, the input value string constraint condition, and the check condition described in FIG. 1B together with the input value string DATA_IN [], the internal state value string STATE [], which are obtained by the method described in FIG.
  • the output value string DATA_OUT [] is described in a logical expression format. Specifically, a combination of each value string and each constraint condition in the time series by a logical product is a constraint condition given to the SAT solver.
  • the inspection program may be constructed by the program inspection apparatus itself, or may be provided by an external apparatus to the program inspection apparatus.
  • Steps S302 to S3021 The program checking device (its SAT solver, and so on) determines whether there is a solution that satisfies the initial value constraint condition (that is, each value sequence, and so on) (S302). If there is no satisfactory solution, it is reported as a determination result that the initial value constraint condition itself is not properly set, and this flowchart is ended (S3021).
  • the program checking apparatus determines whether there is a solution that satisfies the input value string constraint condition (S303). If there is no satisfactory solution, it reports that the input value string constraint condition itself is not properly set as a determination result, and ends this flowchart (S3031).
  • Steps S304 to S3041 The program inspection apparatus determines whether there is a solution that satisfies the inspection condition (S304). If there is no satisfactory solution, it is reported as a determination result that the inspection condition itself is not properly set, and this flowchart is ended (S3041).
  • Steps S302 to S304: Supplement These three steps are preliminaries for the operator who sets the constraint condition to set an erroneous constraint condition due to, for example, a human operation error, and to prevent an error in which the SAT solver cannot lead to an appropriate solution in advance. It is processing.
  • step S305 If a solution exists in step S305, the specific assigned value (that is, each time series value of DATA_IN [], STATE [], and DATA_OUT []) is reported as a specific example that violates the inspection condition. This flowchart is finished.
  • constraints may be set: (A) A set of normal initial internal state values that can be taken by the software 100 is set as an initial value constraint condition; (B) setting a definition of an appropriate input value string DATA_IN [] for the software 100, which is clearly specified in the functional requirements as a precondition that depends on the operating environment of the software 100, as an input value string constraint; (C) Inconvenience that the functional requirement defined in accordance with the operation mode of the software sets the output value string DATA_OUT [] obtained for the normal input value string DATA_IN [] as the inspection condition and violates this. It is determined whether or not the input value string DATA_IN [] exists.
  • constraints may be set: (A) A set of normal initial internal state values that can be taken by the software 100 is set as an initial value constraint condition; (B) An appropriate input value string DATA_IN [] explicitly specified in the functional requirements as a precondition during operation of the software 100, or a failure factor that may occur in the data source from which the software 100 obtains an input value Specify an abnormal input value string DATA_IN [] at any timing caused by this as an input value string constraint condition; (C) The hazard condition defined in accordance with the safety requirement of the software 100 is set as the inspection condition, and it is determined whether or not there is an inconvenient input value string DATA_IN [] that violates the inspection condition.
  • constraints may be set: (A) A set of normal initial internal state values that can be taken by the software 100 is set as an initial value constraint condition; (B) Appropriate input value sequence DATA_IN [] for the software 100, which is clearly specified in the functional requirements as a prerequisite for the operation of the software 100, or a failure factor that may occur in the data source from which the software 100 obtains input values An abnormal input value string DATA_IN [] at any timing is set as an input value string constraint condition; (C) A hazard condition defined in accordance with the safety requirements of the software 100 is set as an inspection condition, and whether or not there is a combination of an unfavorable failure factor and an input value string DATA_IN [] that violates the inspection condition. judge.
  • the program inspection apparatus uses the value sequence that changes in time series and the inspection condition for the software 100 as a logical expression that describes the restriction condition for the SAT solver, and satisfies the restriction condition. Search for a solution to This makes it possible to determine whether or not the software 100 that responds to the input value string DATA_IN [] that changes in time series has a problem that violates the functional requirements.
  • the program inspection apparatus it is possible to derive the normal input value sequence DATA_IN [] in time series and the output value sequence DATA_OUT [] output from this.
  • the input value string as the inspection range it is possible to limit the input value string as the inspection range to only a normal value range in time series. Therefore, it is possible to correctly determine the inspection items imposed on the software of a practical scale even in a situation where the calculation resources are limited.
  • the search range of the solution increases exponentially with respect to the size of the software 100, whereas according to the present embodiment, the calculation amount increases approximately polynomially with respect to the size of the software 100. Can be stopped.
  • the program inspection apparatus it is possible to prevent erroneous detection that the abnormal output value sequence DATA_OUT [] corresponding to the abnormal input value sequence DATA_IN [] is erroneously regarded as abnormal.
  • FIG. 4 is a configuration diagram of the software inspection apparatus 400 according to the second embodiment of the present invention.
  • the software inspection apparatus 400 is an apparatus for inspecting the software 100 using the program inspection apparatus 406 described in the first embodiment, and includes an initial value constraint setting unit 407, an input value string constraint setting unit 408, an inspection condition setting unit 409, an inspection A program construction unit 410 and a program inspection device 406.
  • the software inspection device 400 receives the initial value constraint condition 401, the input value string constraint condition 402, the software 100 to be inspected, and the inspection condition 403 as inputs, and outputs each determination result described in steps S302 to S306 in FIG. .
  • the program inspection apparatus 406 determines that the initial value constraint condition is invalid, the determination result 416 (S3021), the input value constraint condition is invalid, the determination result 417 (S3031), and the inspection condition is invalid.
  • a determination result 418 (S3041) indicating that there is a violation, a determination result 419 (S3051) indicating that there is no violation of the inspection condition, and an initial value and a time series value 420 (S306) that violate the inspection condition are output.
  • the initial value constraint condition 401 is configured by combining logical sum, logical product, or logical negation of initial value constraint description units.
  • the initial value constraint description unit is composed of a pair of (precondition for initial value of internal state) and (constraint condition).
  • the preconditions and constraint conditions include a variable that describes an initial value of an internal state, a variable group that corresponds to an input value string, and an expression that describes a constraint condition between variables using fixed values.
  • the initial value constraint setting unit 407 receives the initial value constraint condition 401 via an appropriate user interface or the like, and converts it into an initial value constraint condition description 411 described in the format of the initial value constraint condition.
  • a logical expression equivalent to the condition specified by the initial value constraint condition 401 and having high calculation efficiency may be constructed. For example, if the initial value constraint condition 401 is specified in the form “if (precondition) is satisfied (constraint condition of the initial value of the internal state value)”, the equivalent logical expression “NOT (premise (Condition)
  • the input value string constraint condition 402 is configured by combining logical sum, logical product, or logical negation of input value string constraint description units.
  • the input value string constraint description unit is composed of a pair of (precondition for input value string) and (constraint condition).
  • the input value string constraint setting unit 408 receives the input value string constraint condition 402 via an appropriate user interface or the like, and converts it into an input value string constraint condition description 412 described in the form of the input value string constraint condition.
  • the inspection condition 403 is configured by combining logical sum, logical product, and logical negation of the inspection condition description unit.
  • the inspection condition description unit is composed of a pair of (a precondition for the input value string or internal state initial value) and (a constraint condition for the output value string).
  • a precondition for the input value string or internal state initial value a precondition for the input value string or internal state initial value
  • constraint condition a variable corresponding to an initial value of an internal state value, a variable group corresponding to an input value string and an output value string, and a fixed condition are used to describe a constraint condition between variables.
  • the inspection condition setting unit 409 receives the inspection condition 403 via an appropriate user interface or the like, and converts it into an inspection condition description 415 described in the form of the inspection condition.
  • the inspection condition 403 can also specify a recursive execution condition 414 that specifies the number of executions for adjusting the calculation load.
  • FIG. 5 is a flowchart for explaining a procedure for the inspection program construction unit 410 to construct the inspection program 405 using the software 100. This flowchart corresponds to steps S301 to S304 in FIG.
  • Step S501 and S508 The inspection program construction unit 410 determines whether or not the initial value constraint condition description 411, the input value string constraint condition description 412 and the check condition description 415 are described without contradiction, and there is a solution that satisfies them. To do. If there is no satisfactory solution, the process proceeds to step S508, and a determination result (corresponding to S302 to S304) that any of the constraint condition descriptions is invalid is output, and this flowchart is terminated. If there is a satisfactory solution, the process proceeds to step S502.
  • the inspection program construction unit 410 performs a logical product of the initial value constraint condition description 411 converted into the logical expression format by the initial value constraint setting unit 407 and the initial value TRUE of the logical expression P (S502).
  • the inspection program construction unit 410 performs a logical product of the input value string constraint condition description 412 converted into the logical expression format by the input value string constraint setting unit 408 and the logical expression P updated in step S502 (S503).
  • the inspection program construction unit 410 acquires the recursive execution condition 414 (S504).
  • the recursive execution condition 414 specifies, for example, the final time T of the input value string.
  • the inspection program construction unit 410 initializes a counter t of the number of times that the following step S506 is recursively executed (S505).
  • Step S506 The inspection program construction unit 410 sequentially inputs an input value sequence to the software 100 to obtain an internal state value and an output value, and the logical product of these value sequence (corresponding to the dynamic program description 413) and the logical expression P Take. The inspection program construction unit 410 repeatedly executes this process until the final time point T is reached.
  • the inspection program construction unit 410 performs a logical product of the inspection condition description 415 converted into the logical expression format by the inspection condition setting unit 409 and the logical expression P updated in step S506.
  • the logical expression P obtained at this time is set as an inspection program 405.
  • the program inspection device 406 uses the inspection program 405 to execute the processing described in the first embodiment.
  • a vehicle travel control program 602 used in a vehicle system in which a travel stabilization function ESC (Electronic Stability Control) and a brake override function are simultaneously installed is used as an inspection target, as a specific description example of a constraint condition.
  • ESC Electronic Stability Control
  • a brake override function a specific description example of a constraint condition. An example will be described. Since the configuration of each device is the same as in the first and second embodiments, a specific example of the constraint condition will be mainly described below.
  • the vehicle travel control program 602 steps on more strongly than the brake control by ESC. Check that the mounting is prioritized.
  • ESC is a driving assistance function that is usually temporarily activated when the vehicle state becomes unstable due to deviation from the ideal contact state with the road. If the brake control by the ESC and the control of the brake itself are not properly implemented, if the operator of the vehicle system depresses the brake strongly with the intention of sudden braking, the control function between the brake itself and the control function by the ESC This causes output competition and makes it impossible to uniquely determine an appropriate acceleration / deceleration. In order to avoid such a problem, the vehicle travel control program 602 needs to implement appropriate priority processing regarding these functions.
  • the brake override function is a function that enforces brake priority when such output competition occurs. For example, even in a situation where the vehicle travel control program 602 sets an unintended acceleration command, there is a function that gives priority to a deceleration command through a brake depression by a driver.
  • FIG. 6 is a diagram showing a configuration of the dynamic program 601 in the third embodiment.
  • the dynamic program 601 shown in FIG. 6 includes a vehicle travel control program 602 to be inspected and a vehicle dynamic characteristic model 603 appropriately designed by using a simulation model.
  • An input value sequence for the vehicle travel control program 602 includes a vehicle operation value input value sequence 604 including an accelerator depression value, a brake depression value, and a steering angle value, a measurement state value input value sequence 605 received by the vehicle travel control program 602 from the vehicle system, It is the operating environment state value input value string 606 on which the dynamic characteristics of the vehicle system depend.
  • a dynamic friction coefficient depending on the state of the traveling road can be cited.
  • the vehicle travel control program 602 outputs a vehicle control value output value sequence 607 including an acceleration force value, a deceleration force value, a turning torque value, and a stop ramp value as an output value sequence.
  • the vehicle travel control program 602 uses a dynamic friction coefficient estimated value, a vehicle speed, and a vehicle attitude angular velocity as internal state values.
  • the vehicle dynamic characteristic model 603 uses an operating environment state value input value string 606 and a vehicle control value output value string 607 as input value strings.
  • the dynamic characteristic model 603 outputs a measurement state value input value sequence 605 as an output value sequence.
  • the dynamic characteristic model 603 uses vehicle acceleration and vehicle attitude angular velocity as internal state values.
  • FIG. 7 is a source code example of the vehicle travel control program 602 in which the brake override function is implemented.
  • FIG. 7A shows an example in which the function is not properly implemented, and
  • FIG. 7B shows an example in which the function is appropriately modified.
  • the vehicle operation value input value sequence 604 and the measurement state value input value sequence 605 are used as examples of the constraint condition for determining the posture unstable state.
  • a constraint condition for determining a sudden brake depression it is assumed that a brake depression value that is a component of the vehicle operation value input value sequence 604 is used.
  • the source code shown in FIG. 7 selects an appropriate control process such as BRAKE_ON, BRAKE_OFF, ESC_ON, ESC_OFF, FOLLOW_COM using the constraints corresponding to these determination conditions, and the acceleration that is the vehicle control value output value sequence 607
  • the force value, deceleration force value, turning torque value, and stop ramp value are output.
  • the inspection condition is “When the brake is depressed suddenly, the brake depression command is always given priority”.
  • the software inspection device 400 searches for an inconvenient behavior that violates this constraint condition.
  • the program that violates this constraint (Fig. 7 (a)) is designed to give priority to the brake control by sudden braking when the vehicle becomes unstable. The sudden brake that was depressed when it was turned on does not function effectively. The software inspection device 400 detects such an undesirable behavior.
  • FIG. 8 is a specific example of the initial value constraint condition of the vehicle travel control program 602. In this example, only the constraint condition regarding the range of the initial value is described.
  • FIG. 9A and FIG. 9B are specific examples of the input value string restriction conditions of the vehicle travel control program 602.
  • an expression format of the precondition a restriction at the time of application of the precondition or a specific conditional restriction condition can be used.
  • a constraint condition of the dynamic friction coefficient for example, a constraint condition regarding the dynamic friction coefficient within an assumed range, a constraint condition regarding primary continuity of the dynamic friction coefficient value, a limitation that the dynamic friction coefficient value decreases during a specific period, and the like can be used.
  • Constraint conditions related to the accelerator depression value include, for example, upper and lower limit constraints on the accelerator depression value as the inspection range, primary continuity constraint on the accelerator depression value, and restrictions on the time series value of the accelerator depression value.
  • upper and lower limit constraints on the accelerator depression value as the inspection range
  • primary continuity constraint on the accelerator depression value restrictions on the time series value of the accelerator depression value.
  • the final value is smaller than the initial depression value, and that the final value becomes the specified value under the upper and lower limit constraints and the primary continuity constraint. Describes the constraints. That is, the inspection range is limited to a range that satisfies these constraint conditions.
  • FIG. 10 is a specific example of the inspection conditions of the vehicle travel control program 602.
  • the first inspection condition includes (a) a precondition that the brake depression condition is satisfied at an arbitrary point in the inspection range acquired as the recursive execution condition 414, and (b) a constraint corresponding to the stop lamp being turned on. It is composed of conditions.
  • the second inspection condition is based on (a) a precondition that the brake depression condition is satisfied at an arbitrary point in the inspection range acquired as the recursive execution condition 414, and (b) a specified constraint condition regarding the deceleration force value. It is configured.
  • FIG. 11 is a time chart showing a calculation example of the internal state value, the input value string, and the output value string of the vehicle travel control program 602. This time chart displays an input value string, an internal state value, and an output value string for each discrete time of the inspection range acquired as the recursive execution condition 414.
  • a time chart example is shown in which the software inspection apparatus 400 outputs a determination result indicating that the inspection condition is violated.
  • the posture angular velocity measurement value (DATA_IN_RATE_YAW) greatly fluctuates in the negative direction
  • FIG. 7A the condition for determining posture instability in the program described is satisfied.
  • the ESC_ON state is set, and the brake control for the purpose of posture stabilization by ESC is prioritized over the principle of sudden braking. That is, according to the program shown in FIG. 7A, the branch condition for lighting the stop lamp (DATA_OUT_STOP_LAMP) cannot be reached, and the inspection condition is violated.
  • the control for enabling the sudden braking is started from the time when the ESC mode is turned OFF, and then the stop lamp is correctly shifted to the ON state.
  • the designer of the vehicle travel control program 602 reads the cause of violation in the program shown in FIG. 7 (a) based on the inspection condition violation shown in FIG. 11, and inspects again the program corrected as shown in FIG. 7 (b). Execute. When the same inspection condition violation disappears, it can be proved that the specified inspection condition is not violated at least in the range limited in FIGS.
  • FIG. 12 is a configuration diagram of the program inspection device 406.
  • the program checking device 406 includes a SAT solver 4062 which is software that implements an algorithm for solving the SAT problem, a CPU (Central Processing Unit) 4061 that executes the SAT solver 4062, a checking program 405, a storage device 4063 that stores each constraint description, data An interface 4064 for input / output is provided.
  • the SAT solver 4062 does not necessarily need to be implemented as software, and may be configured by hardware such as a circuit device that implements the same algorithm, or may be configured as a separate device such as a high-speed processing computer specialized for the SAT problem. You can also.
  • the present invention is not limited to the above-described embodiment, and includes various modifications.
  • the above embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment.
  • the configuration of another embodiment can be added to the configuration of a certain embodiment. Further, with respect to a part of the configuration of each embodiment, another configuration can be added, deleted, or replaced.
  • the control unit, processing unit, function, etc. may be realized by hardware by designing a part of them, for example, by an integrated circuit.
  • the control unit, the processing unit, the function, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
PCT/JP2015/072980 2014-09-11 2015-08-17 プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体 WO2016039076A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-185326 2014-09-11
JP2014185326A JP2016057969A (ja) 2014-09-11 2014-09-11 プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体

Publications (1)

Publication Number Publication Date
WO2016039076A1 true WO2016039076A1 (ja) 2016-03-17

Family

ID=55458834

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/072980 WO2016039076A1 (ja) 2014-09-11 2015-08-17 プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体

Country Status (2)

Country Link
JP (1) JP2016057969A (enrdf_load_stackoverflow)
WO (1) WO2016039076A1 (enrdf_load_stackoverflow)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9649376B2 (en) 2010-09-27 2017-05-16 Siwa Corporation Selective removal of age-modified cells for treatment of atherosclerosis
CN107544284A (zh) * 2017-07-20 2018-01-05 同济大学 一种复合工况下汽车制动器摩擦噪声控制方法
CN111966579A (zh) * 2020-07-24 2020-11-20 复旦大学 基于自然语言处理与机器学习的自适应文本输入生成方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017203660A1 (ja) * 2016-05-26 2017-11-30 株式会社日立製作所 データ処理装置、データ処理方法、及び自律システム
JP6692281B2 (ja) * 2016-12-02 2020-05-13 株式会社日立製作所 テストケース生成装置、及びテストケース生成方法
JP6838234B2 (ja) 2017-03-24 2021-03-03 日立Astemo株式会社 車両制御装置
CN110520850B (zh) 2017-04-19 2023-08-11 三菱电机株式会社 等效性验证装置和计算机能读取的存储介质
JP7059220B2 (ja) * 2019-02-15 2022-04-25 株式会社日立製作所 機械学習プログラム検証装置および機械学習プログラム検証方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011052030A1 (ja) * 2009-10-26 2011-05-05 株式会社 東芝 事前条件生成装置
JP2013045269A (ja) * 2011-08-24 2013-03-04 Nec Corp モデル検査装置、モデル検査方法およびコンピュータプログラム
WO2015111142A1 (ja) * 2014-01-22 2015-07-30 株式会社日立製作所 システム解析装置、設計不良解析装置、故障モード解析装置、故障ツリー解析装置、自律動作装置及び自律動作制御システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011052030A1 (ja) * 2009-10-26 2011-05-05 株式会社 東芝 事前条件生成装置
JP2013045269A (ja) * 2011-08-24 2013-03-04 Nec Corp モデル検査装置、モデル検査方法およびコンピュータプログラム
WO2015111142A1 (ja) * 2014-01-22 2015-07-30 株式会社日立製作所 システム解析装置、設計不良解析装置、故障モード解析装置、故障ツリー解析装置、自律動作装置及び自律動作制御システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9649376B2 (en) 2010-09-27 2017-05-16 Siwa Corporation Selective removal of age-modified cells for treatment of atherosclerosis
CN107544284A (zh) * 2017-07-20 2018-01-05 同济大学 一种复合工况下汽车制动器摩擦噪声控制方法
CN107544284B (zh) * 2017-07-20 2020-11-27 同济大学 一种复合工况下汽车制动器摩擦噪声控制方法
CN111966579A (zh) * 2020-07-24 2020-11-20 复旦大学 基于自然语言处理与机器学习的自适应文本输入生成方法

Also Published As

Publication number Publication date
JP2016057969A (ja) 2016-04-21

Similar Documents

Publication Publication Date Title
WO2016039076A1 (ja) プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体
US8302078B2 (en) Lazy evaluation of geometric definitions of objects within procedural programming environments
CN102073585B (zh) 一种基于模型的嵌入式系统流延时属性测试方法
CN110245085B (zh) 利用在线模型检验的嵌入式实时操作系统验证方法及系统
JP6469730B2 (ja) ソフトウェア検査装置
Ramezani et al. Multiple objective functions for falsification of cyber-physical systems
US20190146893A1 (en) Simulation device, simulation system, simulation method, and simulation program
US8881075B2 (en) Method for measuring assertion density in a system of verifying integrated circuit design
JP6584625B2 (ja) プログラム検査装置、ソフトウェア検査装置、ｓａｔ制約条件データ、記憶媒体
US9646252B2 (en) Template clauses based SAT techniques
US8903700B2 (en) Concretization of abstracted traces
WO2019142266A1 (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
US8166444B2 (en) Clock gating using abstraction refinement
US20080005619A1 (en) Validation of software execution paths
JP2013254371A (ja) ソフトウェア開発支援装置、ソフトウェア開発支援方法及びソフトウェア開発支援プログラム
US8639490B2 (en) Concretization of abstracted traces
Galarraga et al. Toward Linux-based safety-critical systems—Execution time variability analysis of Linux system calls
KR20210023722A (ko) 요구 사항에 대한 시스템의 테스트 방법
US20100077383A1 (en) Simulation method and storage medium for storing program
Dominka et al. Taming and optimizing feature interaction in software-intensive automotive systems
US10810111B2 (en) Computer system, test method, and recording medium
WO2015136844A1 (ja) 電子制御装置
CN119089708B (zh) 一种自动驾驶测试中残余风险接受准则的确定方法及装置
CN116643781A (zh) 用于控制机器人装置的方法
US7467366B2 (en) Method for generating a timing path software monitor for identifying a critical timing path in hardware devices coupled between components

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: 15840464

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: 15840464

Country of ref document: EP

Kind code of ref document: A1