Fault recovery method and device before OTA upgrade, equipment and storage medium

Abstract

The invention discloses a fault recovery method and device before OTA upgrading, equipment and a storage medium, and relates to the technical field of OTA upgrading, and the method comprises the steps: obtaining an OTA upgrading file of the current OTA upgrading of a whole vehicle; target part information is determined according to the OTA upgrading file, and a fault detection request is generated according to the target part information; determining a diagnosis script according to the OTA upgrade file, and diagnosing the target part based on the diagnosis script to obtain a diagnosis result; and when the diagnosis result is that the target part is abnormal, determining an abnormal type, determining a recovery strategy according to the abnormal type, and carrying out fault recovery before OTA upgrading on the target part based on the recovery strategy, so that potential software problems possibly influencing the upgrading process and the system stability after upgrading can be identified, and the system stability can be improved according to the part version of the vehicle. Whether the fault version is a known fault version is judged, and the specific fault version is preprocessed before upgrading, so that the fault version is prevented from influencing upgrading of other ECUs.

Description

Technical Field

[0001] The present application relates to the field of OTA upgrade technology, and in particular to a fault recovery method, device, equipment and storage medium before OTA upgrade. Background Art

[0002] OTA (Over-The-Air) upgrade technology is a capability that allows remote updating of device software over wireless networks. In the automotive field, this technology allows vehicles to continue to receive new features and improvements even after they are delivered to users, without having to return to dealers or service centers. However, when performing OTA upgrades, there is currently no way to detect the upgrade environment before the OTA upgrade, so there may be situations that cause OTA upgrades to fail, resulting in the user's vehicle being unable to upgrade firmware or software, which in turn affects the user's driving experience and even increases the danger of vehicle driving.

[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0004] The main purpose of this application is to provide a fault recovery method, device, equipment and storage medium before OTA upgrade, aiming to solve the technical problem in the prior art that faults cannot be detected and recovered before OTA upgrade.

[0005] To achieve the above objectives, the present application proposes a fault recovery method before OTA upgrade, and the fault recovery method before OTA upgrade includes:

[0006] Get the OTA upgrade file of the current OTA upgrade of the vehicle;

[0007] Determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information;

[0008] Determine a diagnostic script according to the OTA upgrade file, diagnose the target part based on the diagnostic script, and obtain a diagnostic result;

[0009] When the diagnosis result indicates that an abnormality exists in the target part, the abnormality type is determined, a recovery strategy is determined according to the abnormality type, and fault recovery is performed on the target part before OTA upgrade based on the recovery strategy.

[0010] In one embodiment, the step of determining a diagnostic script according to the OTA upgrade file, diagnosing the target part based on the diagnostic script, and obtaining a diagnostic result includes:

[0011] Parsing the OTA upgrade file to obtain a diagnostic script;

[0012] Detecting whether the system file is abnormal based on the diagnostic script, and if so, returning a first diagnostic result;

[0013] When the system file is normal, detecting whether the key user data is abnormal, and if so, returning a second diagnosis result;

[0014] When there is no abnormality in the key user data, it is detected whether the ECU has a self-test fault, and if so, the third diagnostic result is returned, and if not, the fourth diagnostic result is returned.

[0015] In one embodiment, the step of detecting whether the system file is abnormal based on the diagnostic script, and if so, returning the first diagnostic result comprises:

[0016] Based on the diagnosis script, the system files are traversed in order according to the file sorting, and the md5 code of the system files is calculated;

[0017] Compare the md5 code of the system file with the md5 code of the system file recorded by the ECU to obtain a comparison result;

[0018] When the comparison results are inconsistent, it is determined that the system file is abnormal and the first diagnosis result is returned.

[0019] In one embodiment, when the system file is normal, detecting whether the key user data is abnormal, and if so, returning the second diagnosis result comprises:

[0020] When there is no abnormality in the system file, determining the file format of the key user data;

[0021] When the file format is a preset file format, detecting the data integrity of the key user data;

[0022] When the data integrity is incomplete, it is determined that the key user data is abnormal, and a second diagnosis result is returned.

[0023] In one embodiment, when the key user data is normal, detecting whether the ECU has a self-test fault, if so, returning the third diagnostic result, if not, returning the fourth diagnostic result, comprises:

[0024] When the key user data is normal, the ECU is made to perform a self-check according to the diagnostic script to obtain status data of the sensor;

[0025] The state data of the sensor is detected, and when abnormal state data is obtained, it is determined that the ECU has a self-test fault and a third diagnostic result is returned, otherwise a fourth diagnostic result is returned.

[0026] In one embodiment, when the diagnosis result is that the target part is abnormal, determining the abnormality type, determining a recovery strategy according to the abnormality type, and performing fault recovery on the target part before OTA upgrade based on the recovery strategy includes:

[0027] Determine an error code corresponding to the diagnosis result;

[0028] When the error code is the first error code, obtaining a starting packet of the ECU, flashing the ECU based on the starting packet, and performing fault recovery on the target part before OTA upgrade;

[0029] When the error code is the second error code, a component factory reset instruction is initiated to restore the component to a factory state, and the target component is restored to a fault state before an OTA upgrade;

[0030] When the error code is the third error code, an ECU restart instruction is received, and based on the ECU restart instruction, the ECU is powered off and then powered on to perform fault recovery on the target part before OTA upgrade.

[0031] In one embodiment, when the diagnosis result is that the target part is abnormal, determining the abnormality type, determining a recovery strategy according to the abnormality type, and performing fault recovery on the target part before OTA upgrade based on the recovery strategy also includes:

[0032] Detecting the target part version, and when the target part version is a specific version, decompressing the OTA upgrade file to obtain a preprocessing package;

[0033] The file data is transmitted to the ECU, so that the ECU is restarted;

[0034] When the ECU start signal is received, fault recovery is performed on the target part before OTA upgrade.

[0035] In addition, to achieve the above purpose, the present application also proposes a fault recovery device before OTA upgrade, and the fault recovery device before OTA upgrade includes:

[0036] The file loading module is used to obtain the OTA upgrade file of the current OTA upgrade of the vehicle;

[0037] A detection request module, used to determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information;

[0038] A fault detection module, used to determine a diagnosis script according to the OTA upgrade file, diagnose the target part based on the diagnosis script, and obtain a diagnosis result;

[0039] A fault recovery module is used to determine the type of abnormality when the diagnosis result shows that the target part has an abnormality, determine a recovery strategy according to the abnormality type, and perform fault recovery on the target part before OTA upgrade based on the recovery strategy.

[0040] In addition, to achieve the above-mentioned purpose, the present application also proposes a pre-OTA upgrade fault recovery device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the pre-OTA upgrade fault recovery method as described above.

[0041] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the fault recovery method before OTA upgrade as described above are implemented.

[0042] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the fault recovery method before OTA upgrade as described above.

[0043] One or more technical solutions proposed in this application have at least the following technical effects: by obtaining the OTA upgrade file of the current OTA upgrade of the whole vehicle; determining the target part information according to the OTA upgrade file, and generating a fault detection request according to the target part information; determining the diagnostic script according to the OTA upgrade file, diagnosing the target part based on the diagnostic script, and obtaining a diagnostic result; when the diagnostic result is that the target part is abnormal, determining the abnormality type, determining the recovery strategy according to the abnormality type, and performing fault recovery on the target part before the OTA upgrade based on the recovery strategy, it can identify potential software problems that may affect the upgrade process and the stability of the system after the upgrade. When a potential problem is detected, it can accurately analyze the cause of the problem and provide effective repair operations. At the same time, it can also determine whether it is a known fault version based on the vehicle's part version, and pre-process the specific fault version before the upgrade to prevent the fault version from affecting the upgrade of other ECUs. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0046] Figure 1 A flowchart of the first embodiment of the method for fault recovery before OTA upgrade of this application is provided;

[0047] Figure 2 A schematic diagram of the vehicle OTA software architecture provided for an embodiment of a method for fault recovery before OTA upgrade in this application;

[0048] Figure 3 An upgrade timing diagram for OTA upgrade provided in accordance with an embodiment of a method for fault recovery before OTA upgrade of the present application;

[0049] Figure 4 A diagnostic flow chart of a diagnostic script provided in an embodiment of a method for fault recovery before OTA upgrade of this application;

[0050] Figure 5 A pre-processing script flow chart provided for an embodiment of a method for fault recovery before OTA upgrade of this application;

[0051] Figure 6 This is a schematic diagram of the module structure of the fault recovery device before OTA upgrade in an embodiment of the present application;

[0052] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the fault recovery method before OTA upgrade in the embodiment of the present application.

[0053] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0054] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0055] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0056] The main solution of the embodiment of the present application is: obtain the OTA upgrade file of the current OTA upgrade of the whole vehicle; determine the target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information; determine the diagnosis script according to the OTA upgrade file, diagnose the target part based on the diagnosis script, and obtain a diagnosis result; when the diagnosis result is that the target part has an abnormality, determine the type of abnormality, determine a recovery strategy according to the abnormality type, and perform fault recovery on the target part before OTA upgrade based on the recovery strategy.

[0057] In this embodiment, for ease of description, the following description is made by taking the identification of a fault recovery device before OTA upgrade as the execution subject.

[0058] Since the existing technology does not have the ability to detect the upgrade environment before OTA upgrade, there is a possibility that the OTA upgrade may fail, resulting in the user's vehicle being unable to upgrade the firmware or software, which in turn affects the user's driving experience and even increases the risk of vehicle driving.

[0059] This application provides a solution. By implementing the technical solution of this embodiment, the reliability of the vehicle's OTA technology and user satisfaction can be significantly improved, problems introduced by software upgrades can be reduced, and the vehicle's intelligence level and user experience can be improved.

[0060] It can be seen from the above embodiments that the present application obtains the OTA upgrade file of the current OTA upgrade of the whole vehicle; determines the target part information according to the OTA upgrade file, and generates a fault detection request according to the target part information; determines the diagnostic script according to the OTA upgrade file, diagnoses the target part based on the diagnostic script, and obtains the diagnostic result; when the diagnostic result is that the target part is abnormal, determines the abnormality type, determines the recovery strategy according to the abnormality type, and performs fault recovery on the target part before the OTA upgrade based on the recovery strategy, which can identify potential software problems that may affect the upgrade process and the stability of the system after the upgrade. When a potential problem is detected, it can accurately analyze the cause of the problem and provide effective repair operations. At the same time, it can also determine whether it is a known fault version based on the vehicle's part version, and pre-process the specific fault version before the upgrade to prevent the fault version from affecting the upgrade of other ECUs.

[0061] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a fault recovery device before OTA upgrade, etc. The following takes the fault recovery device before OTA upgrade as an example to illustrate this embodiment and the following embodiments.

[0062] Based on this, the embodiment of the present application provides a fault recovery method before OTA upgrade, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the fault recovery method before OTA upgrade of the present application.

[0063] In this embodiment, the fault recovery method before OTA upgrade includes steps S10 to S40:

[0064] Step S10, obtaining the OTA upgrade file of the current OTA upgrade of the entire vehicle.

[0065] It should be noted that before the vehicle is upgraded OTA, the vehicle computer needs to register with the platform, download the vehicle model parts configuration, detect the version information of all parts of the vehicle, etc. After obtaining the corresponding vehicle model parts information, it can perform the whole vehicle OTA upgrade and obtain the OTA upgrade file. The OTA upgrade file includes various software packages, pre-processing software packages, diagnostic scripts, flashing scripts and other contents, which are not limited in this embodiment.

[0066] It should be understood that the OTA software structure of the whole vehicle can be described as four main components, namely OTA cloud, in-vehicle infotainment system (IVI), non-intelligent parts and intelligent parts. Figure 2 , Figure 2The following is a schematic diagram of the OTA software architecture of the whole vehicle. OTA cloud and cloud version server: unified management of vehicles, parts, upgrade tasks, and software versions. UC (OTA master control program): responsible for the OTA upgrade of all parts of the whole vehicle, including vehicle parts information query, task detection, download, upgrade, result reporting, etc. DPC (diagnostic flash module): for parts upgraded through CAN or Doip protocol, this module is responsible for its information collection, version flashing and other functions. OtaService (smart parts flashing): some smart parts such as in-vehicle infotainment system and in-vehicle wireless terminal do not support Doip upgrade conditions, and information collection and version flashing can be completed through this module. UPS (mqtt server process): provides the mqtt message communication mechanism between modules. OTA-UE (user interaction module): responsible for the display of the upgrade process, including version prompts, upgrade task prompts, upgrade progress prompts, and upgrade result display. IVI SocketServer (VHAL): a communication channel provided by the car service of the in-vehicle infotainment system, responsible for forwarding the message message of the OTA diagnostic flash module to the MCU. In-vehicle infotainment system MCU: The microcontroller program on the in-vehicle infotainment system is responsible for forwarding message messages to the GW (gateway) and for the communication between the gateway and the OTA diagnostic flashing module. GW (gateway): Responsible for forwarding CAN messages to designated parts. Upgrade task structure: In the cloud upgrade task, each ECU contains the starting software package, target software package, preprocessing software package, diagnostic script, preprocessing script, flashing script, etc.

[0067] In the specific implementation, in the process of obtaining the OTA upgrade file of the current OTA upgrade of the whole vehicle, it can be described as the user interaction module (User Experience, UE) sending the information of starting the upgrade to the OTA main control program on the vehicle side. After receiving the upgrade instruction, the OTA main control program on the vehicle side can keep the power of the vehicle computer in the ON state. At the same time, the smart component flashing module also transmits the information of keeping the power of the vehicle computer ON to the on-board wireless terminal (Telematics BOX, TBOX). At this time, the on-board wireless terminal can return the corresponding OTA file to the smart component flashing module, and then the smart component flashing module forwards it to the OTA main control program on the vehicle side.

[0068] Step S20, determining target part information according to the OTA upgrade file, and generating a fault detection request according to the target part information.

[0069] In the specific implementation, the OTA file is decompressed to determine the upgrade content and target parts, such as the engine control unit, infotainment system, battery management system, etc., and the information of the target parts is determined. Detailed information about the target parts is included in the upgrade file, including the part number, current firmware version, required new firmware version, and any specific parameters related to the upgrade, and a corresponding fault detection request is generated based on the target part information.

[0070] Step S30, determining a diagnostic script according to the OTA upgrade file, diagnosing the target part based on the diagnostic script, and obtaining a diagnostic result.

[0071] It should be noted that the diagnostic script is downloaded together with the upgrade task and cached in the OTA partition of the vehicle infotainment system, including the strategy for vehicle part detection before OTA upgrade. The diagnostic results include error codes and no-error codes during the diagnostic process.

[0072] In the specific implementation, refer to Figure 3 , Figure 3 This is the upgrade sequence diagram for OTA upgrade. When the task information and related upgrade files are downloaded, the OTA main control program on the vehicle side initiates a fault detection request to the OTA diagnostic flashing module based on the part information to be upgraded in this task, and passes in the ECU part information and the diagnostic script path. The diagnostic script is downloaded along with the upgrade task and cached in the OTA partition of the vehicle infotainment system. The OTA diagnostic flashing module process executes the diagnostic script, which can be uploaded to the OTA cloud and can be designed individually according to the situation of each part. The diagnostic instructions are forwarded to the gateway by the OTA diagnostic flashing module process via the MCU, and then sent to the specified ECU by the gateway. The diagnostic steps and results are jointly determined by the diagnostic script and the ECU. The diagnostic results are obtained by the OTA diagnostic flashing module to control the diagnostic script, and then returned to the OTA main control program on the vehicle side.

[0073] In a feasible implementation manner, the step of determining a diagnostic script according to the OTA upgrade file, diagnosing the target part based on the diagnostic script, and obtaining a diagnostic result includes:

[0074] Parsing the OTA upgrade file to obtain a diagnostic script;

[0075] Detecting whether the system file is abnormal based on the diagnostic script, and if so, returning a first diagnostic result;

[0076] When the system file is normal, detecting whether the key user data is abnormal, and if so, returning a second diagnosis result;

[0077] When there is no abnormality in the key user data, it is detected whether the ECU has a self-test fault, and if so, the third diagnostic result is returned, and if not, the fourth diagnostic result is returned.

[0078] It should be noted that the first diagnostic result corresponds to the error code corresponding to the detection of system files, the second diagnostic result corresponds to the error code corresponding to the detection of key user data, and the third diagnostic result corresponds to the error code corresponding to whether the ECU has a self-test failure.

[0079] In the specific implementation, refer to Figure 4 , Figure 4 It is the diagnostic flow chart of the diagnostic script. When performing the test, it can first detect whether the system file has been changed or damaged. If so, it returns the first diagnostic result, corresponding to error code 1. If not, it judges whether the key user is damaged. If so, it returns the second diagnostic result, corresponding to error code 2. If not, it detects whether the ECU has a self-test fault. If so, it feeds back the third diagnostic result, corresponding to error code 3. If not, it returns code 0. When the return code or error code is detected, the detection process will be stopped. When the error code is detected, it means that there is a fault in the current vehicle.

[0080] In a feasible implementation manner, the step of detecting whether the system file is abnormal based on the diagnostic script, and if so, returning the first diagnostic result includes:

[0081] Based on the diagnosis script, the system files are traversed in order according to the file sorting, and the md5 code of the system files is calculated;

[0082] Compare the md5 code of the system file with the md5 code of the system file recorded by the ECU to obtain a comparison result;

[0083] When the comparison results are inconsistent, it is determined that the system file is abnormal and the first diagnosis result is returned.

[0084] In the specific implementation, when checking whether the system files have been changed or damaged, the system core files (such as files under Android system / system, etc.) are sorted by file name, read in sequence, and the md5 code is calculated. The md5 code is compared with the md5 code of the version core file recorded by the ECU. If they are inconsistent, it means that the core file has been changed or damaged. If the md5 code verification fails, error code 1 is returned.

[0085] In a feasible implementation manner, when the system file is normal, detecting whether the key user data is abnormal, and if so, returning the second diagnosis result comprises:

[0086] When there is no abnormality in the system file, determining the file format of the key user data;

[0087] When the file format is a preset file format, detecting the data integrity of the key user data;

[0088] When the data integrity is incomplete, it is determined that the key user data is abnormal, and a second diagnosis result is returned.

[0089] In the specific implementation, when checking whether key user data is damaged, the system core configuration files are checked for damage, mainly the file formats, such as XML, JSON and other format files. These files are very likely to be incompletely written due to a sudden power failure of the system during the IO reading and writing process, and the format becomes unparseable. If the user data format is damaged, error code 2 is returned.

[0090] In a feasible implementation manner, when the key user data is normal, detecting whether the ECU has a self-test fault, if so, returning the third diagnostic result, if not, returning the fourth diagnostic result, comprises:

[0091] When the key user data is normal, the ECU is made to perform a self-check according to the diagnostic script to obtain status data of the sensor;

[0092] The state data of the sensor is detected, and when abnormal state data is obtained, it is determined that the ECU has a self-test fault and a third diagnostic result is returned, otherwise a fourth diagnostic result is returned.

[0093] In the specific implementation, when detecting whether the ECU has a self-test fault, the ECU status data is mainly detected, and instructions are issued through the script, and the ECU detects itself. If there is abnormal status data such as the sensor, the error code 3 is returned, otherwise it returns 0.

[0094] When a part is diagnosed to be abnormal, the OTA main control program on the car side notifies the user interaction module and displays it to the user, informing the user that the corresponding part was found to be faulty before the upgrade and that recovery is in progress.

[0095] Step S40, when the diagnosis result is that the target part has an abnormality, determine the type of the abnormality, determine a recovery strategy according to the abnormality type, and perform fault recovery on the target part before OTA upgrade based on the recovery strategy.

[0096] It should be noted that there is a corresponding relationship between the exception type, recovery strategy and error code, including restarting the ECU, self-restarting after restoring factory settings and flashing the start package.

[0097] In a specific implementation, the error code corresponding to the diagnostic result can be determined. When the error code is a first error code, the starting packet of the ECU is obtained, the ECU is flashed based on the starting packet, and the target part is recovered from the fault before the OTA upgrade; when the error code is a second error code, a part factory reset instruction is initiated to restore the part to the factory state, and the target part is recovered from the fault before the OTA upgrade; when the error code is a third error code, an ECU restart instruction is received, and based on the ECU restart instruction, the ECU is powered off and then powered on, and the target part is recovered from the fault before the OTA upgrade.

[0098] In the specific implementation, error code 1 corresponds to the recovery strategy of re-flashing the current version, which is mainly aimed at faults caused by abnormal system files in ECU parts, that is, re-entering OTA mode and re-flashing the ECU version to avoid the current ECU function abnormality causing other parts to be unable to upgrade. For example, the abnormal PDCU (power domain controller) causes the abnormal power state of the vehicle, and other parts are affected by the abnormal power state and cannot be upgraded.

[0099] Error code 2 corresponds to the recovery strategy of self-restart after restoring to factory settings, which is mainly aimed at faults caused by abnormal data cached by users in ECU parts. The OTA main control program on the vehicle side initiates a factory reset command to the OTA diagnostic flash module, which then sends the command to the ECU through CAN. The ECU restarts after restoring to factory settings. After receiving the restart signal, the OTA diagnostic flash module returns success to the OTA main control program on the vehicle side.

[0100] Error code 3 corresponds to the recovery strategy for restarting the ECU, which is mainly aimed at faults caused by abnormal data in the ECU memory RAM. The OTA main control program on the vehicle side initiates the restart ECU command to the smart component flashing module, and the smart component flashing module then notifies the on-board wireless terminal of the command. The on-board wireless terminal sends the power-off and power-on operation instructions to the CAN, which is processed by the corresponding power controller and then returns the execution results to the OTA main control program on the vehicle side to achieve fault recovery before OTA upgrade of the target parts.

[0101] In a feasible implementation manner, when the diagnosis result is that the target part is abnormal, determining the abnormality type, determining a recovery strategy according to the abnormality type, and performing fault recovery on the target part before OTA upgrade based on the recovery strategy also includes:

[0102] Detecting the target part version, and when the target part version is a specific version, decompressing the OTA upgrade file to obtain a preprocessing package;

[0103] The file data is transmitted to the ECU, so that the ECU is restarted;

[0104] When the ECU start signal is received, fault recovery is performed on the target part before OTA upgrade.

[0105] In the specific implementation, the target part version is detected. When the target part version is a specific version, the OTA upgrade file can be decompressed to obtain a preprocessing package. The preprocessing package includes a recovery strategy for known faults. If such faults are not repaired first, they cannot be upgraded remotely. Therefore, the vehicle-side OTA main control program can detect the part version. If the version matches the specific version, it will initiate the preprocessing of the specific fault version to the OTA diagnostic flashing module. The OTA diagnostic flashing module executes the preprocessing script and returns the processing result to the vehicle-side OTA main control program. Figure 5 , Figure 5 The preprocessing script flowchart is shown in Figure 1. The preprocessing script first unzips the preprocessing package, which is downloaded along with the upgrade task. The OTA diagnostic flashing module process passes the file or data to the ECU through the CAN communication protocol. After receiving the data, the ECU will write the file or data to the specified location according to the communication parameters. When restarting the ECU, the OTA diagnostic flashing module process sends a restart command to the ECU. After waiting for the ECU start signal, a specific signal will be sent to the CAN. After the ECU restarts, the OTA diagnostic flashing module detects that the ECU has been successfully restarted and returns a success to the OTA main control program on the vehicle side. If the signal is not received within the timeout period, a failure will be returned to the OTA main control program on the vehicle side.

[0106] This embodiment provides a method for fault recovery before OTA upgrade, which obtains the OTA upgrade file of the current OTA upgrade of the whole vehicle; determines the target part information according to the OTA upgrade file, and generates a fault detection request according to the target part information; determines the diagnostic script according to the OTA upgrade file, diagnoses the target part based on the diagnostic script, and obtains the diagnostic result; when the diagnostic result is that the target part is abnormal, determines the abnormal type, determines the recovery strategy according to the abnormal type, and performs fault recovery before OTA upgrade on the target part based on the recovery strategy, which can identify potential software problems that may affect the upgrade process and the stability of the system after the upgrade. When a potential problem is detected, it can accurately analyze the cause of the problem and provide effective repair operations. At the same time, it can also determine whether it is a known fault version based on the vehicle's part version, and pre-process the specific fault version before upgrading to prevent the fault version from affecting the upgrade of other ECUs.

[0107] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the fault recovery method before OTA upgrade of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0108] This application also provides a fault recovery device before OTA upgrade, please refer to Figure 6 , the fault recovery device before OTA upgrade includes:

[0109] The file loading module 10 is used to obtain the OTA upgrade file of the current OTA upgrade of the whole vehicle;

[0110] A detection request module 20, configured to determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information;

[0111] A fault detection module 30 is used to determine a diagnosis script according to the OTA upgrade file, diagnose the target part based on the diagnosis script, and obtain a diagnosis result;

[0112] The fault recovery module 40 is used to determine the type of abnormality when the diagnosis result shows that the target part has an abnormality, determine a recovery strategy according to the abnormality type, and perform fault recovery on the target part before OTA upgrade based on the recovery strategy.

[0113] The pre-OTA upgrade fault recovery device provided by the present application adopts the pre-OTA upgrade fault recovery method in the above-mentioned embodiment, which can solve the technical problem that the prior art cannot detect and recover faults before OTA upgrade. Compared with the prior art, the beneficial effects of the pre-OTA upgrade fault recovery device provided by the present application are the same as the beneficial effects of the pre-OTA upgrade fault recovery method provided by the above-mentioned embodiment, and the other technical features of the pre-OTA upgrade fault recovery device are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0114] The present application provides a pre-OTA upgrade fault recovery device, and the pre-OTA upgrade fault recovery device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the pre-OTA upgrade fault recovery method in the above-mentioned embodiment one.

[0115] Reference below Figure 7, which shows a schematic diagram of the structure of a fault recovery device before OTA upgrade suitable for implementing the embodiment of the present application. The fault recovery device before OTA upgrade in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The fault recovery device before OTA upgrade shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0116] like Figure 7 As shown, the fault recovery device before OTA upgrade may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the fault recovery device before OTA upgrade are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the pre-OTA upgrade fault recovery device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a pre-OTA upgrade fault recovery device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0117] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0118] The pre-OTA upgrade fault recovery device provided by the present application adopts the pre-OTA upgrade fault recovery method in the above embodiment, which can solve the technical problem that the prior art cannot detect and recover faults before OTA upgrade. Compared with the prior art, the beneficial effects of the pre-OTA upgrade fault recovery device provided by the present application are the same as the beneficial effects of the pre-OTA upgrade fault recovery method provided by the above embodiment, and the other technical features of the pre-OTA upgrade fault recovery device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0119] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0120] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0121] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the fault recovery method before OTA upgrade in the above-mentioned embodiment.

[0122] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Freq user interaction module: radio frequency), etc., or any suitable combination of the above.

[0123] The computer-readable storage medium may be included in the fault recovery device before OTA upgrade; or may exist independently without being assembled into the fault recovery device before OTA upgrade.

[0124] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the pre-OTA upgrade fault recovery device, the pre-OTA upgrade fault recovery device:

[0125] Get the OTA upgrade file of the current OTA upgrade of the vehicle;

[0126] Determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information;

[0127] Determine a diagnostic script according to the OTA upgrade file, diagnose the target part based on the diagnostic script, and obtain a diagnostic result;

[0128] When the diagnosis result indicates that an abnormality exists in the target part, the abnormality type is determined, a recovery strategy is determined according to the abnormality type, and fault recovery is performed on the target part before OTA upgrade based on the recovery strategy.

[0129] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0131] The modules involved in the embodiments of the present application may be implemented by software or hardware, wherein the name of the module does not limit the unit itself in some cases.

[0132] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned fault recovery method before OTA upgrade, and can solve the technical problem that the prior art cannot detect and recover faults before OTA upgrade. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the fault recovery method before OTA upgrade provided by the above-mentioned embodiment, and will not be repeated here.

[0133] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the fault recovery method before OTA upgrade as described above.

[0134] The computer program product provided by the present application can solve the technical problem that the prior art cannot detect and recover faults before OTA upgrade. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the fault recovery method before OTA upgrade provided by the above embodiment, which will not be repeated here.

[0135] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A fault recovery method before OTA upgrade, characterized in that: The fault recovery method before OTA upgrade includes: Get the OTA upgrade file of the current OTA upgrade of the vehicle; Determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information; Determine a diagnostic script according to the OTA upgrade file, diagnose the target part based on the diagnostic script, and obtain a diagnostic result; When the diagnosis result indicates that an abnormality exists in the target part, the abnormality type is determined, a recovery strategy is determined according to the abnormality type, and fault recovery is performed on the target part before OTA upgrade based on the recovery strategy.

2. The method according to claim 1, characterized in that The step of determining a diagnostic script according to the OTA upgrade file, diagnosing the target part based on the diagnostic script, and obtaining a diagnostic result comprises: Parsing the OTA upgrade file to obtain a diagnostic script; Detecting whether the system file is abnormal based on the diagnostic script, and if so, returning a first diagnostic result; When the system file is normal, detecting whether the key user data is abnormal, and if so, returning a second diagnosis result; When there is no abnormality in the key user data, it is detected whether the ECU has a self-test fault, and if so, the third diagnostic result is returned, and if not, the fourth diagnostic result is returned.

3. The method according to claim 2, characterized in that The step of detecting whether the system file is abnormal based on the diagnostic script, and if so, returning the first diagnostic result comprises: Based on the diagnosis script, the system files are traversed in order according to the file sorting, and the md5 code of the system files is calculated; Compare the md5 code of the system file with the md5 code of the system file recorded by the ECU to obtain a comparison result; When the comparison results are inconsistent, it is determined that the system file is abnormal and the first diagnosis result is returned.

4. The method according to claim 2, characterized in that When the system file is normal, detecting whether the key user data is abnormal, and if so, returning the second diagnosis result comprises: When there is no abnormality in the system file, determining the file format of the key user data; When the file format is a preset file format, detecting the data integrity of the key user data; When the data integrity is incomplete, it is determined that the key user data is abnormal, and a second diagnosis result is returned.

5. The method according to claim 2, characterized in that The step of detecting whether the ECU has a self-test fault when the key user data is normal, and if so, returning the third diagnostic result, and if not, returning the fourth diagnostic result comprises: When the key user data is normal, the ECU is made to perform a self-check according to the diagnostic script to obtain status data of the sensor; The state data of the sensor is detected, and when abnormal state data is obtained, it is determined that the ECU has a self-test fault and a third diagnostic result is returned, otherwise a fourth diagnostic result is returned.

6. The method according to claim 1, characterized in that When the diagnosis result indicates that the target part is abnormal, determining the abnormality type, determining a recovery strategy according to the abnormality type, and performing fault recovery on the target part before OTA upgrade based on the recovery strategy includes: Determine an error code corresponding to the diagnosis result; When the error code is the first error code, obtaining a starting packet of the ECU, flashing the ECU based on the starting packet, and performing fault recovery on the target part before OTA upgrade; When the error code is the second error code, a component factory reset instruction is initiated to restore the component to a factory state, and the target component is restored to a fault state before an OTA upgrade; When the error code is the third error code, an ECU restart instruction is received, and based on the ECU restart instruction, the ECU is powered off and then powered on to perform fault recovery on the target part before OTA upgrade.

7. The method according to claim 1, characterized in that When the diagnosis result indicates that the target part is abnormal, determining the abnormality type, determining a recovery strategy according to the abnormality type, and performing fault recovery on the target part before OTA upgrade based on the recovery strategy also includes: Detecting the target part version, and when the target part version is a specific version, decompressing the OTA upgrade file to obtain a preprocessing package; The file data is transmitted to the ECU, so that the ECU is restarted; When the ECU start signal is received, fault recovery is performed on the target part before OTA upgrade.

8. A fault recovery device before OTA upgrade, characterized in that: The device comprises: The file loading module is used to obtain the OTA upgrade file of the current OTA upgrade of the vehicle; A detection request module, used to determine target part information according to the OTA upgrade file, and generate a fault detection request according to the target part information; A fault detection module, used to determine a diagnosis script according to the OTA upgrade file, diagnose the target part based on the diagnosis script, and obtain a diagnosis result; A fault recovery module is used to determine the type of abnormality when the diagnosis result shows that the target part has an abnormality, determine a recovery strategy according to the abnormality type, and perform fault recovery on the target part before OTA upgrade based on the recovery strategy.

9. A fault recovery device before OTA upgrade, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the pre-OTA upgrade fault recovery method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the fault recovery method before OTA upgrade according to any one of claims 1 to 7 are implemented.

Images