Method and device for testing vehicle-mounted application and computer readable medium

Abstract

The invention provides a method for testing a vehicle-mounted application. The method comprises the following steps: enabling the vehicle-mounted application to enter a test mode; connecting an interface of the vehicle-mounted application to a simulation unit; enabling the in-vehicle application to receive simulation data of data necessary for the in-vehicle application to execute a function from the simulation unit; and causing the in-vehicle application to execute the function using the received simulation data. By emulating data necessary for the in-vehicle application to perform a function, the in-vehicle application can be tested independently of the sensor and / or other applications that provide the data.

Description

Technical Field

[0001] The present invention relates to testing of applications, and more particularly, to testing of vehicle-mounted applications. Background Art

[0002] Dozens of applications can be run simultaneously in a Linux-based advanced driver assistance system (ADAS) domain controller. The operation of these applications usually requires the support of external sensors, and usually requires coordination between applications. For example, the central computing application needs to receive sensor data from sensors such as millimeter-wave radars and front-view cameras, and needs to receive data such as vehicle speed and following status from the adaptive cruise control (ACC) application in order to calculate the target acceleration of the vehicle. The calculated results can be returned to the ACC application to control the vehicle. In other words, it is difficult for the central computing application to perform its functions independently, and other related applications and sensors must be started at the same time when it is running.

[0003] When testing or debugging an application, if the data provided by other related applications and sensors cannot be obtained, the function of the application under test cannot be started and cannot be tested. Therefore, application testing also requires the support of other related applications and sensors. This is difficult for testing in-vehicle applications, because the vehicle needs to be actually driven to activate the corresponding sensors and other related applications to obtain relevant data. If such an application needs to be debugged repeatedly, the vehicle must be kept in driving state. In addition, when debugging the application under test, since multiple related applications work in coordination, it is very likely that the application under test that could have run normally will report an error due to errors in other applications, thereby affecting the test results. Furthermore, it may be difficult to test the application in some extreme cases, such as it is difficult to test the application in rare extreme weather conditions, or it is difficult to test the application under some occasional failures.

[0004] Therefore, it remains desirable to provide improved testing of in-vehicle applications. Summary of the invention

[0005] The present invention provides improved testing of in-vehicle applications by using simulated data to enable the application to be tested independently of external sensors and / or other applications.

[0006] According to one aspect of the present invention, a method for testing an in-vehicle application is proposed, comprising: causing the in-vehicle application to enter a test mode; connecting an interface of the in-vehicle application to a simulation unit; causing the in-vehicle application to receive simulation data of data necessary for the in-vehicle application to execute a function from the simulation unit; and causing the in-vehicle application to execute the function using the received simulation data.

[0007] According to another aspect of the present invention, a device for testing in-vehicle applications is proposed, comprising: a memory on which an in-vehicle application is stored, the in-vehicle application including instructions; and a processor for running the instructions to perform the following operations: causing the in-vehicle application to enter a test mode; connecting an interface of the in-vehicle application to a simulation unit; causing the in-vehicle application to receive simulation data of data necessary for the in-vehicle application to execute a function from the simulation unit; and causing the in-vehicle application to execute the function using the received simulation data.

[0008] According to another aspect of the present invention, a computer-readable medium is proposed, on which an in-vehicle application is stored. The in-vehicle application includes instructions, which, when executed by a processor, cause the processor to: cause the in-vehicle application to enter a test mode; connect an interface of the in-vehicle application to a simulation unit; cause the in-vehicle application to receive simulation data from the simulation unit that is necessary for the in-vehicle application to execute a function; and cause the in-vehicle application to execute the function using the received simulation data.

[0009] By simulating the sensor data necessary for the vehicle-mounted application to perform its function and / or the data provided by other applications, and using the obtained simulation data to make the tested application perform the corresponding function, the tested application can be tested independently of the operation of external sensors and / or other applications. Therefore, it is not necessary to start the external sensors and / or other applications when testing the tested application, which allows the tested application to be tested without the actual vehicle driving, thereby simplifying the testing process. For example, the tested application can be tested only on a computer without being installed on the vehicle. In addition, errors in test results caused by failures of external sensors and / or other applications can be avoided. At the same time, extreme situations can be simulated to implement testing of applications in extreme situations.

[0010] Still further advantages of the present invention will be appreciated to those of ordinary skill in the art upon reading and understanding the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A flowchart of a method 100 for testing an in-vehicle application according to an embodiment of the present invention is shown;

[0012] Figure 2 shows a flowchart 200 of the operation of the vehicle-mounted application according to one embodiment of the present invention; and

[0013] Figure 3 FIG. 4 is a block diagram of an apparatus 300 for testing an in-vehicle application according to an embodiment of the present invention. DETAILED DESCRIPTION

[0014] Figure 1 A flow chart of a method 100 for testing an in-vehicle application according to an embodiment of the present invention is shown.

[0015] The in-vehicle application can be, for example, a central computing application or a central decision-making application on a Linux-based advanced driver assistance system (ADAS) domain controller. The central computing application can calculate the acceleration / deceleration of the vehicle during the vehicle's adaptive cruise control (ACC), or can calculate the steering angle during the automatic parking (APA) process. The central decision-making application can decide in ACC and APA whether it is necessary to remind the driver to take over the steering wheel to improve driving safety. The characteristic of these in-vehicle applications is that they cannot run independently. They need to receive data from external sensors such as millimeter-wave radars and forward-looking cameras, need to receive data from other applications such as ACC modules and APA modules, and need to send calculation results or decision results to other applications.

[0016] In 110 , the in-vehicle application is caused to enter a test mode.

[0017] In one embodiment, the vehicle-mounted application may not be finalized and is not ready for installation in the vehicle. At this point, it only has a test mode. In this case, when the application is started on a processing device such as a computer, the application is directly put into the test mode. Therefore, it can be understood that in the present invention, the vehicle-mounted application does not necessarily refer to an application that has been installed in the vehicle, and it may refer to an application that is developed for use in the vehicle but still exists on a processing device such as a computer in order to be tested.

[0018] Alternatively, the in-vehicle application is already a well-developed application and can be installed on the vehicle to perform the corresponding functions. In this case, the test mode and the running mode can be configured for the in-vehicle application. When starting the application, the user can, for example, choose to enter the test mode or the running mode through the user interface. Of course, in order to facilitate the user's daily use, when starting the in-vehicle application, the running mode can be entered directly by default, and the test mode will only be entered when the user gives a specific user instruction. The user can give user instructions through various methods such as buttons, touch, voice, etc. to make the in-vehicle application enter the test mode.

[0019] In 120, the interface of the in-vehicle application is connected to the simulation unit. Then, in 130, the in-vehicle application receives simulation data of data necessary for the in-vehicle application to execute functions from the simulation unit.

[0020] In one embodiment, entries of data necessary for the vehicle-mounted application to execute functions can be stored in a test mode configuration file. After the vehicle-mounted application enters the test mode, the test mode configuration file can be read to obtain entries of required data. Based on the obtained entries of required data, the corresponding interface can be activated. For example, when it is determined that the video data of the front-view camera and the vehicle speed data provided by the ACC module are required to run the application, the video data interface and the vehicle speed data interface can be activated. The activated interface is then connected to the simulation unit to receive simulated versions of the video data and the vehicle speed data from the simulation unit.

[0021] Alternatively, after the vehicle-mounted application enters the test mode, the interface of the application can be non-selectively connected to the simulation unit, and identification data that can identify the type of the vehicle-mounted application can be sent to the simulation unit. Afterwards, the simulation unit can determine what data is required for the type of vehicle-mounted application based on the identified type of the vehicle-mounted application, and thus provide the simulated version of the data to the application under test.

[0022] In one embodiment, the data necessary for the vehicle-mounted application to perform functions includes sensor data and data from other applications. For common assisted driving technologies such as adaptive cruise control (ACC), automatic emergency braking (AEB), and automatic parking (APA), it is important to be able to provide accurate control parameters for these technologies, including but not limited to: acceleration, deceleration, steering angle, etc. For example, in ACC, the acceleration or deceleration of the vehicle can be calculated based on the current vehicle speed, the target vehicle speed set by the user, and the distance from the vehicle in front. In order to calculate the corresponding control parameters, the central computing application must require sensor data. For example, the distance between the vehicle and the vehicle in front can be measured by laser radar, which is the necessary data for calculating the acceleration or deceleration of the vehicle. In addition, in ACC, the central computing application needs to receive data on the current vehicle speed from the ACC application, and receive the target vehicle speed set by the user from the application used to interact with the user. These data from other applications are also necessary for calculating the acceleration or deceleration of the vehicle.

[0023] In other embodiments, some applications may only need specific sensor data or data from other applications to run. For example, an application for triggering a collision alarm in parking may only receive data from sensors such as radar, video cameras; or an application for congestion alarm may only receive data from a navigation application.

[0024] These necessary data provided by sensors and / or other applications are prerequisites for running the vehicle-mounted application under test. In order to make the vehicle-mounted application under test run independently of sensors and / or other applications, the simulation unit needs to provide the vehicle-mounted application under test with simulation data of these necessary data. For example, the simulation data can have the same data format and the same numerical range as the corresponding real data. Therefore, when the vehicle-mounted application under test receives the simulation data, it is as if it has received the real data obtained during the actual driving of the vehicle, to ensure that the vehicle-mounted application under test can perform its functions based on the received simulation data.

[0025] In one embodiment, the simulation data may include historical measured data. For example, sensor data collected during tens of thousands of actual drivings of the same type of vehicle and / or data generated by other applications may be stored as simulation data for testing the application under non-actual driving conditions.

[0026] In this case, the simulation unit may simply be a database, which may store historical measured data in a table, for example, and the application under test may read data specified by the test mode configuration file, for example, from the database through a corresponding interface.

[0027] In one embodiment, the simulation data may include modified data obtained by modifying the historical measured data. In this case, the simulation unit may be a simulation module including a memory and a processor. The memory may store the historical measured data and corresponding instructions, and the processor may execute the corresponding instructions to modify the stored historical measured data.

[0028] This embodiment is advantageous because it can simulate some rare extreme conditions by modifying historical measured data, for example, some extreme weather conditions (such as heavy rain or fog) that are difficult to encounter even in thousands of actual drivings. These extreme weather conditions can be simulated by modifying historical measured data, for example, video camera data collected on ordinary rainy days can be modified to simulate video camera data under heavy rain conditions.

[0029] Alternatively, this embodiment can simulate some rare equipment failures. For example, in an instance where the application under test needs to rely on the data of the millimeter-wave radar and the front-view camera to identify objects in the scene at the same time, when the millimeter-wave radar or the front-view camera has an equipment failure, the data of the millimeter-wave radar and the front-view camera may give contradictory results. In this case, the application under test should have the ability to make a final decision. For example, in the case where different data give contradictory results, the application under test can make a decision based on the priority or confidence of each data. However, it is likely that it is difficult to encounter situations where the data of the millimeter-wave radar and the front-view camera give contradictory results in thousands of actual drivings, which makes it impossible for the application under test to test this decision-making function based on historical measured data. This equipment failure situation can be simulated by modifying the historical measured data. For example, in the case where the data of the millimeter-wave radar and the front-view camera both identify a specific object as a vehicle, the recognition result of the millimeter-wave radar can be modified to a pedestrian so that the data of the millimeter-wave radar and the front-view camera give contradictory recognition results. The ability of the application under test to run in the case of encountering contradictory results can be tested by modifying the historical measured data.

[0030] In one embodiment, the simulation unit includes a simulation model. The simulation model can generate simulation data completely independent of measured data. The user can provide input data to the simulation model through a user interface. The input data may include basic input and adjustable input. Basic input is an input that remains unchanged during the simulation process, such as the size of the vehicle, the engine model, etc. The adjustable input can be modified during the simulation process to simulate different situations. For example, the user can modify the congestion condition (such as the number and distance of other vehicles located in front, behind, left and right of the vehicle), weather conditions, road conditions (such as whether the road is a highway or a city road, whether the road surface is smooth or bumpy), etc. Based on different input data, the simulation model can output corresponding simulation data, such as simulated front-view camera data, simulated millimeter-wave radar data, and simulated ACC module output data. After the simulation model generates simulation data, the simulation unit can provide the generated simulation data to the application under test through a corresponding interface.

[0031] The simulation model may be, for example, a trained machine learning model, for example, the simulation model may be trained using real data on the vehicle's size, engine model, congestion, weather conditions, road conditions, etc., as well as sensor data and ACC module output data measured under the corresponding real data.

[0032] After the application under test receives the simulation data from the simulation unit, the vehicle-mounted application is enabled to perform its functions using the received simulation data in 140. In this process, it can be tested whether the vehicle-mounted application can stably perform its functions, whether it can give accurate results and / or appropriate decisions, and whether it can respond to user needs in a timely manner.

[0033] It can be understood that for a certain application, it can implement more than just one function. For example, for a central computing application, it can calculate the acceleration / deceleration of the vehicle for ACC, and can also calculate the vehicle steering angle for APA, etc. For different functions, the data required can also be different.

[0034] Therefore, the user can select which function of the test application through the user interface. For example, the user can choose to enter the first test mode for calculating acceleration / deceleration for ACC, or can choose to enter the second test mode for calculating the vehicle steering angle for APA.

[0035] When entering the first test mode, the interface of the application under test may be connected to the first simulation unit, and when entering the second test mode, the interface of the application under test may be connected to the second simulation unit.

[0036] The first simulation unit and the second simulation unit may be the same simulation unit. For example, the first simulation unit and the second simulation unit may be a database storing historical measured data, wherein various types of data are stored in the database. When entering the first test mode, the first group of data types required for the first test mode may be determined by reading the first configuration file, thereby reading the first group of data types from the database; when entering the second test mode, the second group of data types required for the second test mode may be determined by reading the second configuration file, thereby reading the second group of data types from the database.

[0037] Alternatively, the first simulation unit and the second simulation unit may be different simulation units. For example, the first simulation unit and the second simulation unit are different databases. Alternatively, the first simulation unit and the second simulation unit include different simulation models. For example, the simulation model of the first simulation unit may simulate relevant sensor data and ACC module output data for ACC, and the simulation model of the second simulation unit may simulate relevant sensor data and APA module output data for APA.

[0038] In one embodiment, as described above, the vehicle-mounted application under test may be an application that has been fully developed and can be installed on the vehicle to perform the corresponding functions. In this case, the vehicle-mounted application may also include an operating mode. When the application is started, the operating mode will be entered by default. Alternatively, the user can choose to enter the test mode or operating mode of the application through the user interface. Unlike the test mode, in the operating mode, the interface of the application will be connected to real sensors and / or other related applications, so that real-time measurement data can be received during the actual driving process of the vehicle to perform related functions.

[0039] Figure 2 A flow chart 200 showing the operation of such a refinement application is shown.

[0040] At 210 , an in-vehicle application is launched.

[0041] In 220, it is determined whether the vehicle-mounted application enters the test mode. In one embodiment, after the vehicle-mounted application is started, it enters the non-test mode (i.e., the running mode) by default. If the user wants to enter the test mode, the user can issue a user command to enter the test mode. In another embodiment, after the vehicle-mounted application is started, the user should actively issue a command to select whether to enter the test mode or the running mode.

[0042] If it is determined in 220 that the vehicle-mounted application enters the test mode, then in 230 , the test mode configuration file is read to determine data entries necessary for running the application from the configuration file.

[0043] In 240, after reading the necessary data entries from the configuration file, the vehicle-mounted application is run under conditions independent of external sensors and other applications, including connecting the interface to the simulation unit 10 to obtain the simulated version of the necessary data entries from the simulation unit 10. The simulation unit 10 can be a flexible simulation framework that can provide simulated versions of each data entry under different scenarios (e.g., different driving states, different weather, different road conditions, different faults). Different scenarios can be defined according to user input. Alternatively, different scenarios can be predefined, and when performing application testing, all predefined scenarios can be experienced in sequence, thereby achieving testing for all scenarios. At the same time, after receiving the simulated data of the necessary data, the vehicle-mounted application can use the received data to perform its function, for example, calculate the acceleration value for ACC. At the same time, the vehicle-mounted application can return the calculated result to the simulation unit 10 through the interface, and the simulation unit 10 can verify the calculated result. For example, the simulation unit 10 can simulate the ACC module to generate a signal to control the vehicle using the calculated acceleration value. If the calculated result cannot be recognized by the simulated ACC module or the value is obviously wrong, the simulation unit 10 may issue an alarm to inform the user that the in-vehicle application may not pass the test.

[0044] If it is determined in 220 that the in-vehicle application enters the running mode, then in 250, it is checked whether the interface of the application is successfully connected to the external sensor 20 and other related one or more applications 30. If the connection is successful, in 260, the in-vehicle application is started to perform its related functions, such as calculating vehicle control parameters or making vehicle control decisions.

[0045] Figure 3 FIG. 4 is a block diagram of an apparatus 300 for testing an in-vehicle application according to an embodiment of the present invention.

[0046] The device 300 includes a memory 310 , in which an in-vehicle application is stored, and the in-vehicle application includes instructions.

[0047] The device 300 also includes a processor 320, which is used to run the instructions to perform the following operations: cause the in-vehicle application to enter a test mode; connect the interface of the in-vehicle application to a simulation unit; cause the in-vehicle application to receive simulation data from the simulation unit that is necessary for the in-vehicle application to execute a function; and cause the in-vehicle application to execute the function using the received simulation data.

[0048] It can be understood that the device according to the present invention has the same or similar embodiments as the method according to the present invention. For example, the processor can also execute the instructions to make the vehicle-mounted application enter the second test mode, so as to test the second function; and the processor can also execute the instructions to make the vehicle-mounted application enter the running mode, so as to execute the corresponding function during the actual driving process.

[0049] Those skilled in the art will appreciate that the simulation unit may represent a software module. For example, the simulation unit may be another application independent of the vehicle-mounted application being tested. The application may be stored in the memory 310 of the apparatus 300, or may be stored in the memory of another device. For example, the simulation module as an application may be stored in a computer independent of the vehicle, and when the vehicle-mounted application needs to be tested, the computer may be connected to the vehicle to interact with the vehicle-mounted application installed in the vehicle. Alternatively, the simulation unit may represent a hardware device. For example, the simulation unit may be a computing device having the simulation function of the present invention.

[0050] Figure 1 The method shown in can be implemented by a processor executing corresponding instructions included in the vehicle-mounted application. The vehicle-mounted application and the instructions contained therein can be stored on any appropriate computer-readable medium.

[0051] The above is only for reference Figure 1 The illustrated embodiments describe the method of the present invention. It is understood that the operations included in the above embodiments are not restrictive and can be deleted, combined, changed, split and / or recombined as needed to add / modify / delete corresponding functions.

[0052] The apparatus and method of the present invention are described above with reference to various embodiments, wherein the embodiments mentioned may include specific features, structures or characteristics, but not every embodiment necessarily includes the specific features, structures or characteristics. In addition, some embodiments may have some or all of the features described for other embodiments or have no features described for other embodiments.

[0053] The various features of different embodiments or examples can be combined in a variety of ways with some of the features included and other features excluded to adapt to a variety of different applications. The accompanying drawings and the foregoing description give examples of embodiments. It will be appreciated by those skilled in the art that one or more of the elements described can be combined into a single functional element. Alternatively, certain elements can be divided into multiple functional elements. Elements from one embodiment can be added to another embodiment. For example, the order of the processes described herein can be changed and are not limited to the methods described herein. In addition, the operations of any flow chart do not need to be implemented in the order shown; nor do they necessarily need to perform all operations. In addition, those operations that are not dependent on other operations can be performed in parallel with other operations. The scope of the embodiments is by no means limited by these specific examples. Whether or not it is clearly given in the specification, many changes such as differences in the order of operations, product composition, and structure are possible.

Claims

1. A method for testing an in-vehicle application, comprising: causing the in-vehicle application to enter a test mode; connecting the interface of the in-vehicle application to a simulation unit; causing the in-vehicle application to receive simulation data of data necessary for the in-vehicle application to execute a function from the simulation unit; and The in-vehicle application is caused to perform the function using the received simulation data.

2. The method according to claim 1, in, The simulation data includes historical measured data.

3. The method according to claim 1, in, The simulation data includes modified data obtained by modifying historical measured data.

4. The method according to claim 1, in, The simulation data includes data generated by a simulation model.

5. The method according to any one of claims 1 to 4, in, The data necessary for the in-vehicle application to execute the function includes sensor data and / or data provided by other applications.

6. The method according to any one of claims 1 to 4, further comprising: causing the in-vehicle application to enter a second test mode; connecting the interface of the in-vehicle application to a second simulation unit; The in-vehicle application receives second simulation data of second data necessary for the in-vehicle application to execute a second function from the second simulation unit; and enabling the in-vehicle application to perform the second function using the received second simulation data, The second simulation unit is different from the simulation unit, or the second simulation unit is the simulation unit.

7. The method according to any one of claims 1 to 4, further comprising: causing the in-vehicle application to enter a running mode; and In response to the in-vehicle application entering the running mode, the interface of the in-vehicle application is connected to sensors and / or other applications, and the sensors and / or other applications provide the in-vehicle application with data necessary for the in-vehicle application to perform the function through the interface.

8. A device for testing an in-vehicle application, comprising: a memory having an in-vehicle application stored thereon, the in-vehicle application including instructions; and A processor configured to execute the instructions to perform the following operations: causing the in-vehicle application to enter a test mode; connecting the interface of the in-vehicle application to a simulation unit; causing the in-vehicle application to receive simulation data of data necessary for the in-vehicle application to execute a function from the simulation unit; and The in-vehicle application is caused to perform the function using the received simulation data.

9. The device according to claim 8, in, The simulation data includes historical measured data.

10. The device according to claim 8, in, The simulation data includes modified data obtained by modifying historical measured data.

11. The device according to claim 8, in, The simulation data includes data generated by a simulation model.

12. The device according to any one of claims 8 to 11, in, The data necessary for the in-vehicle application to execute the function includes sensor data and / or data provided by other applications.

13. The device according to any one of claims 8 to 11, wherein: The processor is further configured to execute the instructions to perform the following operations: causing the in-vehicle application to enter a second test mode; connecting the interface of the in-vehicle application to a second simulation unit; The in-vehicle application receives second simulation data of second data necessary for the in-vehicle application to execute a second function from the second simulation unit; and enabling the in-vehicle application to perform the second function using the received second simulation data, The second simulation unit is different from the simulation unit, or the second simulation unit is the simulation unit.

14. The device according to any one of claims 8 to 11, wherein: The processor is further configured to execute the instructions to perform the following operations: causing the in-vehicle application to enter a running mode; and In response to the in-vehicle application entering the running mode, the interface of the in-vehicle application is connected to sensors and / or other applications, and the sensors and / or other applications provide the in-vehicle application with data necessary for the in-vehicle application to perform the function through the interface.

15. A computer-readable medium having an in-vehicle application stored thereon, the in-vehicle application comprising instructions, which when executed by a processor cause the processor to perform the method according to any one of claims 1-7.

Images