Vehicle OTA upgrade test control method and device

Abstract

The invention relates to the technical field of vehicle control, and provides a control method and device for a vehicle OTA upgrade test. The method comprises the following steps: in response to an OTA test request of a vehicle, verifying a Boot shared variable; determining that the Boot shared variable is successfully verified, and performing memory access to obtain diagnosis information; controlling the vehicle to execute an OTA upgrade test according to the diagnosis information; wherein the Boot shared variable is data created and initialized by a boot loader in a starting stage. According to the control method for the vehicle OTA upgrade test provided by the embodiment of the invention, the situation that the OTA test of the vehicle is influenced by memory access abnormity caused by erasing of the boot loader can be reduced, and the safety of the vehicle OTA upgrade test is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle control, in particular to a control method and device for vehicle OTA upgrade test. BACKGROUND

[0002] OTA (Over the Air) of a vehicle refers to remote upgrade of the vehicle, which pushes software updates to the vehicle to be upgraded through remote connection to the networked vehicle, so as to realize remote upgrade of the vehicle.

[0003] To ensure that the vehicle can normally perform OTA upgrade, OTA upgrade test usually needs to be performed in the vehicle test phase. In the related art, when the vehicle needs to perform OTA upgrade test, the electronic control unit that needs to perform software or program update of the vehicle first reads diagnostic information from the memory storing the bootloader and its version information, such as reading the version information of the bootloader, to perform OTA upgrade test based on the read diagnostic information. However, if the bootloader is erased at this time, it will cause memory access exception, and the diagnostic information cannot be obtained, resulting in crash of the running program of the OTA upgrade test, affecting the safety of the vehicle OTA upgrade test. SUMMARY

[0004] The present application aims to at least solve one of the technical problems in the related art. To this end, the present application provides a control method for vehicle OTA upgrade test, which can reduce the influence of memory access exception caused by erasing the bootloader on the vehicle OTA test, and improve the safety of the vehicle OTA upgrade test.

[0005] The control method for vehicle OTA upgrade test according to the first aspect of the present application comprises: In response to an OTA test request of the vehicle, checking a Boot shared variable; If the Boot shared variable is checked successfully, performing memory access to obtain diagnostic information; Controlling the vehicle to perform OTA upgrade test according to the diagnostic information; The Boot shared variable is data created and initialized by the bootloader in the startup phase.

[0006] The Boot shared variable is checked first when the vehicle receives an OTA test request. If the Boot shared variable is successfully checked, memory access is performed to obtain diagnostic information, and the vehicle is controlled to perform OTA upgrade testing according to the diagnostic information. Since the Boot shared variable is data created and initialized by the bootloader in the startup stage, if the bootloader is not erased, the Boot shared variable exists and can be successfully checked. Therefore, if the Boot shared variable is successfully checked, it indicates that the bootloader is not erased, and then memory access is performed and OTA testing is performed, thereby preventing memory access anomalies caused by erasing the bootloader, and reducing the impact of memory access anomalies caused by erasing the bootloader on vehicle OTA testing, and improving the safety of vehicle OTA upgrade testing.

[0007] According to one embodiment of the present application, further comprising: Determine that the Boot shared variable check fails, and prohibit memory access.

[0008] According to one embodiment of the present application, after prohibiting memory access, further comprising: Control the vehicle to perform OTA upgrade testing according to the preset safety value.

[0009] According to one embodiment of the present application, further comprising: During the OTA upgrade testing, control the DTC record control function of the vehicle to switch to a silent state.

[0010] According to one embodiment of the present application, further comprising: In the case that the OTA upgrade testing exits, detect the DTC record control function of an electronic control unit involved in the OTA upgrade testing; Determine that the enable state of the DTC record control function is not enabled, and stop recording fault codes of the electronic control unit.

[0011] According to one embodiment of the present application, further comprising: Determine that the enable state of the DTC record control function is enabled, and start recording diagnostic fault codes of the electronic control unit.

[0012] According to one embodiment of the present application, further comprising: Obtain the transmission path of each test signal issued under the OTA upgrade testing; According to the transmission path of each test signal, obtain a detection result representing the correctness of signal routing of the vehicle in the OTA upgrade process.

[0013] According to one embodiment of the present application, the detection result characterizing the correctness of signal routing of the vehicle during the OTA upgrade process is obtained according to the transmission path of each test signal, including: It is determined that the transmission path of any test signal matches the preset transmission path of the test signal, and the detection result is that the signal routing of the vehicle during the OTA upgrade process is correct.

[0014] According to the control device of the vehicle OTA upgrade test of the second aspect of the present application, it comprises: The variable verification module is configured to verify the Boot shared variable in response to the OTA test request of the vehicle. The information acquisition module is configured to access the memory to obtain the diagnostic information when the Boot shared variable verification is successful. The vehicle control module is configured to control the vehicle to perform the OTA upgrade test according to the diagnostic information. The Boot shared variable is data created and initialized by the boot loader in the startup phase.

[0015] According to the electronic device of the third aspect of the present application, the processor executes the computer program to realize the control method of the vehicle OTA upgrade test of any one of the above embodiments.

[0016] According to the computer readable storage medium of the fourth aspect of the present application, the computer program is stored thereon, and the computer program is executed by the processor to realize the control method of the vehicle OTA upgrade test of any one of the above embodiments.

[0017] According to the computer program product of the fifth aspect of the present application, the computer program is stored thereon, and the computer program is executed by the processor to realize the control method of the vehicle OTA upgrade test of any one of the above embodiments.

[0018] According to the vehicle of the sixth aspect of the present application, it comprises the electronic device of the third aspect of the above embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0020] Figure 1 is the first flowchart of the control method of the vehicle OTA upgrade test provided by the embodiments of the present application; Figure 2 is a second flowchart of a control method of vehicle OTA upgrade testing provided by an embodiment of the present application; Figure 3 is a structural diagram of a control device of vehicle OTA upgrade testing provided by an embodiment of the present application; Figure 4 is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] For the purpose, technical solutions and advantages of the present application to be clearer, the technical solutions in the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0022] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the meaning of "multiple" is more than two, unless otherwise explicitly and specifically limited.

[0023] In this document, the reference to "embodiments" means that the specific features, structures or properties described in conjunction with the embodiments can be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily mean that it refers to the same embodiment, nor is it independent or alternative to other embodiments. The skilled person in the art explicitly and implicitly understands that the embodiments described herein can be combined with other embodiments.

[0024] In the description of the embodiments of the present application, the term "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this document generally represents an "or" relationship between the associated objects before and after it.

[0025] In the description of the embodiments of the present application, the term "multiple" refers to more than two (including two), and similarly, "multiple groups" refers to more than two groups (including two groups), and "multiple pieces" refers to more than two pieces (including two pieces).

[0026] The OTA (Over the Air) upgrade of the vehicle refers to the remote upgrade of the vehicle, that is, the remote software or firmware upgrade of the vehicle through a wireless network. The OTA upgrade remotely connects the networked vehicle through the wireless network and pushes the software update to the vehicle to be upgraded, thereby realizing the remote upgrade of the vehicle. Through the OTA upgrade, the original equipment manufacturer can remotely connect the networked vehicle without going through the after-sales service center, and push the software or program update to the vehicle to be upgraded.

[0027] To ensure that the vehicle can normally perform the OTA upgrade, it is usually necessary to perform the OTA upgrade test during the vehicle test phase. In the related art, when the vehicle needs to perform the OTA upgrade test, the electronic control unit that needs to perform the software or program update of the vehicle reads the diagnostic information from the memory in which the bootloader and the version information thereof are stored, for example, reads the version information of the bootloader, to perform the OTA upgrade test based on the read diagnostic information. However, the bootloader may be erased during the OTA upgrade test. For example, the bootloader can be erased and the region can be inaccessible when the debugger is used for writing during the development, test, and calibration process of the electronic control unit of the vehicle. If the bootloader is erased at this time, when the diagnostic information reading, such as DID-F180, is called, the running program of the OTA upgrade test enters the Trap state of the abnormal access of the memory, the diagnostic information cannot be obtained, the running program of the OTA upgrade test crashes, and the safety of the OTA upgrade test of the vehicle is affected.

[0028] To solve the above technical problems, the embodiment of the present application first verifies the Boot shared variable when the OTA test request of the vehicle is received. If the Boot shared variable is verified successfully, the memory is accessed to obtain the diagnostic information, and the vehicle is controlled to perform the OTA upgrade test according to the diagnostic information. Since the Boot shared variable is the data created and initialized by the bootloader during the startup stage, if the bootloader is not erased, the Boot shared variable exists and can be successfully verified. Therefore, if the Boot shared variable is verified successfully, it indicates that the bootloader is not erased, and then the memory is accessed and the OTA test is performed, thereby preventing the abnormal memory access caused by the erasure of the bootloader, reducing the influence of the abnormal memory access caused by the erasure of the bootloader on the OTA test of the vehicle, and improving the safety of the OTA upgrade test of the vehicle.

[0029] According to some embodiments of the present application, the embodiments of the present application provide a control method for vehicle OTA upgrade test, which can be applied to a controller for realizing control of vehicle OTA upgrade test. The controller can include a VCU (Vehicle Control Unit), an MCU (Microcontroller Unit), an ECU (Electronic Control Unit) and / or other vehicle terminal, etc.

[0030] As shown in Figure 1 The control method for vehicle OTA upgrade test includes the following steps: S101, in response to an OTA test request of a vehicle, checking a Boot shared variable; S102, determining that the Boot shared variable is checked successfully, performing memory access, and obtaining diagnostic information; S103, controlling the vehicle to perform OTA upgrade test according to the diagnostic information; The Boot shared variable is a data created and initialized by a bootloader in a startup phase.

[0031] In some embodiments, the bootloader refers to a core underlying firmware stored in the controller (such as an ECU), which is first run after the system is powered on, is responsible for initializing hardware, verifying the integrity and authenticity of application firmware, and finally transferring control to the main program. It is the root of trust in the system startup chain, and is the basis for ensuring the safe and reliable execution of subsequent OTA upgrade test processes.

[0032] In some embodiments, the Boot shared variable is a data created and initialized by the bootloader in the startup phase, such as bootProgramInf or bootTesterSerialInf. It is usually stored in volatile memory. When the system is powered off or reset, these variables will be lost. Each time the system is cold started, the bootloader will be run again, and the Boot shared variable will be recreated and initialized. If the bootloader is erased, the Boot shared variable cannot be created and initialized during the startup process after the system is reset, so it can be preset that if the bootloader is erased, the Boot shared variable is all 0, i.e. all null values.

[0033] When receiving the OTA test request for the OTA upgrade test of the vehicle, the bootloader can be started in response to the OTA test request, at which time the Boot shared variable stored in the volatile memory is obtained, and the Boot shared variable is verified. If the Boot shared variable is not a null value, i.e., the Boot shared variable is not all 0, it can be determined that the Boot shared variable verification is successful, the bootloader has been successfully run and has not been erased, at which time memory access can be performed, the diagnostic information is read from the memory storing the bootloader and the version information of the bootloader, such as the version information of the bootloader, and the security access process of the OTA upgrade test is executed based on the read diagnostic information to continue executing the running program of the OTA upgrade test to control the vehicle to continue performing the OTA upgrade test. The security access process can be a security authentication protocol for verifying the authority of the operator, which requires that the test system must pass a key-based cryptographic challenge-response verification to obtain temporary permission to perform subsequent high-risk OTA test operations (such as writing to memory), to ensure that only authorized and legitimate test instruction sources (such as OTA servers or diagnostic tools in the cloud) can perform high-risk OTA test operations on vehicle electronic control units, thereby ensuring that only authorized parties can trigger the upgrade test and preventing unauthorized malicious access.

[0034] By verifying the Boot shared variable when receiving the OTA test request of the vehicle, if the Boot shared variable verification is successful, memory access is performed to obtain diagnostic information to control the vehicle to perform the OTA upgrade test according to the diagnostic information. Since the Boot shared variable is data created and initialized by the bootloader during the startup phase, if the bootloader is not erased, the Boot shared variable exists and can be successfully verified. Therefore, if the Boot shared variable verification is successful, it indicates that the bootloader has not been erased, at which time memory access is performed and the OTA test is performed, thereby preventing memory access anomalies caused by the bootloader being erased, and further reducing the impact of memory access anomalies caused by the bootloader being erased on the OTA test of the vehicle, and improving the security of the OTA upgrade test of the vehicle.

[0035] To further improve the security of the OTA upgrade test of the vehicle, in some embodiments, the method further comprises: determining that the Boot shared variable verification fails, and prohibiting memory access.

[0036] In some embodiments, if all Boot shared variables are found to be null (e.g., all values ​​are 0), it can be determined that the Boot shared variable verification has failed, and the bootloader in memory has been erased. In this case, memory access is prohibited. Prohibiting memory access can mean prohibiting access to the code area and register addresses of the bootloader corresponding to the Boot shared variable in memory—that is, the code area and register addresses of the bootloader of the electronic control unit requiring OTA upgrade testing—to avoid accessing invalid register addresses that could cause the running program to crash. This prevents memory access anomalies caused by the erased bootloader from affecting the vehicle's OTA testing, improving the safety of vehicle OTA upgrade testing.

[0037] To prevent the bootloader from being erased and thus preventing OTA upgrade testing of the vehicle, some embodiments, after disabling memory access, also include: The vehicle is controlled to perform OTA upgrade testing according to the preset safety value.

[0038] In some embodiments, a preset security value can be set in advance. This preset security value is a safe alternative to diagnostic information, such as ASCII "Failed". If the Boot shared variable verification fails, access to the code area and register address of the bootloader corresponding to the Boot shared variable in memory is prohibited. At the same time, the preset security value is returned to replace the diagnostic information, so that subsequent processes can continue to be executed according to the preset security value. That is, the safe access process continues to be executed according to the preset security value to control the vehicle to continue performing OTA upgrade testing. Thus, when the bootloader is erased, a reliable and simple pre-health check can be performed through the preset security value, guiding the OTA upgrade test program to continue execution from a certain and harmless path. This avoids the inability to perform OTA upgrade testing on the vehicle due to the erased bootloader, thereby improving both the security and reliability of vehicle OTA upgrade testing.

[0039] To avoid resource contention between the vehicle's DTC recording control function, such as Service85, and the OTA upgrade test during the OTA upgrade testing process, which could lead to errors in fault code recording, in some embodiments, the method further includes: During the OTA upgrade test, the DTC recording control function of the vehicle is switched to a silent state.

[0040] The DTC recording control function that switches to silent mode can be the DTC recording control function of all electronic control units in the vehicle, or the DTC recording control function of the electronic control unit that is being tested for OTA upgrade in the vehicle.

[0041] For example, during OTA upgrade testing, for electronic control units (ECUs) involved in the OTA upgrade test, their DTC recording control function can be controlled, such as Service85, to switch to a silent state, to prevent errors in fault code recording caused by the OTA upgrade test. For ECUs not involved in the OTA upgrade test, the current state of their DTC recording control function does not need to be switched.

[0042] To avoid system failures caused by fault code record conflicts during OTA upgrade testing, in some embodiments, the method further includes: If the OTA upgrade test is exited, the DTC recording control function of the electronic control unit involved in the OTA upgrade test is detected; If the DTC recording control function is determined to be disabled, the recording of fault codes for the electronic control unit will be stopped.

[0043] For example, the DTC recording control function can be Service85, where Service85 refers to the trigger switch used to remotely enable or disable the recording and storage of DTC (Diagnostic Trouble Code) functions within the electronic control unit.

[0044] In some embodiments, when the electronic control unit switches out of OTA mode (i.e., exits OTA), the system restores all normal functions, including continuous monitoring of system status and recording relevant diagnostic fault codes. The core function of the DTC recording control function is to temporarily suppress or enable DTCs. If the electronic control unit automatically enables DTC recording when exiting OTA mode, while the host computer diagnostic tool may still be executing or preparing to execute a test process that requires DTC suppression, the behavior of the electronic control unit will directly conflict with the instructions issued by the diagnostic tool through the service, leading to confusion in the control of the diagnostic session and unreliable test results. Therefore, a flag for enabling and disabling the DTC recording control function can be preset, such as setting the flag to 0 when enabling the DTC recording control function and setting it to 1 when disabling it.

[0045] When an OTA upgrade test exit is detected, the flag bit of the DTC recording control function of the electronic control unit involved in the OTA upgrade test can be checked to determine its enabled status. If the flag bit is 1, it can be determined that the enabled status is disabled. In this case, the DTC recording control function of the electronic control unit is judged to be in a disabled state, and fault code recording of the electronic control unit is stopped. This avoids system failure caused by fault code recording status conflicts due to OTA upgrade testing.

[0046] In some embodiments, the method further includes: If the DTC recording control function is determined to be enabled, the diagnostic fault code recording of the electronic control unit is enabled.

[0047] In some embodiments, if the flag bit of the DTC recording control function of the electronic control unit involved in the OTA upgrade test is detected to be 0, it can be determined that the DTC recording control function of the electronic control unit is disabled. At this time, it is determined that the DTC recording control function of the electronic control unit is enabled, and the fault code recording of the electronic control unit is started.

[0048] To further improve the reliability of vehicle OTA upgrade testing, in some embodiments, the method further includes: Obtain the transmission path of each test signal issued during the OTA upgrade test; Based on the transmission paths of each test signal, the detection results characterizing the correctness of signal routing during the OTA upgrade process of the vehicle are obtained.

[0049] In some embodiments, during the OTA upgrade test, multiple test signals, such as 0x4CC and 0x7DF, can be injected using Vector CANoe. At the same time, the transmission paths of each test signal issued by the OTA upgrade test can be obtained during the OTA upgrade test.

[0050] For any test signal's transmission path, its accuracy can be checked. If the transmission paths of all test signals are accurate, the signal routing correctness test result indicates that the vehicle's signal routing is correct during the OTA upgrade process; otherwise, the signal routing correctness test result indicates that the vehicle's signal routing is incorrect during the OTA upgrade process, and the erroneous transmission path can be located. This achieves routing detection during the OTA upgrade test process, improving the reliability of vehicle OTA upgrade testing.

[0051] In some embodiments, based on the transmission paths of each test signal, detection results characterizing the correctness of signal routing during the OTA upgrade process of the vehicle are obtained, including: If the transmission path of any of the test signals is determined to match the preset transmission path of the test signal, the detection result is that the signal routing of the vehicle is correct during the OTA upgrade process.

[0052] In some embodiments, a preset transmission path can be pre-set for any test signal. For example, the preset transmission path for test signal 0x4CC is: "Chassis CAN transmits 0x4CC → Private CAN receives"; the preset transmission path for test signal 0x7DF is: "Private CAN transmits 0x7DF → Lower-level device receives". After obtaining the transmission paths of each test signal issued by the OTA upgrade test, for any test signal, it can be checked whether the transmission path of the test signal is consistent with the preset transmission path corresponding to the test signal. If they are consistent, it can be determined that the transmission path of the test signal matches the preset transmission path corresponding to the test signal.

[0053] If the transmission path of any test signal matches the preset transmission path of that test signal, the test result indicates that the signal routing of the vehicle during the OTA upgrade process is correct; otherwise, the mismatched transmission paths can be located to improve the reliability of the vehicle OTA upgrade test.

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below. In some embodiments, such as Figure 2 As shown, the control method for this vehicle OTA upgrade test includes: S201, in response to the vehicle's OTA test request, verifies the Boot shared variables to determine if the verification was successful. If yes, proceed to S202; otherwise, proceed to S204. The Boot shared variables are data created and initialized by the bootloader during the startup phase. S202 performs memory access to obtain diagnostic information.

[0055] S203 controls the vehicle to perform OTA upgrade tests based on diagnostic information.

[0056] S204 prohibits memory access and controls the vehicle to perform OTA upgrade tests according to preset security values.

[0057] During the OTA upgrade test of S205, the DTC recording control function of the vehicle was switched to silent mode.

[0058] S206, If the OTA upgrade test is exited, check whether the DTC recording control function of the electronic control unit involved in the OTA upgrade test is enabled. If yes, proceed to S207; otherwise, proceed to S208.

[0059] S207, Enable recording of diagnostic fault codes for the electronic control unit.

[0060] S208, Stop recording fault codes for the electronic control unit.

[0061] S209. Based on the transmission paths of each test signal issued during the OTA upgrade test, the detection results characterizing the correctness of signal routing during the OTA upgrade process are obtained.

[0062] If the transmission path of any test signal matches the preset transmission path of the test signal, the detection result is that the signal routing of the vehicle during the OTA upgrade process is correct; otherwise, the detection result is that the signal routing of the vehicle during the OTA upgrade process is incorrect.

[0063] The control device for vehicle OTA upgrade testing provided in this application is described below. The control device for vehicle OTA upgrade testing described below can be referred to in correspondence with the control method for vehicle OTA upgrade testing described above.

[0064] In one embodiment, such as Figure 3 As shown, a control device for vehicle OTA upgrade testing is provided, comprising: The variable verification module 210 is used to verify Boot shared variables in response to the vehicle's OTA test request; Information acquisition module 220 is used to determine that the Boot shared variable verification is successful, perform memory access, and acquire diagnostic information; Vehicle control module 230 is used to control the vehicle to perform OTA upgrade test based on the diagnostic information; The Boot shared variables are data created and initialized by the bootloader during the startup phase.

[0065] Upon receiving an OTA test request from a vehicle, the system first verifies the Boot shared variables. If the Boot shared variables are successfully verified, memory access is then performed to obtain diagnostic information, which is used to control the vehicle to execute the OTA upgrade test. Since the Boot shared variables are data created and initialized by the bootloader during the startup phase, if the bootloader has not been erased, the Boot shared variables exist and can be successfully verified. Therefore, a successful Boot shared variable verification indicates that the bootloader has not been erased. Memory access and OTA testing are then performed, preventing memory access anomalies caused by bootloader erasure. This reduces the impact of memory access anomalies caused by bootloader erasure on vehicle OTA testing, improving the security of vehicle OTA upgrade testing.

[0066] In one embodiment, the information acquisition module 220 is further configured to: If the Boot shared variable verification fails, memory access is prohibited.

[0067] In one embodiment, the vehicle control module 230 is further configured to: After memory access is disabled, the vehicle is controlled to perform an OTA upgrade test according to the preset security value.

[0068] In one embodiment, the vehicle control module 230 is further configured to: During the OTA upgrade test, the DTC recording control function of the vehicle is switched to a silent state.

[0069] In one embodiment, the vehicle control module 230 is further configured to: If the OTA upgrade test is exited, the DTC recording control function of the electronic control unit involved in the OTA upgrade test is detected; If the DTC recording control function is determined to be disabled, the recording of fault codes for the electronic control unit will be stopped.

[0070] In one embodiment, the vehicle control module 230 is further configured to: Determine that the DTC recording control function is enabled, and start recording the diagnostic fault codes of the electronic control unit.

[0071] In one embodiment, the vehicle control module 230 is further configured to: Obtain the transmission path of each test signal issued during the OTA upgrade test; Based on the transmission paths of each test signal, the detection results characterizing the correctness of signal routing during the OTA upgrade process of the vehicle are obtained.

[0072] In one embodiment, the vehicle control module 230 is specifically used for: If the transmission path of any of the test signals is determined to match the preset transmission path of the test signal, the detection result is that the signal routing of the vehicle is correct during the OTA upgrade process.

[0073] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call a computer program in the memory 830 to execute a control method for vehicle OTA upgrade testing, such as including: In response to the vehicle's OTA test request, verify the Boot shared variables; Once the Boot shared variable verification is confirmed to be successful, memory access is performed to obtain diagnostic information. Based on the diagnostic information, control the vehicle to perform an OTA upgrade test; The Boot shared variables are data created and initialized by the bootloader during the startup phase.

[0074] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0075] On the other hand, this application embodiment also provides a storage medium, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the control method for vehicle OTA upgrade testing provided in the above embodiments.

[0076] On the other hand, this application also provides a computer program product that stores a computer program thereon. When the computer program is executed by a processor, the computer program product can execute the control method for vehicle OTA upgrade testing provided in the above embodiments.

[0077] In some embodiments, a vehicle is also provided, including electronic devices as provided in the above embodiments.

[0078] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A control method of a vehicle OTA upgrade test, characterized by, The method comprises: checking a Boot shared variable in response to an OTA test request of a vehicle; determining that the Boot shared variable is checked successfully, performing memory access, and obtaining diagnostic information; controlling the vehicle to perform an OTA upgrade test according to the diagnostic information; wherein the Boot shared variable is data created and initialized by a bootloader in a startup phase.

2. The control method of vehicle OTA upgrade test according to claim 1, characterized in that, The method further comprises: determining that the Boot shared variable is checked unsuccessfully, and prohibiting memory access.

3. The control method of vehicle OTA upgrade test according to claim 2, characterized in that, After prohibiting memory access, the method further comprises: controlling the vehicle to perform the OTA upgrade test according to the preset security value.

4. The control method of vehicle OTA upgrade test according to any one of claims 1-3, characterized in that, The method further comprises: controlling a DTC record control function of the vehicle to switch to a silent state during the OTA upgrade test.

5. The control method of vehicle OTA upgrade test according to claim 4, characterized in that, The method further comprises: detecting a DTC record control function of an electronic control unit involved in the OTA upgrade test in a case where the OTA upgrade test exits; determining that an enable state of the DTC record control function is disabled, and stopping recording of fault codes of the electronic control unit.

6. The control method of vehicle OTA upgrade test according to claim 5, characterized in that, The method further comprises: determining that the enable state of the DTC record control function is enabled, and starting recording of diagnostic fault codes of the electronic control unit.

7. The control method of vehicle OTA upgrade test according to any one of claims 1-3, 5-6, characterized in that, The method further comprises: obtaining a transmission path of each test signal issued in the OTA upgrade test; obtaining a detection result representing signal routing correctness of the vehicle in an OTA upgrade process according to the transmission path of each test signal.

8. The control method of vehicle OTA upgrade test according to claim 6, characterized in that, The detection result representing signal routing correctness of the vehicle in the OTA upgrade process according to the transmission path of each test signal comprises: determining that the transmission path of any test signal matches a preset transmission path of the test signal, and obtaining the detection result as the signal routing of the vehicle in the OTA upgrade process being correct.

9. A control device of a vehicle OTA upgrade test, characterized by, The method comprises: a variable checking module configured to check a Boot shared variable in response to an OTA test request of a vehicle; an information obtaining module configured to determine that the Boot shared variable is checked successfully, perform memory access, and obtain diagnostic information; a vehicle control module configured to control the vehicle to perform an OTA upgrade test according to the diagnostic information; wherein the Boot shared variable is data created and initialized by a bootloader in a startup phase.

10. An electronic device comprising a processor and a memory having a computer program stored therein, characterized in that, The processor executes the computer program to implement the control method of the vehicle OTA upgrade test according to any one of claims 1 to 8.

11. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the control method of the vehicle OTA upgrade test according to any one of claims 1 to 8.

12. A vehicle characterized by comprising: The vehicle comprises the electronic device according to claim 10.

Images