JP7737556B2 - Computer and test pattern creation method - Google Patents

Description

The present invention relates to a method for creating test patterns for source code testing.

The use of electronics in control technologies related to the operation and movement of automobiles is increasing year by year. A single automobile is equipped with dozens of electronic control units (ECUs) and the total size of the software (hereafter referred to as source code) implemented in these ECUs ranges from 1 million to 10 million lines.

As the scale of source code development increases, there is also a demand to shorten development times. As a result, maintaining and improving the quality of source code during short-term development has become a major challenge for automakers and suppliers.

The following prior art exists as background art in this technical field. Patent Document 1 (JP 2014-63415 A) and Patent Document 2 (JP 2009-14406 A) are cited. Patent Document 1 (JP 2014-63415 A) describes an automatic test case generation device that generates software test specifications, characterized in that it includes a branch record statement insertion means that inserts a record statement into the branch point in program code that records whether the branch point has been reached, a multi-step linking means that links one step of program code for multiple steps, and an analysis means that analyzes whether the branch point will be reached when the multi-step linked program code is executed.

Patent document 2 (JP 2009-14406 A) describes an automatic testing device for an electronic control unit that takes in sensor signals and outputs actuator drive signals, comprising: a branch condition acquisition means that acquires the branch conditions of a control branch point to be tested from among the processes executed by the electronic control unit; an operation pattern generation means that outputs an operation pattern for executing the branch conditions in the electronic control unit; a simulator that generates a pseudo sensor signal that is equivalent to the sensor signal generated in response to the actuator drive signal when the actual machine that is the original control target of the electronic control unit operates in accordance with the operation pattern; a signal exchange means that supplies the pseudo sensor signal to the electronic control unit and receives the actuator drive signal emitted from the electronic control unit; and an inspection means that uses computer hardware resources to inspect whether the processing results in the electronic control unit and/or the processing results in the simulator are normal.

JP 2014-63415 A JP 2009-14406 A

The automatic test case generation device described in JP 2014-63415 A automatically tests the ECU under test using Hardware In-the-Loop Simulation (HILS), sending and receiving pseudo sensor signals and actuator drive signals between the ECU and the HILS, causing the ECU to operate in the same way as if it were connected to the actual device it is intended to control. Then, depending on whether the ECU processing results created at this time are normal, it can be automatically tested to see whether the ECU functions normally when operating while sending and receiving signals to and from the actual device.

ECUs store various source codes for controlling vehicles. These source codes contain numerous control branch points, which allow for complex condition settings. Therefore, to maintain the quality of the source code, it is desirable to inspect all control branch points, but the test cases used in ECU debug inspections are often created manually. In other words, test cases are created based on the creator's subjective judgment, resulting in variations in the quality of test cases depending on the creator. In this case, poor test results are produced due to defects in the test cases, reducing testing efficiency.

JP 2014-63415 A proposes a method for detecting branching points and automating the creation of test cases, but this proposal is intended to check the functional transitions of source code, and it is difficult to create test patterns that have physical meaning for sending and receiving pseudo sensor signals and actuator drive signals between the ECU and HILS.

In addition, Japanese Patent Application Laid-Open No. 2009-14406 proposes a method for automatically generating test patterns that are executed by simulation using HILS according to an execution list, which identifies control branch points (e.g., IF statements) to be inspected from source code, creates an execution list of the branch conditions at the branch points and their expected results, and then uses HILS to execute the simulation. However, in reality, in many cases, values in the source code are internal values that differ from physical values, and need to be converted to physical values taking into account the bit rate of the internal values. However, Japanese Patent Application Laid-Open No. 2009-14406 does not disclose a specific method for doing this.

The present invention has been made to solve the above-mentioned problems, and aims to automatically create test patterns for testing electronic control units by appropriately linking internal values in source code with physical values.

A representative example of the invention disclosed in this application is as follows: A computer that creates test patterns for testing a control program using a simulator's control model, comprising: a link data storage unit that stores link data representing the physical meanings of variables used in the control program; a test case creation unit that creates test cases written with internal variables that do not have physical meaning for testing branching or arithmetic processing of the control program; and a test pattern creation unit that uses the link data to convert the internal variables used in the test cases into thresholds and variables that have physical meaning, and creates test patterns written with the variables that have physical meaning.

According to one aspect of the present invention, test patterns for HILS, which require signals with physical meaning, can be created from test cases created from the source code of a control program composed of internal values. Other issues, configurations, and advantages will become clearer from the description of the following examples.

FIG. 1 is a schematic configuration diagram of a test environment according to an embodiment of the present invention. 1 is a flowchart of a process executed in this embodiment. 1 is an example of source code in which branch condition checking using HILS is performed. 10 is a flowchart of a process according to a test case. FIG. 10 is a diagram illustrating an example of the configuration of a link database. 10 is a flowchart of a process using a test pattern. 10 is a time chart of an output signal for operating a test pattern in HILS.

An embodiment of the present invention will be described below with reference to the drawings. The automated testing environment using HILS (Hardware In the Loop Simulation) according to this embodiment enables efficient testing by creating test patterns with physical meaning that operate HILS through an information link database, even for test cases created from source code consisting of internal values that have no physical meaning.

First, we will explain the automatic testing environment using the HILS of this embodiment with reference to Figure 1. Figure 1 is a schematic diagram of a system that tests source code 30 composed of internal values according to this embodiment using a HILS operated by physical signals. In Figure 1, the HILS is composed of a vehicle model 11 and a driving model 12. The HILS 10 of this embodiment is connected to an ECU (Electric Control Unit) 20 via electrical connection lines. The HILS 10 is also connected to a personal computer (PC) 70 via electrical connection lines.

HILS10 is a simulation system that performs desired simulations by exchanging signals with ECU20, just like the vehicle that ECU20 is intended to control. Source code 30 that runs on ECU20 is stored in PC70. It also includes an automatic test case creation tool 40 that analyzes the source code 30 and automatically creates test cases, and an automatic test pattern creation tool 50 that creates test patterns that run HILS10 via a link database 60 that gives physical meaning to test cases made up of internal values created by automatic test case creation tool 40.

HILS10 includes a vehicle model 11 and a driving model 12. The driving model 12 is a model that simulates driving operations by a driver, calculates the accelerator opening to achieve a vehicle speed that matches the supplied test pattern, and outputs information about the accelerator opening to the vehicle model 11.

Vehicle model 11 is a model that simulates the functions of a vehicle. For example, the actual engine installed in a vehicle is equipped with various sensors, such as an A/F sensor for measuring the exhaust air-fuel ratio, a crank angle sensor for measuring the crank angle, and an air flow meter for measuring the intake air amount Ga, as well as actuators such as fuel injection valves. Vehicle model 11 simulates the movement of the actual engine and actuators in accordance with accelerator opening information output from driving model 12 and actuator signals output from ECU 20, and generates simulated sensor signals similar to the various sensor signals generated in the actual engine.

The pseudo sensor signals generated in the vehicle model 11 are supplied to the ECU 20 via a wire harness. The pseudo sensor signals supplied from the vehicle model 11 to the ECU 20 include signals required by the ECU 20 to calculate the fuel injection amount (fuel injection time TAU), such as a pseudo signal from an A/F sensor (a pseudo signal from the exhaust air-fuel ratio) or a pseudo signal from the intake air amount Ga, or signals required to synchronize the processing of the ECU 20 with the processing of the HILS system 10, such as a pseudo signal from a crank angle sensor.

The ECU 20 performs predetermined processing required for controlling the internal combustion engine based on the pseudo sensor signals supplied from the vehicle model 11, and outputs the actuator signals generated by the processing back to the vehicle model 11. In this embodiment, the ECU 20 performs processing such as calculating the fuel injection time according to pseudo sensor signals such as intake air volume and exhaust air-fuel ratio A/F, and outputting an injection signal as an actuator drive signal to open the fuel injection valve for the fuel injection time at the appropriate timing.

Next, we will explain the operation for executing processing at a control branch point in a simulation using HILS10. Here, we will first explain the operation for specifying a driving pattern. In this embodiment, HILS10 executes a simulation that simulates the actual vehicle, which is the original control target, according to the input vehicle driving conditions. Therefore, the vehicle driving conditions are specified so that processing at the control branch point is executed in the simulation by HILS10. Specifically, HILS10 detects a control branch point (e.g., an IF statement) to be inspected from the control source code of CU20 stored in PC70, and the branch conditions at the branch point and their expected results are stored in PC70 as an execution list. HILS10 then specifies the target vehicle speed and target rotation speed as vehicle driving conditions so that the simulation in HILS10 is executed according to the execution list.

Next, referring to Figure 2, the specific details of the processing performed in this embodiment will be explained.

In step S1, control branch points (such as IF statements) are detected from the control program source code 30 stored in the HILS PC 70, and their branch conditions (variables, thresholds) and expected results are extracted. In step S2, the extracted branch conditions are stored in the PC 70 as test cases. As mentioned above, the source code 30 used here is composed of internal values, so it is a test case using internal values.

In step S3, the test case created using internal values is converted into a physical signal using the link database 60, and in step S4, the PC 70 creates and stores a test pattern that operates the HILS 10 using the converted physical signal.

In step S5, a test is performed using HILS10 using the test pattern created in step S4.

Figure 3 is an example of source code 30 that constitutes a routine that performs branch condition testing using HILS10. The input and output of source code 30 consist of input and output variables. These input and output variables are expressed as internal values, which are converted to physical values through rates. Therefore, unlike direct physical values within the source code, these input and output variables have no physical meaning and are values for which signal attributes are not specified. Source code 30 uses these internal values to perform various processes and branching operations.

Next, the specific details of the processing of this embodiment will be explained with reference to Figure 4. Figure 4 is a flowchart of the processing for performing branch condition checking using HILS10.

In the routine shown in Figure 4, first, the branch conditions and their expected results at the control branch points are extracted (steps 100 to 102). Specifically, control branch points (such as IF statements) are detected from the control source code stored in the HILS PC 70, and their branch conditions and expected results are extracted. The extracted branch conditions and expected results are stored in the PC 70 as an execution list of the test cases.

Figure 5 shows an example configuration of a link database 60 that describes the relationship between internal values (control program signals) in the source code and physical signals operating in HILS 10.

As mentioned above, test cases created using internal values written in the program signal column have no physical meaning or attributes and therefore cannot be used as test patterns to be run in HILS10. However, they can be used as test patterns if rates and attributes are associated with physical signals. Therefore, the link database 60 stores internal value information (RAM (Random Access Memory), rate, and unit) and the physical attributes of those internal values. Furthermore, information on the signals of test patterns used in HILS10 is stored and associated with the stored information as internal values. Internal values (variables, thresholds) used in test cases that do not have physical meaning or attributes are linearly convertible with the variables and thresholds of test patterns run in HILS10, and the conversion coefficients are written in the rate column. Furthermore, multiple internal values may be used in the control program for the same physical variable (e.g., engine speed). When the physical attributes are the same, there is only one test pattern signal run in HILS, so multiple internal values of the same physical attribute are associated with a single physical attribute signal using different rate values.

Figure 6 is a flowchart of test patterns with physical meanings that run in HILS 10 and are associated with internal values of test cases using the link database 60.

In the routine shown in Figure 6, the branch conditions and their expected results at control branch points are extracted (steps 300 to 302). Specifically, control branch points (such as IF statements) are detected from test cases stored in the HILS PC 70, and their branch conditions are extracted. The extracted branch conditions are stored in the PC 70 as an execution list of the test pattern.

Figure 7 is a time chart of the signals output to operate the test patterns stored in PC70 in HILS10.

The branch conditions in the test pattern shown in FIG. 6 are A to D below, and signals corresponding to the branch conditions A to D are output from the PC 70 at the timings shown in FIG.
A: Branch to N at S200 for engine speed, water temperature condition, and judgment time. B: Branch to N at S201. C: Branch to N at S202. D: Y for all conditions.

The above describes an embodiment of the present invention using HILS, but the present invention can also be applied to MILS.

As described above, in an embodiment of the present invention, the internal values of test cases created from the control program source code 30 are associated with a link database 60 that stores variable names, physical attributes, and rates for converting physical values, and test patterns consisting of physical signals that can be operated in HILS10 are created by referring to the link database 60, so that test patterns that can be operated in HILS10 can be created from the control program source code 30.

Also, even if multiple internal values representing the same physical variable (e.g., engine speed) are used in a control program, they can be associated with a single physical attribute signal using different rate values and consolidated into a single signal in the test pattern run by HILS.

The present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations that include all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added, deleted, or replaced with other configurations.

Furthermore, each of the aforementioned configurations, functions, processing units, processing means, etc. may be realized in hardware, for example by designing some or all of them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

Information such as programs, tables, files, etc. that realize each function can be stored in storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.

Furthermore, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily represent all control lines and information lines necessary for implementation. In reality, it is safe to assume that almost all components are interconnected.

10...HILS system, 11...vehicle model, 12...driving model, 20...ECU, 30...source code, 40...automatic test case creation tool, 50...automatic test pattern creation tool, 60...link database, 70...HILS PC

Claims (7)

A computer that generates test patterns for testing a control program using a control model of a simulator,
a link data storage unit for storing link data representing the physical meanings of variables used in the control program;
a test case creation unit that creates test cases described with internal variables that have no physical meaning for testing branching or arithmetic processing of the control program;
a test pattern creation unit that uses the link data to convert internal variables used in the test case into thresholds and variables having physical meanings, and creates a test pattern described with the variables having physical meanings. 2. The computer of claim 1,
The internal variable having no physical meaning and the variable having physical meaning are in a linearly transformable relationship,
The computer is characterized in that the link data storage unit stores a conversion coefficient between the internal variable having no physical meaning and the variable having a physical meaning. 3. The computer of claim 2,
The test pattern generation unit
Extracting internal variables of branch processing and their thresholds from the control program;
converting the internal variables and thresholds of the branching process into variables and thresholds having physical meanings by referring to the conversion coefficients stored in the link data storage unit;
A computer that generates test patterns described by variables and thresholds having physical meanings. 2. The computer of claim 1,
The control program is a computer program that is executed by an on-vehicle electronic control unit. 1. A test pattern generation method for generating a test pattern for testing a control program using a control model of a simulator, comprising:
The computer that executes the test pattern generation method includes an arithmetic unit that executes predetermined arithmetic processing, and a storage device that is connected to the arithmetic unit;
the storage device stores link data that represents the physical meaning of variables used in the control program;
The test pattern creation method includes:
a test case creation procedure in which the arithmetic device creates test cases described with internal variables that have no physical meaning for testing branching or arithmetic processing of the control program;
a test pattern creation procedure in which the computing device uses the link data to convert internal variables used in the test case into variables having physical meanings, and creates a test pattern described with thresholds and variables having physical meanings. 6. The test pattern creation method according to claim 5,
The internal variable having no physical meaning and the variable having physical meaning are in a linearly transformable relationship,
The test pattern generating method according to the present invention, wherein the storage device stores conversion coefficients between the internal variables that do not have physical meaning and the variables that have physical meaning. 7. The test pattern creation method according to claim 6,
In the test pattern generation procedure,
the arithmetic unit extracts an internal variable of a branch process and a threshold value thereof from the control program;
the arithmetic unit converts the internal variables and thresholds of the branching process into variables and thresholds having physical meanings by referring to the conversion coefficients stored in the storage device;
A test pattern generating method, characterized in that the arithmetic unit generates a test pattern described by the variables and threshold values having physical meanings.