OTA stress testing method, system, electronic device, and storage medium

Abstract

The present invention provides an OTA stress test method, system, electronic device, and storage medium, which relate to the field of OTA stress testing. It includes responding to a test startup program, reading a test configuration file of the test startup program; generating multiple upgrade task packages according to the test configuration file parameters, and issuing them to the modules under test specified by the upgrade task packages respectively; repeatedly flashing the ECU according to the upgrade task package until the cumulative number of tests reaches a preset number of tests; obtaining the test results of each module under test, and generating a test report according to the test results. During the test process, the method of the present application can write a configuration file once, and independently test multiple modules under test at the same time. The tester does not need to operate each module under test separately, which reduces the work tasks of the tester, effectively increases the number of tests, and meets the sample quantity requirements of the OTA stress test.

Description

Technical Field

[0001] The present invention relates to the field of OTA stress testing, and particularly to an OTA stress testing method, system, electronic device, and storage medium. Background Art

[0002] With the advent of the era of Internet of Things and big data, the "attributes" of cars are changing, which stems from the rise of intelligence. Cars are no longer simply means of transportation for getting around. They are constantly changing and growing. Car owners will occasionally discover small surprises brought by their cars. It becomes more considerate and safe. Even one day, it can drive by itself without your operation, thus further enhancing the sense of technology and intelligence for the driver. And what makes all this possible is OTA (Over-the-Air Technology). Against the backdrop of the country's strong support for the development of new energy vehicles, in-vehicle OTA technology will accelerate its popularization in the process of the electrification and intelligent development of cars. The development of vehicle OTA technology is an inevitable trend to promote the rapid iteration and update of connected cars. Automotive OTA first appeared in some models launched in 2012, and its update scope covers fields such as autonomous driving, human-machine interaction, power, and battery systems. Functions such as improving the key card vulnerability, increasing the cruising range, raising the maximum speed, and enhancing the riding comfort or the repair of vulnerabilities are completed through OTA. OTA brings about a revolution in the automotive business model. OTA is not only a standard configuration for the capabilities of the vehicle end, but also an operational standard configuration for the new profit model of car manufacturers. To ensure the test coverage of the OTA system and reduce the test coupling degree, at the same time, to improve the user experience after the vehicle is launched, the reliability and stability of the technology must be fully verified before being put on the market, including component verification of key controllers and system integration verification. And the only way to ensure this is to conduct a complete test and verification on the OTA solution.

[0003] The current OTA test solutions have many limitations and bottlenecks. First of all, the current solutions basically adopt non-automated test and verification methods, that is, manual test and verification by investing human resources. This not only brings a large amount of labor costs, but also because the link tests of OTA all involve downloading and installation, and these two steps take a lot of time, ranging from dozens of minutes to several hours. The consequence of this is that the input and output are not proportional.

[0004] Secondly, the current OTA tests are completed through manual or semi-automatic tests. Each test can only test one module under test, and the test coverage and efficiency are not high enough, far from meeting the sample quantity requirements of stress testing. Summary of the Invention

[0005] In view of the above-mentioned disadvantages of the prior art, the present invention provides an OTA stress test method to improve the technical problems that the existing OTA tests use non-automated test verification, consume a large amount of manpower and material resources, and have insufficient test coverage and efficiency, and cannot meet the number of stress test samples.

[0006] To achieve the above object and other related objects, the present invention provides an OTA stress test method. The method includes: in response to a test start program, reading a test configuration file of the test start program;

[0007] Generating a plurality of upgrade task packages according to the parameters of the test configuration file, and respectively sending them to the tested modules specified by the upgrade task packages;

[0008] Performing repeated ECU (Electronic Control Unit) flashing according to the upgrade task packages until the cumulative test times reach a preset test times;

[0009] Obtaining the test results of each of the tested modules, and generating a test report according to the test results.

[0010] In an embodiment of the present application, generating a plurality of upgrade task packages according to the parameters of the test configuration file and respectively sending them to the tested modules specified by the upgrade task packages includes: generating a plurality of the upgrade task packages with codes according to the parameters of the test configuration file; and respectively sending the upgrade task packages with different codes to the tested modules with different preset numbers according to the codes of the upgrade task packages.

[0011] In an embodiment of the present application, performing repeated ECU flashing according to the upgrade task packages until the cumulative test times reach a preset test times includes: triggering a version synchronization diagnostic service request; obtaining a download authorization license, obtaining an installation instruction manual and a software upgrade package; obtaining an installation authorization license, and flashing each corresponding ECU according to the installation instruction manual; obtaining a rollback operation request, performing a local rollback ECU flash, and incrementing the cumulative test times by one; obtaining the cumulative test times, and repeating the above steps according to the cumulative test times until the cumulative test times reach the preset test times.

[0012] In an embodiment of the present application, the instruction process for triggering a version synchronization diagnostic service request includes: a gateway controller reset request; an extended session entry request; a version synchronization instruction operation of the gateway; stepping on the brake pedal; setting the gear position to D gear; pressing the P gear button; and maintaining the above states for a preset time.

[0013] In an embodiment of the present application, a new thread is created to cyclically check the version synchronization status. If the query result is in a non-synchronized NOK state within the version synchronization viewing time, it is determined that version synchronization cannot be achieved, and a specific exception prompt is issued.

[0014] In one embodiment of the present application, obtaining an installation authorization license includes: receiving a software upgrade package; activating the update and upgrade button on the DHU; and automatically triggering the pressing of the update and upgrade button on the DHU through ADB control.

[0015] In one embodiment of the present application, receiving a software upgrade package includes: performing security verification of communication encryption before receiving the software upgrade package; detecting data frame anomalies during the reception of the software upgrade package; and performing security verification of OTA upgrade package signature verification after receiving the software upgrade package.

[0016] The present application also provides an OTA stress test system, including:

[0017] A test management module that reads a test configuration file, controls the generation of multiple upgrade task packages according to the test configuration file, and distributes the upgrade task packages to the corresponding modules under test specified by the upgrade task packages.

[0018] Modules under test, where one test management module corresponds to one or more modules under test; the module under test triggers a version synchronization diagnosis service request, obtains a download authorization license, then obtains an installation instruction manual and a software upgrade package, and performs flashing on the corresponding ECUs according to the installation instruction manual after obtaining the installation authorization license; performs a local rollback after obtaining a rollback operation request, increments the cumulative test count by one; obtains the cumulative test count and performs repeated tests.

[0019] After the cumulative test counts of each module under test reach their respective preset test counts, the test management module obtains the test results of each module under test and generates a test report based on the test results.

[0020] The present application also provides an electronic device, which includes:

[0021] One or more processors;

[0022] A storage device for storing one or more programs, which when executed by the one or more processors, cause the electronic device to implement the OTA stress test method as described in any one of the above.

[0023] The present application also provides a computer-readable storage medium, on which a computer program is stored, which when executed by a processor of a computer, causes the computer to execute the OTA stress test method as described in any one of the above.

[0024] The beneficial effects of the present invention are as follows:

[0025] The OTA stress test method provided by this application automatically completes the OTA stress test, executes the corresponding test script according to the test items, and outputs the test report with one key. The entire test process is automated, reducing the time occupied by testers and improving the test efficiency.

[0026] During the test process of the method of this application, it is possible to write the configuration file once and conduct independent tests on multiple modules under test simultaneously. Testers do not need to operate on each module under test separately, reducing the work tasks of testers, effectively increasing the number of tests, and meeting the sample quantity requirements of the OTA stress test.

[0027] During the test process of the method of this application, the test cases are automatically selected according to the settings. By coordinating the cloud and the vehicle end to synchronously restore the OTA initial state, it is ensured that the execution of the next test case is not interfered by the remaining tasks in the previous test case, and each test case runs independently, thus meeting the requirements of the OTA stress test. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0029] Figure 1 It is an exemplary schematic diagram of the existing OTA test;

[0030] Figure 2 It is a schematic diagram of an OTA automated test system;

[0031] Figure 3 It is a schematic diagram of an exemplary OTA stress test method of this application;

[0032] Figure 4 For this application Figure 3 It is an exemplary schematic diagram of step S430 in

[0033] Figure 5 For this application Figure 4 It is an exemplary schematic diagram of a version synchronization diagnosis service request for step S510 in

[0034] Figure 6 For this application Figure 4 It is an exemplary schematic diagram of obtaining an installation authorization license for step S530 in

[0035] Figure 7 For this application Figure 6 It is an exemplary schematic diagram of step S710 in

[0036] Figure 8 For this application Figure 4 An exemplary schematic diagram of step S530 in this application;

[0037] Figure 9 Shows a hardware architecture diagram of an exemplary OTA pressure test method;

[0038] Figure 10 Shows a schematic structural diagram of a computer system suitable for implementing the embodiments of this application. Specific implementation manners

[0039] The following uses specific specific examples to illustrate the implementation manners of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other. It should also be understood that the terms used in the embodiments of the present invention are for describing specific specific implementation manners, rather than for limiting the protection scope of the present invention. The test methods without specific conditions noted in the following embodiments are usually in accordance with conventional conditions or in accordance with the conditions recommended by each manufacturer.

[0040] When an embodiment gives a numerical range, it should be understood that unless otherwise stated in the present invention, any numerical value between the two endpoints of each numerical range and any one of the two endpoints can be selected. Unless otherwise defined, all technical and scientific terms used in the present invention are the same as those mastered by those skilled in the art of the present technology field and the description of the present invention. Any methods, devices, and materials of the prior art similar to or equivalent to the methods, devices, and materials described in the embodiments of the present invention can also be used to implement the present invention.

[0041] It should be noted that the terms such as "upper", "lower", "left", "right", "middle", and "one" cited in this specification are only for the convenience of clear narration, rather than for limiting the scope of implementation of the present invention. The change or adjustment of their relative relationships, without substantial change in technical content, should also be regarded as the scope of implementation of the present invention.

[0042] OTA refers to over-the-air technology. Automotive OTA can remotely manage software through the interface of mobile communication. In the early days, OTA technology was widely used in the software upgrade of smart phones. Later, automotive OTA technology was introduced in 2012, which promoted the development of the automotive industry.

[0043] The upgrade of automotive OTA is similar to the upgrade of computer Windows systems or mobile phone systems. Each upgrade can improve, fix bugs, or obtain more functions, performance, and visual effects enhancements. Since the emergence of automotive OTA technology, 4S stores are no longer a must in the automotive upgrade process.

[0044] Now many automotive companies attach great importance to automotive OTA technology. The current automotive OTA technology is also applied in various maps, applications, and entertainment information systems, etc., and has even developed to the electronic control unit. However, the automotive industry is different from other industries. Automobiles need to have a certain level of safety. If there are problems with OTA technology, it is very likely to lead to serious safety accidents. The reliability and stability of the technology must be fully verified before being put on the market, including component verification of key controllers and system integration verification. And the only way to ensure this is through complete test verification of the OTA solution.

[0045] Please refer to Figure 1 , Figure 1 The exemplary schematic diagram of the existing technology OTA system test.

[0046] Automotive OTA upgrade modifies and upgrades the entertainment or electronic control unit of the vehicle after obtaining the upgrade package through wireless signal transmission. Existing OTA test solutions have many limitations and bottlenecks. The current solutions basically adopt non-automated test verification methods, that is, manual test verification by investing human resources. This not only brings a large amount of labor costs, but also because the link tests of OTA all involve downloading and installation, these two steps take a lot of time, ranging from dozens of minutes to several hours. The consequence of this is that the input and output are not proportional. Secondly, the current OTA tests are completed through manual or semi-automatic tests, with low coverage and poor reliability of the results. They cannot cover various scenarios in real vehicles. Some specific scenarios cannot be satisfied in the manual or semi-automatic test environment and can only be achieved through automated tests in a simulation manner. In addition, the accuracy of many test parameters during the test process needs to be completed through precise timers and cannot be achieved manually or semi-automatically.

[0047] This application can automatically implement OTA stress testing. In one test, only need to write the test file once to achieve flashing different versions to the ECUs (Electronic Control Unit) of different test benches, or can flash the same test bench's ECUs multiple times repeatedly, or can flash different versions to the same ECU, so as to meet the requirements of OTA system stress testing.

[0048] Please refer to Figure 2 , Figure 2It is a schematic diagram of an OTA automated test system, which is described in detail as follows:

[0049] The OTA automated test system includes a test management system, a test execution system, a system under test, and a wireless emulation system;

[0050] The test management system is the window for users to perform automated test operations, with functions such as login, permission control, test case selection, parameter configuration, test report, and test log management; the test execution system is mainly responsible for executing test cases, including power control, I / O signal emulation, message monitoring, message emulation, fault injection, and operation control of the HMI; the system under test is composed of a T-Box, CGW, HMI, ETH / CAN nodes, and their affiliated ECUs that make up the OTA functional logic, and they are integrated onto a test bench; the wireless signal emulation system is composed of a Keysight UXM synthesizer tester and a channel emulator, and its main purpose is to "move" the real external wireless network signal to the laboratory to replace the in-vehicle road test.

[0051] From the perspective of the sorting efficiency of OTA stress testing, an existing set of HIL test benches can only be docked with 1 Boxcar, and the Vector equipment used realizes the simulation and detection functions of CAN / CANFD / LIN / FlexRay / ETH through the combination of 1 VN1670, 1 VN7572, and 1 5650 in terms of hardware configuration. The combination of 1 VN1670, 1 VN7572, and 1 5650 allocates a total of 12 CAN buses, 2 CANFD buses, 10 LIN buses, 1 FlexRay bus, and 12 Ethernet buses compatible with 100BASE-T1 and 1000BASE-T1 interfaces. For most car manufacturers in the market, this configuration can only record and store most of the data of one vehicle or one Boxcar, and the coverage and efficiency are still not high enough to meet the sample quantity requirements of stress testing by far.

[0052] The present application provides a 1-to-N test system framework. By increasing the hardware facilities of the target under test without expanding the number of HIL benches themselves, one set of HIL benches can be docked with N target boxes under test (Boxcar) to achieve parallel testing, thereby expanding the sample size of stress testing and improving the stress testing efficiency. Here, only an example of a certain OTA automated stress testing solution is given, that is, one set of HIL benches is docked with 5 Boxcars. For each Boxcar corresponding to the solution of the present invention, the Vector devices used implement the simulation and detection functions of CAN / CANFD / LIN / FlexRay / ETH through the combination of one VN5650 and two VN7572. One VN5650 and two VN7572 are allocated a total of 10 CAN buses, 2 CANFD buses, 5 LIN buses, 1 FlexRay bus, and 12 Ethernet buses compatible with 100BASE-T1 and 1000BASE-T1 interfaces. Then, the data of the 5 Boxcars are captured in parallel into the CANoe Agent, synchronized by the CANoe Agent and uploaded to the test management software, and the overall stress testing results are reflected in the test management software, finally achieving parallel testing and outputting a test report. Please refer to Figure 3 , Figure 3 which is a schematic diagram of an exemplary OTA stress testing method of the present application, and is specifically introduced as follows:

[0053] Step S410, in response to the test start program, read the test configuration file of the test start program.

[0054] Before the test, write the test configuration file. The test configuration file includes all configuration parameters of this test, such as which target modules under test need to be tested in this test, test cases for each target module under test, configured ECU combinations, test baselines, etc. By writing the test configuration file once, multiple target modules can be combined arbitrarily, thereby increasing the number of OTA tests and meeting the sample requirements of OTA stress testing.

[0055] Step S420, generate multiple upgrade task packages according to the parameters of the test configuration file, and distribute them to the target modules under test specified by the upgrade task packages respectively.

[0056] Generate multiple upgrade task packages according to the parameters of the test configuration file. Each upgrade task package corresponds to one target module under test, and each upgrade task package is sent to the corresponding target module under test, so as to facilitate the simultaneous testing of multiple target modules with the same or different tests.

[0057] In an exemplary embodiment of the present application, the test configuration file parameters are read by the test management software. The test management software generates multiple corresponding upgrade task packages according to the test configuration file parameters and the control OTA server, and distributes the upgrade task packages to the corresponding modules under test respectively, so as to realize the separate testing of multiple modules under test at one time, effectively increasing the number of test samples.

[0058] Step S430: Perform repeated ECU flashing according to the upgrade task package until the cumulative test times reach the preset test times.

[0059] It should be noted that each upgrade task package corresponds to a module under test, and each module under test independently performs repeated ECU flashing. The modules under test are independent of each other. The failure of any module under test to be flashed does not affect other modules under test, and the reason for the flashing failure will be described in the test report.

[0060] Please refer to Figure 4 , Figure 4 for an exemplary schematic diagram of step S430 in the present application, and the method of repeated ECU flashing is introduced as follows: Figure 3

[0061] Step S510: Trigger a version synchronization diagnostic service request.

[0062] Before the module under test is flashed, it is necessary to first perform version synchronization diagnosis, and the flashing test can only be performed when the versions are consistent.

[0063] Please refer to Figure 5 , Figure 5 for an exemplary schematic diagram of the version synchronization diagnostic service request of step S510 in the present application, Figure 4 which introduces an exemplary version synchronization diagnostic service request, and the specific process is as follows: Figure 5

[0064] First is the gateway controller reset request;

[0065] Enter the extended session request;

[0066] The version synchronization operation instruction of the gateway;

[0067] Press the brake pedal;

[0068] Set the gear position to D gear;

[0069] Press the P gear button. It should be noted that for some vehicle models, the P gear and the handbrake are the same button, and for some vehicle models, the P gear and the handbrake are different buttons. For vehicle models with different buttons, the program of pressing the handbrake button also needs to be added at this time.

[0070] ​​The above state is maintained until the preset time. For the convenience of testing, the preset time can be selected from 2 to 5 minutes, preferably 3 minutes.

[0071] In an exemplary embodiment of the present application, after triggering the version synchronization diagnostic service request, the host will open a new thread to periodically check the version synchronization status of the WEB server. If the query result within the version synchronization check time is a synchronization NOK status, it is determined that the vehicle and the cloud cannot synchronize versions, and a specific abnormal prompt is issued, such as Reset failure, inability to enter the extended diagnostic session, routine control negative response, etc. The version synchronization check time is freely set by the system. In order to improve the test efficiency, 3 to 5 minutes can be selected.

[0072] Step S520, obtain download authorization, installation instructions and software upgrade package.

[0073] In one embodiment of the present application, the module under test obtains the download authorization license, including activating the authorization download button on the DHU (Driver Head Unit, an integrated machine of the entertainment host and the instrument), and controlling the DHU to automatically trigger the authorization download button to be pressed through the ADB (Android Debug Bridge), which is equivalent to the user pressing the authorization download button, that is, the user gives the download authorization license. After obtaining the download authorization license, the OTA server downloads the installation instructions and the software upgrade package, which is one of the upgrade task packages.

[0074] Step S530, obtain installation authorization and flash each corresponding ECU according to the installation instructions.

[0075] It should be noted first that the software upgrade package is written into the ECU to achieve the version upgrade of the ECU.

[0076] Please refer to Figure 6 , Figure 6 For this application Figure 4 Step S530 in is an exemplary schematic diagram of obtaining installation authorization.

[0077] Step S710, receiving a software upgrade package.

[0078] The module under test first obtains the software upgrade package issued. Security verification is required in the process of obtaining the software upgrade package to ensure the information security of users or manufacturers, including security verification of communication encryption before receiving the software upgrade package;

[0079] Perform data frame anomaly detection when receiving software upgrade packages;

[0080] After receiving the software upgrade package, the OTA upgrade package signature is verified to ensure the security of the information.

[0081] Step S720: Activate the update button on the DHU.

[0082] In the embodiment of the present application, activating the update button on the DHU is equivalent to sending a update prompt to the customer during the actual OTA update. If the customer clicks the update button, it means that the user permits the update. If the user does not click or clicks "No", it means that the user does not need to upgrade for the time being, and the upgrade reminder instruction is retained.

[0083] Step S730: Use ADB to control the DHU to automatically trigger the pressing of the update button.

[0084] The host computer uses ADB to control the DHU to automatically trigger the pressing of the update button, which is equivalent to the user pressing it, giving authorization for installation.

[0085] It should also be noted that various processes need to be carried out during the flashing of the ECU. Please refer to Figure 8 , Figure 8 This is Figure 4 an exemplary schematic diagram of step S530 in the present application. The specific flashing process is as follows;

[0086] Step S910: Verify the conditions before flashing. The condition verification includes positive condition verification and reverse condition verification.

[0087] Step S920: Process during flashing. The process during flashing includes verification of diagnostic request format and sequence, inversion of flashing conditions, fault injection, and verification of flashing exception handling mechanism.

[0088] Step S930: Process after flashing. The process after flashing includes confirmation of ECU status and recording of sleep mechanism.

[0089] The above processing procedures can all be written into the test report for testers' reference.

[0090] Please continue to refer to Figure 4 , step S540: Obtain a rollback operation request and perform ECU flashing for local rollback, and increment the cumulative test count by one.

[0091] After a single test is completed, obtain a rollback operation request and perform ECU flashing for local rollback, so that the ECU is restored to its initial state to ensure version synchronization during the next test and avoid the influence of this test case on the next test.

[0092] Step S550: Obtain the cumulative test count. According to the cumulative test count, repeat the above steps until the cumulative test count reaches the preset test count.

[0093] When issuing the upgrade task package, the test cases, test times, and test combinations for each test bench are described. When the cumulative number of test times reaches the preset number of test times, the test of this test bench ends.

[0094] It should be noted that the preset number of test times can be one, that is, the test stops when this number is reached. The preset number of test times can also be multiple. Different preset numbers of test times represent different upgrades. Assume that this test bench is in version A, and the two preset numbers of test times are 500 and 1000 respectively. Assume that when the cumulative number of test times is less than 500, the ECU of this test bench is upgraded from version A to version B. When the cumulative number of test times is greater than or equal to 500 and less than 1000, the ECU of this test bench is upgraded from version A to version C. When the cumulative number of test times is equal to 1000, the test stops. Thus, the change of the test version can be realized. Only one test is required to meet various test combinations, which is convenient and simple, saves test time, and increases the number of test samples.

[0095] Please continue to refer to Figure 3 , step S440, obtain the test results of each of the measured modules, and generate a test report according to the test results.

[0096] It should be noted that the test results of each measured module are independent. A test report can be generated independently for each measured module, or a test report can be generated by multiple measured modules. This application does not make any restrictions on this.

[0097] In an embodiment of the present application, bus test data, diagnostic test data, electrical test data, etc. during the test process can be transmitted to the server by means of file transfer, and the data is associated with specific tasks and use cases. Request to view the current test message from the server, the proxy engine accepts the request and reads the data, then calls the CAPL script through CANoe to implement data parsing, and then feedbacks the parsing result. The same method is used for listening to messages and terminating listening.

[0098] An embodiment of the present application also shows an OTA stress test system, including a test management module. The test management module reads a test configuration file, controls the generation of multiple upgrade task packages according to the test configuration file, and distributes the upgrade task packages to the measured modules specified by the upgrade task packages respectively.

[0099] Measured module, one test management module corresponds to one or more measured modules; the measured module triggers a version synchronization diagnostic service request, obtains a download authorization license, then obtains an installation instruction manual and a software upgrade package, and performs flashing on the corresponding ECU according to the installation instruction manual after obtaining an installation authorization license; performs a local rollback after obtaining a rollback operation request, and increments the cumulative number of test times by one; obtains the cumulative number of test times and performs repeated tests;

[0100] After the cumulative test times of each of the modules under test reach the preset test times, the test management module obtains the test results of each of the modules under test and generates a test report based on the test results.

[0101] In one embodiment, a wireless information simulation module is also included. The wireless signal simulation module is composed of a Keysight UXM comprehensive tester and a channel simulator. The main purpose is to "move" the real wireless network signal from the outside world to the laboratory to replace the actual vehicle road test.

[0102] It should be noted that the OTA stress test system provided in the above embodiment and the OTA stress test method provided in the above embodiment belong to the same concept, and the specific way in which each module and unit performs the operation has been described in detail in the method embodiment, which will not be repeated here. In actual application, the OTA stress test system provided in the above embodiment can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0103] Please refer to Figure 9 , Figure 9 Shows a hardware architecture diagram for implementing an OTA stress test method. Through the host computer, the HIL bench dynamically tests according to the sequence and configuration issued, and then automatically controls in parallel to achieve simulation tests of multiple / multiple real vehicle configurations and scenarios, efficiently achieve certain stress test goals, and expose OTA link problems. After the test is completed, the CANoe system variables are used to monitor the number of test case executions, and the CANoe system variables are read by the system to achieve the effect of monitoring the execution of test cases, and the final data is transmitted back to the system.

[0104] In one embodiment of the present application, the test task is executed through the actual test plan. Before the test is executed, the test project needs to be selected. The system will call the proxy engine according to the corresponding relationship to execute the test. At the end of the test execution, when the server receives the test result data, it generates a test report with the result data, and records the test process data and result data for statistical analysis.

[0105] The bus test data, diagnostic test data, electrical test data, etc. during the test process can be transmitted to the server through file transfer, and the data can be associated with specific tasks and use cases. The server requests to view the current test message, the proxy engine accepts the request and reads the data, and then uses CANoe to call the CAPL script to implement data parsing, and then feedback the parsing results. The same method is used to monitor messages and terminate monitoring.

[0106] An embodiment of the present application also shows an electronic device, which includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device implements the OTA stress test method as described in any one of the above.

[0107] Figure 10 The structural schematic diagram of a computer system suitable for implementing the electronic device of the embodiment of the present application is shown. It should be noted that Figure 10 The computer system of the shown electronic device is only an example and should not bring any limitations to the functions and usage scope of the embodiments of the present application.

[0108] As Figure 10 shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage section 1208 into the random access memory (RAM) 1203, such as executing the method described in the above embodiments. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other via a bus 1204. The input / output (I / O) interface 1205 is also connected to the bus 1204.

[0109] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. The drive 1210 is also connected to the I / O interface 1205 as required. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as required, so that the computer program read from it can be installed into the storage section 1208 as required.

[0110] In particular, according to an embodiment of the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product that includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 1209, and / or installed from the removable medium 1211. When the computer program is executed by the central processing unit (CPU) 1201, various functions defined in the system of the present application are executed.

[0111] An embodiment of the present application shows a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor of the computer, the computer is made to execute the OTA stress test method described in any one of the above.

[0112] An OTA stress test method of the present application. The characteristics of OTA automated testing are reflected in that testers can flexibly select a set of test cases and submit them to the test system. The test system can automatically execute the corresponding test scripts according to the test cases submitted by the testers, and finally output a test report, which includes test preconditions, detailed test steps and the expected results of each step. If a test failure item is encountered, possible failure reasons can be given based on the test steps and the information returned by this step to help testers define the problem boundary and even locate the root cause of the problem.

[0113] In order to ensure that the test cases can run independently, it is necessary to cooperate with the cloud and vehicle sides to synchronously restore the OTA initial state to ensure that the execution of the next use case is not interfered by the remaining tasks in the previous use case, so that each use case runs independently.

[0114] The OTA test contents in different stages are quite different, and may involve single-piece testing, system testing, software package stress testing, etc. By changing the configuration conditions of the test system and adapting some software modules, the OTA test can be connected at different stages.

[0115] Therefore, the present invention effectively overcomes some practical problems in the prior art and thus has high utilization value and practical significance. The above embodiments are only illustrative of the principles and effects of the present invention, and are not used to limit the present invention. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical idea disclosed by the present invention should still be covered by the claims of the present invention.

Claims

1. An OTA stress testing method, characterized in that: include: In response to the test startup program, read the test configuration file of the test startup program; Generate multiple upgrade task packages according to the test configuration file parameters, and send them to the tested modules specified by the upgrade task packages respectively; Repeatedly flash the ECU according to the upgrade task package until the cumulative number of tests reaches the preset number of tests; Obtain the test results of each of the tested modules, and generate a test report based on the test results.

2. The OTA stress testing method according to claim 1, characterized in that: Generating multiple upgrade task packages according to the test configuration file parameters and sending them to the tested modules specified by the upgrade task packages respectively, including: Generating a plurality of the upgrade task packages with codes according to the test configuration file parameters; According to the codes of the upgrade task packages, the upgrade task packages with different codes are respectively sent to the tested modules preset with different numbers.

3. The OTA stress testing method according to claim 1, characterized in that: Repeat the ECU flashing according to the upgrade task package until the cumulative number of tests reaches the preset number of tests, including: Trigger version synchronization diagnostic service request; Obtain download authorization, installation instructions and software upgrade packages; Obtain installation authorization and flash the corresponding ECUs according to the installation instructions; Obtain a rollback operation request, perform a local rollback ECU flash, and increase the cumulative number of tests by one; Obtain the cumulative number of tests, and repeat the above steps according to the cumulative number of tests until the cumulative number of tests reaches the preset number of tests.

4. The OTA stress testing method according to claim 3, characterized in that: Triggering a version synchronization diagnostic service request. The instruction process includes: Gateway controller reset request; Enter extended session request; Gateway version synchronization instruction operation; The brake pedal is depressed; The gear position is D; Press the P gear button; The above state is maintained until the preset time.

5. The OTA stress testing method according to claim 4, characterized in that: Open a new thread and periodically check the version synchronization status. If the query result within the version synchronization checking time is a synchronization NOK status, it is determined that the version synchronization cannot be achieved and a specific exception prompt is issued.

6. The OTA stress testing method according to claim 3, characterized in that: Obtain installation authorization, including: Receive software upgrade packages; Activate the update button on the DHU; Control the DHU via ADB to automatically trigger an update when the upgrade button is pressed.

7. The OTA stress testing method according to claim 6, characterized in that: Receive software upgrades including: Perform security verification of communication encryption before receiving software upgrade packages; Perform data frame anomaly detection when receiving software upgrade packages; After receiving the software upgrade package, perform OTA upgrade package signature security verification.

8. An OTA stress testing system, characterized in that: include: A test management module, wherein the test management module reads a test configuration file, controls the generation of multiple upgrade task packages according to the test configuration file, and sends the upgrade task packages to the tested modules specified by the upgrade task packages respectively; Tested module, one test management module corresponds to one or more tested modules; the tested module triggers a version synchronization diagnostic service request, obtains the installation instructions and software upgrade package after obtaining the download authorization license, and flashes each corresponding ECU according to the installation instructions after obtaining the installation authorization license; performs local rollback after obtaining the rollback operation request, and the cumulative test times are increased by one; obtains the cumulative test times and performs repeated tests; After the accumulated test times of each of the modules under test reach the preset test times, the test management module obtains the test results of each of the modules under test and generates a test report according to the test results.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the OTA stress testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is enabled to execute the OTA stress testing method according to any one of claims 1 to 7.

Images