Vehicle OTA upgrading method and device and vehicle

Abstract

The invention provides a vehicle OTA upgrade method and device and a vehicle, and the method comprises the steps: obtaining an OTA upgrade package, splitting the OTA upgrade package into at least two hierarchical upgrade packages, splitting the data of each hierarchical upgrade package into at least two data block units, and in the installation stage of the OTA upgrade package, installing the hierarchical upgrade packages in sequence according to a preset hierarchical installation sequence. The installation data of each data block unit is recorded, if interruption occurs in the vehicle OTA upgrading process, when vehicle OTA upgrading is restarted, upgrading is continued from the breakpoint data block unit until vehicle OTA upgrading is completed, through the method, even if power failure occurs in the vehicle upgrading process, the upgrading process is stopped but not terminated, upgrading can be continued after power-on again, and the vehicle OTA upgrading efficiency is improved. According to the method and the device, a complete upgrade package does not need to be downloaded again, an upgrade process does not need to be started again, potential safety hazards such as damage to original system firmware of the vehicle-mounted controller, blank screen of a vehicle, communication failure of a control module and even locking of a power battery management system are avoided, and user experience is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of vehicles, in particular to a vehicle OTA upgrading method and device and vehicle. BACKGROUND

[0002] With the improvement of the intelligent level of new energy vehicles, OTA (Over-the-Air Technology) upgrading has become a core technical means to realize vehicle function iteration, bug fixing and performance optimization.

[0003] In related technologies, the new energy vehicle OTA upgrading process usually includes four core stages of “upgrading package download - integrity check - module installation - system restart adaptation”, and the entire process relies on stable vehicle power supply (usually provided by a power battery or a low-voltage storage battery). In order to ensure the completion of OTA upgrading, a forced check of power before upgrading can be used, such as requiring the power battery power to be greater than or equal to 30% to start upgrading. However, once power failure occurs during upgrading, the current upgrading will be terminated, and the original system firmware of the vehicle controller may be damaged, causing the vehicle screen to be black, the control module communication to fail, and even the power battery management system to be locked, etc. Safety hazards, and re-upgrading requires downloading a complete upgrade package, which has the problems of low upgrading efficiency and large traffic consumption, seriously affecting user experience. SUMMARY

[0004] Embodiments of the present application provide a vehicle OTA upgrading method, device and vehicle to solve the technical problem that in related technologies, once power failure occurs during upgrading, the current upgrading will be terminated, and the original system firmware of the vehicle controller may be damaged, causing the vehicle screen to be black, the control module communication to fail, and even the power battery management system to be locked, etc. Safety hazards, and re-upgrading requires downloading a complete upgrade package, which has the problems of low upgrading efficiency and large traffic consumption, seriously affecting user experience.

[0005] The vehicle OTA upgrading method provided by the embodiments of the present application comprises: obtaining an OTA upgrading package; splitting the OTA upgrading package into at least two hierarchical upgrading packages, and splitting the data of each hierarchical upgrading package into at least two data block units; in the installation stage of the OTA upgrading package, installing the hierarchical upgrading packages in turn according to a preset hierarchical installation order, and recording the installation data of each data block unit; if interruption occurs in the vehicle OTA upgrading process, when the vehicle OTA upgrading is restarted, the upgrading is continued from the breakpoint data block unit until the vehicle OTA upgrading is completed, the breakpoint data block unit is a data block unit after the last installed data block unit whose installation state is installed, and the installation state is obtained based on the installation data.

[0006] In an embodiment of the present application, the installation data of each data block unit is recorded, including: storing the data block identification, the old version firmware storage address, the data block check value and the installation state of the data block unit which has completed installation to obtain the installation data of the data block unit which has completed installation, wherein the installation state is installed; marking the installation state of the breakpoint data block unit as to be installed to obtain the installation data of the breakpoint data block unit; marking the installation state of the remaining data block unit as not installed to obtain the installation data of the remaining data block unit; and updating the installation state of each data block unit to installed and recording the current upgrade progress at the data block level after completing the writing and checking of each data block unit.

[0007] In an embodiment of the present application, the installation data of each data block unit is recorded, including: storing the installation data of each data block unit in a breakpoint marker library; and synchronously updating the installation data in the breakpoint marker library to the vehicle-mounted nonvolatile memory and the cloud server if a preset backup condition is met, wherein the preset backup condition includes completing the installation of a preset number of data block units or being interval for a preset time.

[0008] In an embodiment of the present application, if interruption occurs in the vehicle OTA upgrade process, before continuing the upgrade from the breakpoint data block unit after restarting the vehicle OTA upgrade, the method further includes: detecting the basic communication function state of the target vehicle-mounted module; loading a preset factory backup firmware if the basic communication function state is communication abnormal; if the basic communication function state is communication normal, obtaining the breakpoint marker library stored in the vehicle-mounted nonvolatile memory and the breakpoint marker library stored in the cloud server respectively, and performing consistency check to determine the last installed data block unit before interruption as installed, and then obtaining the breakpoint data block unit; if the breakpoint marker library stored in the vehicle-mounted nonvolatile memory cannot be obtained, obtaining the breakpoint marker library stored in the cloud server to determine the last installed data block unit before interruption as installed, and then obtaining the breakpoint data block unit.

[0009] In an embodiment of the present application, the installation data of each data block unit is recorded, including: if a power-off protection instruction is received, pausing the installation of the breakpoint data block unit; obtaining the written byte number and the remaining writing byte number of the breakpoint data block unit; generating a partial installation state according to the written byte number and the remaining writing byte number, and generating the installation data based on the partial installation state; recording the installation data to a breakpoint marker library, and synchronously updating the installation data of the breakpoint marker library to the vehicle-mounted nonvolatile memory; at this time, continuing the upgrade from the breakpoint data block unit, including: determining a breakpoint byte position according to the written byte number and the remaining writing byte number, and continuing the upgrade from the breakpoint byte position.

[0010] In an embodiment of the present application, if interruption occurs in the process of vehicle OTA upgrade, when the vehicle OTA upgrade is restarted, the method further comprises: when installation of a level upgrade package is completed, determining a first level check value according to all data block units in the level upgrade package to obtain the first level check value of all installed level upgrade packages; if the breakpoint data block unit is the first data block unit in the level upgrade package, calculating a second level check value of each installed level upgrade package; checking the installed level upgrade package based on the first level check value and the second level check value of the same level upgrade package; if all installed level upgrade packages pass the check, triggering the step of continuing upgrade from the breakpoint data block unit.

[0011] In an embodiment of the present application, the method further comprises: if there is an abnormal level upgrade package, calculating a second data block unit check value of each data block unit in the abnormal level upgrade package; comparing the second data block check value and a first data block check value of the same data block unit, the first data block check value being calculated before interruption based on each data block unit in the abnormal level upgrade package; if the second data block check value of a data block unit is different from the first data block check value, determining the data block unit as an abnormal data block unit; reinstalling the abnormal data block unit.

[0012] In an embodiment of the present application, after the vehicle OTA upgrade is completed, the method further comprises: restarting the vehicle target module, loading the newly upgraded firmware and function, and performing adaptability detection; if the adaptability detection passes, deleting the breakpoint marker library and the backup of the old version firmware, completing the upgrade, the breakpoint marker library being used for storing the installation data; if the adaptability detection does not pass, restoring the old version data of each level according to the old version firmware storage address recorded in the breakpoint marker library, and deleting all files of this upgrade, the installation data further comprising the old version firmware storage address.

[0013] The embodiment of the present application further provides a vehicle OTA upgrade device, the device comprising: an acquisition module, used for acquiring an OTA upgrade package; a data splitting module, used for splitting the OTA upgrade package into at least two level upgrade packages, and splitting data of each level upgrade package into at least two data block units; an installation module, used for installing each level upgrade package in a preset level installation order in the installation stage of the OTA upgrade package, and recording installation data of each data block unit; an upgrade module, used for continuing upgrade from a breakpoint data block unit when interruption occurs in the process of vehicle OTA upgrade, until vehicle OTA upgrade is completed, the breakpoint data block unit being a data block unit after the last installed data block unit, the installation state being obtained based on the installation data.

[0014] This application embodiment also provides a vehicle, the vehicle including a cockpit domain controller and a vehicle domain controller, wherein: the cockpit domain controller is used to acquire OTA upgrade packages; the vehicle domain controller is used to split the OTA upgrade package into at least two level upgrade packages, and to split the data of each level upgrade package into at least two data block units, and to construct a breakpoint marker library, through which, during the installation phase of the OTA upgrade package, each level upgrade package is installed sequentially according to a preset level installation order, the installation data of each data block unit is recorded, and if an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the upgrade continues from the breakpoint data block unit until the vehicle OTA upgrade is completed, the breakpoint data block unit being the data block unit after the last data block unit whose installation state is "installed", and the installation state is obtained based on the installation data.

[0015] This application also provides an electronic device, including: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the method described in any of the above embodiments.

[0016] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0017] The beneficial effects of this application: The vehicle OTA upgrade method, device, and vehicle proposed in this application are as follows: The method obtains the OTA upgrade package and splits it into at least two-level upgrade packages. The data of each-level upgrade package is split into at least two data block units. During the installation phase of the OTA upgrade package, each-level upgrade package is installed sequentially according to a preset installation order. The installation data of each data block unit is recorded. If the vehicle OTA upgrade is interrupted, when the vehicle OTA upgrade is restarted, the upgrade continues from the interrupted data block unit until the vehicle OTA upgrade is completed. With this method, even if the vehicle loses power during the upgrade process, the upgrade process is suspended rather than terminated. After power is restored, the upgrade can continue without downloading the complete upgrade package again or restarting the upgrade process. This avoids the safety hazards such as damage to the original system firmware of the vehicle controller, black screen of the vehicle, communication failure of the control module, or even lock-up of the power battery management system, thus improving the user experience. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0019] In the attached diagram: Figure 1 This is a schematic diagram illustrating an application scenario of a vehicle OTA upgrade method provided in an embodiment of this application; Figure 2 A schematic flowchart of a vehicle OTA upgrade method provided in an embodiment of this application; Figure 3 This application provides a specific flowchart illustrating a vehicle OTA upgrade method according to an embodiment of the present application. Figure 4 This is another specific flowchart illustrating a vehicle OTA upgrade method provided in one embodiment of this application; Figure 5 This is another specific flowchart illustrating a vehicle OTA upgrade method provided in one embodiment of this application; Figure 6 A schematic diagram of a vehicle OTA upgrade device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0021] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0023] With the improvement of the intelligence level of new energy vehicles, OTA upgrades have become a core technical means to realize vehicle function iteration, vulnerability repair, and performance optimization. The current mainstream OTA upgrade process for new energy vehicles usually includes four core stages: "upgrade package download - integrity verification - module installation - system restart adaptation". The entire process relies on a stable on-board power supply (usually provided by the power battery or low-voltage battery).

[0024] However, in real-world usage scenarios, unexpected power outages occur frequently: for example, users may accidentally disconnect the low-voltage battery power supply during OTA upgrades, the vehicle may automatically power down due to insufficient remaining battery power, power outages may occur due to low-voltage battery performance degradation in extreme low-temperature environments, or power system anomalies may result from sudden malfunctions such as vehicle collisions. In related technologies, OTA upgrades generally suffer from the defect of "failure upon power outage." The inventors discovered that once a power outage occurs during the upgrade process, the partially installed upgrade files will become "fragmented data," not only causing the upgrade to terminate but also potentially damaging the original system firmware of the vehicle controller, leading to safety hazards such as a black screen on the vehicle's infotainment system, communication failure of the control module, or even the locking of the power battery management system.

[0025] The inventors also discovered that if a passive protection solution of "forced battery power verification before upgrade" is adopted (such as requiring the power battery power to be ≥30% before the upgrade can be started), it cannot cope with sudden power depletion or forced power failure during the upgrade process; if a "dual partition backup" (i.e. the system partition and the upgrade partition are stored independently) is tried, the complete upgrade package needs to be downloaded again and the installation process needs to be executed from the beginning after the power failure, which has the problems of low upgrade efficiency and large data consumption. Especially for vehicle system upgrade packages with a capacity of more than 1GB, re-upgrading will take up several hours of the user's time, which seriously affects the user experience.

[0026] In view of this, in order to overcome the shortcomings of OTA upgrade technology for new energy vehicles, such as "high risk of upgrade failure, low efficiency of resume upgrade, and poor system security" after unexpected power outages, there is an urgent need to provide a method for resume upgrades after unexpected power outages during OTA upgrades for new energy vehicles. This method should be able to accurately locate the interruption point after a power outage, resume the upgrade based on the breakpoint, and at the same time ensure the integrity of the vehicle system data and the safety of vehicle operation. It should be an OTA resume upgrade technology that can quickly resume the upgrade process without re-downloading the complete upgrade package after an unexpected power outage and ensure system security. The vehicle OTA upgrade method provided in this application obtains the OTA upgrade package and splits it into at least two-level upgrade packages. Each-level upgrade package's data is further divided into at least two data block units. During the OTA upgrade package installation phase, each-level upgrade package is installed sequentially according to a preset installation order. The installation data of each data block unit is recorded. If an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the upgrade continues from the interrupted data block unit until the vehicle OTA upgrade is complete. This method ensures that even if a power outage occurs during the vehicle upgrade process, the upgrade process is paused rather than terminated. After power is restored, the upgrade can continue without needing to download the complete upgrade package again or restart the upgrade process. This avoids damaging the original system firmware of the vehicle controller, preventing safety hazards such as vehicle screen blackouts, control module communication failures, or even battery management system lock-up, thus improving the user experience.

[0027] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of a vehicle OTA upgrade method provided in an embodiment of this application. For example... Figure 1 As shown, during the OTA upgrade process of vehicle 110, the OTA upgrade package is first obtained and then broken down into multiple hierarchical upgrade packages. Each hierarchical upgrade package is further broken down into multiple data block units. During the installation phase, the upgrade is performed one by one according to the dimensions of the hierarchical upgrade packages, and the installation data of each data block unit is recorded. In this way, if the upgrade is interrupted (e.g., due to a power outage), the entire upgrade process is not restarted after power is restored. The previously recorded installation data can be used to find which data block unit the last upgrade was completed at, and then the upgrade can continue from the next data block unit (the breakpoint data block unit). This avoids the need to download the complete upgrade package again and avoids restarting the upgrade process, thus preventing damage to the original system firmware of the vehicle controller, vehicle screen blackout, control module communication failure, or even power battery management system lock-up and other safety hazards, improving the user experience. The installation data is also synchronized to the cloud server 120 to avoid the problem of not being able to identify the breakpoint data block unit due to the loss of installation data stored on the vehicle due to a sudden power outage.

[0028] It should be noted that the above scenario is only an example of an application scenario provided by the embodiments of this application. The embodiments of this application do not limit the actual form of various devices, components, etc. included in the scenario. In the specific application of the solution, it can be set according to actual needs. Please see Figure 2 , Figure 2 A schematic flowchart of a vehicle OTA upgrade method provided in an embodiment of this application is shown below. Figure 2 As shown, the method includes the following steps: Step S210: Obtain the OTA upgrade package.

[0029] The OTA upgrade package can be obtained in a manner known to those skilled in the art, and will not be elaborated here.

[0030] Step S220: The OTA upgrade package is split into at least two tier upgrade packages, and the data of each tier upgrade package is split into at least two data block units.

[0031] OTA upgrade packages may include upgrade data at multiple levels. The division of these levels can be set according to the needs of those skilled in the art, such as: basic firmware layer (e.g., operating system kernel), functional module layer (e.g., autonomous driving algorithms, in-vehicle entertainment functions), and configuration parameter layer (e.g., battery management strategy parameters). This is merely an example and is not intended to limit the layers in this embodiment to only three or only these levels.

[0032] In one embodiment, the division of data block units can be dynamically adjusted according to the read and write speed of the vehicle storage medium. For example, the size of a single data block can be set to 512KB - 2MB.

[0033] Step S230: During the OTA upgrade package installation phase, each level of upgrade package is installed sequentially according to the preset installation order, and the installation data of each data block unit is recorded.

[0034] In one embodiment, recording the installation data of each data block unit includes: associating and storing the data block identifier, old firmware storage address, data block checksum, and installation status of the data block unit that has been installed, to obtain the installation data of the data block unit that has been installed, with the installation status set to "installed"; marking the installation status of the breakpoint data block unit as "to be installed", to obtain the installation data of the breakpoint data block unit; marking the installation status of the remaining data block units (other than the data block units that have been installed and the breakpoint data block units) as "not installed", to obtain the installation data of the remaining data block units; and updating the installation status of each data block unit to "installed" after each data block unit is written and verified, and recording the current upgrade progress at the data block level. Each data block unit has a globally unique identifier, and the old firmware storage address is the storage address of the firmware version of the vehicle before the upgrade corresponding to that data block unit. By recording this data, if the vehicle upgrade fails, it can be rolled back to the original version, ensuring the safe operation of the vehicle. The data block checksum can be used to determine whether the installed data block unit has been tampered with or damaged. Installation status can include installed, uninstalled, and pending installation. For example, initially all data block units are in the uninstalled state. As the installation of a data block unit progresses, its installation status changes from uninstalled to pending installation and finally to installed. When a data block unit becomes installed, the next data block unit becomes pending installation. The current upgrade progress at the data block level indicates which data block the upgrade has reached, facilitating subsequent upgrades and providing users with easy monitoring.

[0035] During the OTA upgrade installation phase, the vehicle controller is installed layer by layer in the order of "basic firmware layer → functional module layer → configuration parameter layer". After each data block unit is written and verified, the "installation status flag (installation status)" of the data block unit in the "breakpoint flag library" is immediately updated to "installed", and the current upgrade progress is recorded (accurate to the data block level).

[0036] In another embodiment, recording the installation data of each data block unit includes: storing the installation data of each data block unit in a breakpoint marker library; if preset backup conditions are met, synchronously updating the installation data in the breakpoint marker library to the vehicle-mounted non-volatile memory and the cloud server. The preset backup conditions include each time a preset number of data block units are installed or each time a preset time interval is reached.

[0037] As an example, installation data can be stored in a pre-built "breakpoint marker library," which contains a "unique identifier ID, storage address, checksum (calculated using the SHA-256 algorithm), and installation status marker (not installed / to be installed / installed)" for each data block unit. The "breakpoint marker library" is also backed up synchronously to the vehicle's non-volatile memory (such as EEPROM) and the T-Box cloud server to avoid marker loss due to local storage corruption.

[0038] In one embodiment, a "high-frequency backup trigger mechanism" is set up to back up the data. For example, every time 10 data block units are installed or every 30 seconds, the latest status of the "breakpoint marker library" is synchronously updated to the non-volatile memory and the cloud server to ensure the real-time nature of the breakpoint information.

[0039] In another embodiment, recording the installation data of each data block unit includes: if a power failure protection command is received, pausing the installation of the breakpoint data block unit; obtaining the number of bytes written and the number of bytes remaining to be written for the breakpoint data block unit; generating a partial installation state based on the number of bytes written and the number of bytes remaining to be written, and generating installation data based on the partial installation state; recording the installation data to the breakpoint marker library, and synchronously updating the installation data in the breakpoint marker library to the vehicle non-volatile memory; at this time, continuing the upgrade from the breakpoint data block unit includes: determining the breakpoint byte position based on the number of bytes written and the number of bytes remaining to be written, and continuing the upgrade from the breakpoint byte position.

[0040] One example of implementing unexpected power outage detection and "breakpoint location" after power-on is as follows: When the vehicle power management module detects that the supply voltage is lower than a threshold (e.g., low-voltage battery voltage < 9V, or a power battery power interruption signal), it immediately triggers a "power outage protection command." Upon receiving this command, the vehicle controller suspends the installation of the current data block unit and prioritizes recording the "partial installation status" (e.g., number of bytes written, number of bytes remaining to be written) of the currently processed data block unit to the "breakpoint marker library." After completing the final local backup of the "breakpoint marker library," it enters a low-power sleep state. At this time, for this special data block unit, the installation data also includes the partial installation status, so upon the next power-on, installation does not need to start from the beginning but begins from the interrupted byte position. It should be noted that the power outage protection command can also be generated using other methods known to those skilled in the art.

[0041] Step S240: If an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the upgrade continues from the breakpoint data block unit until the vehicle OTA upgrade is completed.

[0042] In this context, the breakpoint data block unit is the data block unit following the last data block unit whose installation state is "installed," and the installation state is derived from the installation data. For example, if an impending power outage is detected, and data block unit 1 has just been installed, its installation state is "installed." If the next data block unit has not yet started installation or is currently being installed, its installation state is adjusted to "pending installation," and it is designated as the breakpoint data block unit.

[0043] If there are multiple abnormal power outages during an upgrade process, steps S230 and S240 above can be repeated until the upgrade is completed.

[0044] In one embodiment, if an interruption occurs during the vehicle OTA upgrade process, before continuing the upgrade from the breakpoint data block unit after restarting the vehicle OTA upgrade, the method further includes: detecting the basic communication function status of the target vehicle module; if the basic communication function status is communication abnormal, loading a preset factory backup firmware; if the basic communication function status is communication normal, obtaining the breakpoint marker library stored in the vehicle non-volatile memory and the breakpoint marker library stored in the cloud server respectively, and performing a consistency check to determine that the last installation state before the interruption is the installed data block unit, thereby obtaining the breakpoint data block unit.

[0045] In one embodiment, when performing a follow-up upgrade after an interruption (continuing the upgrade), it is also necessary to perform integrity verification on the downloaded data block units. This integrity verification can be achieved through data block hash values, etc. One example of hash verification for downloaded data block units is to calculate and store the hash value of each data block unit during download. After power failure is restored, before continuing to download the remaining data block units, the hash values ​​of the downloaded data block units are recalculated and compared with the previously stored hash values. If they match, the data block is intact; if they do not match, the data block may be corrupted, and the data block unit needs to be downloaded again.

[0046] For example, when the vehicle is powered back on, the vehicle controller first initiates a "system safety check": it checks whether the basic communication functions of the vehicle target modules (such as ECU, vehicle infotainment system, BMS, etc.) are normal. If there is a communication abnormality, it initiates an "emergency recovery mode" and loads the "factory backup firmware" pre-stored in the vehicle controller to ensure that the vehicle has basic driving functions. If the system communication is normal, it reads the "breakpoint marker library" in the non-volatile memory and performs a consistency check (compare the checksums) with the "breakpoint marker library" backed up on the cloud server. If the local marker library is damaged, it synchronizes the latest version from the cloud and finally determines the "last installed data block" and "data block to be installed" before the power failure, thus completing the breakpoint location.

[0047] As an example, consistency verification can be performed at the tier level by comparing the tier checksum before power failure (first-tier checksum) with the tier checksum after power failure (second-tier checksum) of the installed tier upgrade package. If the verification passes, a fine-grained verification at the data block level is performed by comparing the data block checksum before power failure (first data block checksum) with the data block checksum after power failure (second data block checksum) of each data block unit in the currently installed tier upgrade package. If they are consistent, the verification passes; otherwise, it fails. Then, using the data in the obtained breakpoint marker library, the last data block unit with a completed installation status is found, and the next data block unit is designated as the breakpoint data block. Alternatively, if the installation data records partial installation statuses, the breakpoint data block unit can be designated by querying which data block unit has a partial installation status. As another example, once a data block unit is installed, the partial installation status can be deleted to prevent confusion of data block units in the event of a subsequent power failure. Alternatively, breakpoint data block units that have been installed can be distinguished from those that have not been installed by using special markings or updating partial installation status.

[0048] Following the above embodiments, if the breakpoint marker library stored in the vehicle's non-volatile memory cannot be obtained, the breakpoint marker library stored on the cloud server is obtained. The last installed state before the interruption is determined to be an installed data block unit, thus obtaining the breakpoint data block unit. If the local breakpoint marker library is damaged or other problems occur, it may be impossible to obtain the breakpoint marker library stored in the vehicle's non-volatile memory. In this case, the breakpoint marker library stored on the cloud server can be obtained separately, and then the breakpoint data block unit can be determined.

[0049] In one embodiment, if an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the method further includes: when a level-one upgrade package is installed, determining a first-level verification value based on all data block units in the level-one upgrade package to obtain the first-level verification value of all installed level-one upgrade packages; if the breakpoint data block unit is the first data block unit in the level-one upgrade package, calculating a second-level verification value for each installed level-one upgrade package; verifying the installed level-one upgrade packages based on the first-level verification value and the second-level verification value of the same level-one upgrade package; if all installed level-one upgrade packages pass the verification, triggering the step of continuing the upgrade from the breakpoint data block unit.

[0050] For example, after each level is installed, a "Level Integrity Verification Report" is generated, which includes a summary of the verification values ​​of all data blocks at that level, for rapid verification during subsequent upgrades. The calculation method for the first-level verification value is the same as that for the second-level verification value. The first-level verification value can be the summary of the verification values ​​of all data blocks as described above, or it can be a new verification value determined based on the verification values ​​of all data blocks. Those skilled in the art can also set the calculation rules for the level verification value as needed.

[0051] Following the above embodiments, the method further includes: if an abnormal level upgrade package exists, calculating the second data block unit verification value of each data block unit in the abnormal level upgrade package; comparing the second data block verification value of the same data block unit with the first data block verification value, wherein the first data block verification value is calculated based on each data block unit in the abnormal level upgrade package before the interruption; if the second data block verification value of a data block unit is different from the first data block verification value, identifying the data block unit as an abnormal data block unit; and reinstalling the abnormal data block unit.

[0052] This embodiment provides a breakpoint-based "layered upgrade and integrity verification" method. Based on the located breakpoint, the vehicle controller initiates the upgrade process: if the breakpoint is located in an intermediate data block unit at a certain level (i.e., there are uninstalled data block units), all "installed" data block units are skipped, and installation starts directly from the "to be installed" data block units. For each data block unit installed, the "real-time breakpoint recording" operation is repeated. After each data block unit is written and verified, the "installation status flag" of that data block unit in the "breakpoint flag library" is immediately updated to "installed", and the current upgrade progress at the data block level is recorded.

[0053] If the breakpoint is located between two levels (i.e., the upper level has been installed but the lower level has not started), then the installed level will first be "integrity checked": the check value of all data blocks in the current level will be compared with the "level integrity check report". If the check passes, the installation of the next level will start directly; if the check fails, only the data blocks that failed the check (rather than the entire level) will be reinstalled to reduce the amount of repeated installation.

[0054] During the upgrade process, if another power outage occurs, the upgrade packages for each level will be installed sequentially according to the preset installation order. The installation data for each data block unit will be recorded. If the vehicle OTA upgrade is interrupted, the upgrade process will resume from the interrupted data block unit when the vehicle OTA upgrade is restarted, ensuring that the upgrade process can be interrupted and resumed multiple times. As an example, the data block units in the upgrade package have an installation order and must be installed in that order.

[0055] In one embodiment, after the vehicle OTA upgrade is completed, the method further includes: restarting the on-board target module, loading the newly upgraded firmware and functions, and performing a compatibility test; if the compatibility test passes, deleting the breakpoint marker library and the old version firmware backup, and completing the upgrade, wherein the breakpoint marker library is used to store installation data; if the compatibility test fails, restoring the old version data at each level according to the old version firmware storage address recorded in the breakpoint marker library, and deleting all files of this upgrade, wherein the installation data also includes the old version firmware storage address.

[0056] The target vehicle module and the target vehicle module can be the same module or different modules, and can be set by those skilled in the art as needed. However, the target vehicle module must include the vehicle modules involved in this upgrade.

[0057] During the "System Adaptation and Anomaly Rollback" phase after the upgrade is completed, once all data block units at all levels have been installed (i.e., all data block units in the "Breakpoint Marker Library" are in the "Installed" installation status), the vehicle controller initiates "Overall System Adaptation": restarting all vehicle modules, loading the newly upgraded firmware and functions, and checking the communication compatibility between modules and the correctness of functional logic (such as whether the BMS charging strategy is normal and whether the vehicle's touch response is smooth). If the adaptation test passes, the "Breakpoint Marker Library" and the old version firmware backup are deleted, and the upgrade is completed; if a functional anomaly is detected (such as errors in the autonomous driving module or frequent crashes of the vehicle's infotainment system), the "Anomaly Rollback Mechanism" is triggered: based on the old version firmware storage address recorded in the "Breakpoint Marker Library," the old version data at each level is restored, and all files from this upgrade are deleted to ensure that the vehicle is restored to its normal operating state before the upgrade.

[0058] The vehicle OTA upgrade method provided in the above embodiments obtains the OTA upgrade package and splits it into at least two-level upgrade packages. Each-level upgrade package's data is further divided into at least two data block units. During the OTA upgrade package installation phase, each-level upgrade package is installed sequentially according to a preset installation order. The installation data of each data block unit is recorded. If an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the upgrade continues from the interrupted data block unit until the vehicle OTA upgrade is complete. This method ensures that even if a power outage occurs during the vehicle upgrade process, the upgrade process is paused rather than terminated. After power is restored, the upgrade can continue without needing to download the complete upgrade package again or restart the upgrade process. This avoids potential safety hazards such as damage to the original system firmware of the vehicle controller, vehicle screen blackout, control module communication failure, or even power battery management system lockup, thus improving the user experience.

[0059] The vehicle OTA upgrade method provided in the above embodiments also has the following beneficial effects: 1. Enhanced security: Through dual backup of the "breakpoint marker library" (local non-volatile storage + cloud), "emergency protection command" before power failure, and "system security check" after power-on, the system firmware is prevented from being damaged due to power failure. At the same time, the "abnormal rollback mechanism" can quickly restore the old version of the system when the upgrade fails, ensuring that the basic driving functions of the vehicle are not affected. 2. Improved Upgrade Efficiency: No need to re-download the complete upgrade package; only "data blocks to be installed" or "data blocks that failed verification" are processed, significantly reducing upgrade time and data consumption. For example, with a 1.5GB vehicle system upgrade package, if 60% of the installation has been completed when the power is off, if it is necessary to re-download the 1.5GB package and install it from scratch (approximately 2-3 hours), while if only the remaining 40% of the data needs to be processed (approximately 40 minutes), the efficiency is improved by more than 70%. 3. Strong compatibility: It supports upgrades of multiple modules such as vehicle controllers, BMS, and vehicle systems for various new energy vehicles, including pure electric and hybrid vehicles. The "dynamic adjustment of data block size" design can adapt to vehicle storage media with different read and write speeds, making it widely applicable. 4. Improved user experience: The upgrade process is automated, requiring no manual operation from the user. At the same time, "real-time breakpoint recording" ensures that the upgrade progress is not lost, avoiding negative experiences caused by repeated upgrade failures. In addition, the abnormal rollback mechanism can prevent functional failures of the vehicle after the upgrade from affecting its use.

[0060] Taking a hybrid vehicle as an example, with an OTA upgrade package size of 300MB, the upgrade process is as follows: 1. Pre-upgrade processing: The OTA upgrade package is disassembled into "basic firmware layer (100MB, 80 1.25MB data blocks) and policy parameter layer (200MB, 160 1.25MB data blocks)", and a "breakpoint marker library" is built and backed up; 2. Upgrade Interruption: When the installation reaches data block 50 of the strategy parameter layer (progress approximately (80 + 50) / (80 + 160) = 54.2%), the power battery is depleted and the system automatically shuts down. The controller records the breakpoint and then goes into hibernation. 3. Power-on upgrade: After the user charges to 20% and powers on, the controller locates the breakpoint, skips the 130 already installed data blocks, and directly starts the upgrade from data block 50 of the strategy parameter layer. After completion, the vehicle domain controller strategy parameters are verified. After the adaptation is successful, the upgrade is completed. The entire upgrade process takes only 12 minutes, which is much shorter than the 30 minutes required for a new upgrade.

[0061] Please see Figure 3 , Figure 3This is a schematic flowchart illustrating a specific method for over-the-air (OTA) upgrades of a vehicle according to an embodiment of this application. Figure 3 As shown, the method includes the following steps: After initiating the OTA upgrade process, the vehicle's current status is detected, including dimensions such as battery level, network status, and ECU health. If the status is abnormal, such as low battery or network disconnection, an upgrade pre-pause is triggered, prompting the user to repair the anomaly. If the repair is completed, the vehicle's current status detection step is re-triggered. If the status is normal, the OTA upgrade steps are executed, writing the upgrade package in stages: Bootloader-Application Layer-Configuration File. During this process, the upgrade process is monitored in real time, and upgrade breakpoint information is recorded (e.g., completed stages (current upgrade progress at the data block level), checksums (layer level and data block level), current write address (write address of the current version's data)). In one embodiment, the upgrade breakpoint information also includes the storage address of the old firmware version. It is determined whether an unexpected power outage has occurred. If no unexpected power outage has occurred, all upgrade stages are completed, and system verification and restart are performed. If there are no problems, the OTA upgrade is successful, and an upgrade log archive is generated. In the event of an unexpected power outage, the vehicle saves breakpoint information (installation data of the breakpoint marker library) to non-volatile memory (such as EEPROM (Electrically Erasable Programmable Read-Only Memory), SSD (Solid State Disk or Solid State Drive)). Once the user restores power to the vehicle, the power-off resume upgrade wake-up mechanism is triggered. The breakpoint information and checksums are read from the non-volatile memory, and breakpoint information verification (including integrity and consistency checks) is performed. If the verification is successful, the upgrade resumes from the breakpoint (skipping completed stages and continuing the transmission of incomplete data packets), and the steps for real-time monitoring of the upgrade process continue. If the verification fails, a downgrade mechanism is triggered, rolling back to the stable version before the upgrade, and an upgrade pre-pause is triggered, prompting the user to fix the anomaly.

[0062] Please see Figure 4 , Figure 4 This is another specific flowchart illustrating a vehicle OTA upgrade method provided in an embodiment of this application, as shown below. Figure 4As shown, the Remote Over-The-Air (OTA) Server sends the upgrade task to the cockpit domain controller. The cockpit domain controller downloads the upgrade package and sends it to the vehicle domain controller. The vehicle domain controller disassembles the upgrade package, builds a breakpoint marker library, and then enters the upgrade phase. During the upgrade, the vehicle domain controller updates the breakpoint marker library. If an unexpected power outage occurs, the cockpit domain controller issues a power-down command, and the vehicle domain controller pauses the installation, backs up the breakpoint marker library, and upon power-up, performs a safety check, reads and verifies the breakpoint marker library, and reports the upgrade progress to the cockpit domain controller. The breakpoint marker library contains a unique identifier ID, storage address, checksum (calculated using the SHA-256 algorithm), and installation status flag (not installed / pending installation / installed) for each data block (data block unit).

[0063] Please see Figure 5 , Figure 5 This is another specific flowchart illustrating a vehicle OTA upgrade method provided in an embodiment of this application, as shown below. Figure 5 As shown, the cockpit domain controller integrates an upgrade control module. This module is located within the cockpit domain, and the cockpit domain controller leads OTA upgrades through it. The cockpit domain controller is responsible for the overall vehicle OTA process control, including downloading vehicle software packages, installing / flashing the vehicle, entering and exiting OTA mode, high and low voltage power management, and uploading management logs. The area controller manages low voltage power, controlling the vehicle's power on and off. The vehicle domain controller is responsible for downloading software packages, reflashing and rolling back; uploading OTA upgrade logs; disassembling upgrade packages and building a breakpoint marker library; and performing security checks by reading and verifying the breakpoint marker library. The intelligent driving domain controller is connected to both the cockpit domain controller and the vehicle domain controller. The vehicle domain controller is also connected to the area controller and the cockpit domain controller. During the OTA upgrade process, the vehicle domain controller periodically sends query signals (such as liquid cooling signals) to the intelligent driving domain controller. The intelligent driving domain controller determines whether it needs to hibernate to avoid overheating based on these query signals. If hibernation is required, the intelligent driving domain controller and its integrated modules will not be upgraded; if hibernation is not required, the intelligent driving domain controller and its integrated modules will be upgraded normally.

[0064] In one embodiment, a vehicle OTA upgrade device is provided, which is used to execute the vehicle OTA upgrade method provided in any of the above embodiments. Please refer to [link to previous document]. Figure 6 , Figure 6 A schematic diagram of a vehicle OTA upgrade device provided in an embodiment of this application is shown below. Figure 6As shown, the vehicle OTA upgrade device 600 includes an acquisition module 610 for acquiring OTA upgrade packages; a data splitting module 620 for splitting the OTA upgrade package into at least two level upgrade packages, and splitting the data of each level upgrade package into at least two data block units; an installation module 630 for installing each level upgrade package sequentially according to a preset level installation order during the OTA upgrade package installation phase, and recording the installation data of each data block unit; and an upgrade module 640 for continuing the upgrade from the breakpoint data block unit when the vehicle OTA upgrade is restarted if an interruption occurs during the vehicle OTA upgrade process, until the vehicle OTA upgrade is completed. The breakpoint data block unit is the data block unit after the last data block unit with an installed status, and the installation status is obtained based on the installation data.

[0065] For specific limitations regarding the vehicle OTA upgrade device, please refer to the limitations on the vehicle OTA upgrade method mentioned above, which will not be repeated here. Each module in the aforementioned vehicle OTA upgrade device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the electronic device in hardware form or independently of it, or they can be stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of each module.

[0066] In this embodiment, the vehicle OTA upgrade device is actually equipped with multiple modules to execute the vehicle OTA upgrade method in any of the above embodiments. The specific functions and technical effects can be referred to the above embodiments, and will not be repeated here.

[0067] In one embodiment, a vehicle is provided for performing the vehicle OTA upgrade method provided in any of the above embodiments.

[0068] In one embodiment, the vehicle includes a cockpit domain controller and a vehicle domain controller, wherein: the cockpit domain controller is used to acquire OTA upgrade packages; the vehicle domain controller is used to split the OTA upgrade package into at least two tier upgrade packages, and to split the data of each tier upgrade package into at least two data block units, and to construct a breakpoint marker library, which, during the installation phase of the OTA upgrade package, sequentially installs each tier upgrade package according to a preset tier installation order, records the installation data of each data block unit, and, if an interruption occurs during the vehicle OTA upgrade process, resumes the upgrade from the breakpoint data block unit when the vehicle OTA upgrade is restarted, until the vehicle OTA upgrade is completed, the breakpoint data block unit being the data block unit following the last data block unit whose installation state is "installed", and the installation state is obtained based on the installation data.

[0069] In one embodiment, if the vehicle domain controller does not integrate the function of controlling the vehicle's power on and off, the vehicle's electronic and electrical architecture requires other area controllers to implement the corresponding functions. The vehicle also includes an area controller, which is used to control the vehicle's power on and off. When the vehicle is powered off, it will cause an interruption during the vehicle's OTA upgrade process, and when the vehicle is powered on, it will trigger a restart of the vehicle's OTA upgrade.

[0070] In another embodiment, if the vehicle domain controller integrates the function of controlling the vehicle's power on and off, then the vehicle's electronic and electrical architecture does not have any other area controllers besides the cockpit domain controller, driver domain controller, and vehicle domain controller. The vehicle domain controller is also used to control the vehicle's power on and off. When the vehicle is powered off, it will cause an interruption in the vehicle's OTA upgrade process. When the vehicle is powered on, it will trigger a restart of the vehicle's OTA upgrade.

[0071] For specific limitations regarding the vehicle, please refer to the limitations on vehicle OTA upgrade methods mentioned above, which will not be repeated here. The various modules in the aforementioned vehicle can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the electronic device in hardware form or independent of it, or stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of each module.

[0072] In this embodiment, the vehicle is actually equipped with multiple modules to execute the vehicle-side execution method in any of the above embodiments of the vehicle OTA upgrade method. The specific functions and technical effects can be referred to the above embodiments, and will not be repeated here.

[0073] See Figure 7 , Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown below. Figure 7 As shown, this embodiment of the invention also provides an electronic device 700, including a processor 701, a memory 702, and a communication bus 703; the communication bus 703 is used to connect the processor 701 and the memory 702; the processor 701 is used to execute a computer program stored in the memory 702 to implement the method described in any of the above embodiments.

[0074] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0075] This application also provides a non-volatile readable storage medium storing one or more modules (programs) that, when applied to a device, enable the device to execute the instructions included in the steps provided in this application.

[0076] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0077] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0078] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

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

[0080] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0081] It should be understood that the terms "first," "second," etc., used in this application are used to distinguish similar objects and do not necessarily indicate a specific order or sequence. The technical features to which these terms are used can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0082] It should be understood that although the flowcharts provided in the embodiments of this application indicate the various steps with arrows, the order indicated by the arrows does not necessarily limit the implementation order of these steps. Those skilled in the art can perform these steps in other orders according to different implementation scenarios and requirements.

[0083] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A vehicle OTA upgrade method, characterized in that, The method includes: Obtain OTA update package; The OTA upgrade package is split into at least two tiers of upgrade packages, and the data of each tier of upgrade package is split into at least two data block units; During the installation phase of the OTA upgrade package, each level of upgrade package is installed sequentially according to the preset hierarchical installation order, and the installation data of each data block unit is recorded. If an interruption occurs during the vehicle OTA upgrade process, when the vehicle OTA upgrade is restarted, the upgrade will continue from the breakpoint data block unit until the vehicle OTA upgrade is completed. The breakpoint data block unit is the data block unit after the last data block unit with the installation status of "installed". The installation status is obtained based on the installation data.

2. The vehicle OTA upgrade method as described in claim 1, characterized in that, Record the installation data for each data block unit, including: The data block identifier, old firmware storage address, data block check value, and installation status of the data block unit that has been installed are associated and stored to obtain the installation data of the data block unit that has been installed, wherein the installation status is "installed". The installation status of the breakpoint data block unit is marked as pending installation, and the installation data of the breakpoint data block unit is obtained. The installation status of the remaining data block units is marked as not installed, and the installation data of the remaining data block units is obtained; In addition, after each data block unit is written and verified, the installation status of the data block unit is updated to "installed", and the current upgrade progress at the data block level is recorded.

3. The vehicle OTA upgrade method as described in claim 1, characterized in that, Record the installation data for each data block unit, including: The installation data of each data block unit is stored in the breakpoint marker library; If the preset backup conditions are met, the installation data in the breakpoint marker library will be synchronously updated to the vehicle-mounted non-volatile memory and the cloud server. The preset backup conditions include each time a preset number of data block units are installed or each preset time interval.

4. The vehicle OTA upgrade method as described in claim 3, characterized in that, If an interruption occurs during the vehicle OTA upgrade process, before continuing the upgrade from the breakpoint data block unit after restarting the vehicle OTA upgrade, the method further includes: Detect the basic communication function status of the target vehicle module; If the basic communication function status is abnormal, load the preset factory backup firmware; If the basic communication function status is normal, the breakpoint marker library stored in the vehicle non-volatile memory and the breakpoint marker library stored in the cloud server are obtained respectively, and a consistency check is performed to determine that the last installation status before the interruption is the installed data block unit, and then the breakpoint data block unit is obtained. If the breakpoint marker library stored in the vehicle-mounted non-volatile memory cannot be obtained, then the breakpoint marker library stored in the cloud server is obtained, the last installed state before the interruption is determined to be the installed data block unit, and then the breakpoint data block unit is obtained.

5. The vehicle OTA upgrade method as described in claim 1, characterized in that, Record the installation data for each data block unit, including: If a power failure protection command is received, the installation of the breakpoint data block unit shall be suspended. Obtain the number of bytes already written and the number of bytes remaining to be written for the breakpoint data block unit; A partial installation status is generated based on the number of bytes already written and the number of bytes remaining to be written, and the installation data is generated based on the partial installation status; The installation data is recorded to the breakpoint marker library, and the installation data in the breakpoint marker library is synchronously updated to the vehicle non-volatile memory. At this point, continuing the upgrade from the breakpoint data block unit includes: determining the breakpoint byte position based on the number of bytes already written and the number of remaining bytes to be written, and continuing the upgrade from the breakpoint byte position.

6. The vehicle OTA upgrade method according to any one of claims 1-5, characterized in that, If an interruption occurs during the vehicle OTA upgrade process, the method further includes the following steps when restarting the vehicle OTA upgrade: Once a level-one upgrade package is installed, the first-level check value is determined based on all data block units in the level-one upgrade package, thus obtaining the first-level check value for all installed level-one upgrade packages. If the breakpoint data block unit is the first data block unit in the hierarchical upgrade package, calculate the second-level verification value for each installed hierarchical upgrade package; The installed tiered upgrade package is verified based on the first-level and second-level verification values ​​of the same tiered upgrade package; If all installed tier upgrade packages pass verification, the step of continuing the upgrade from the breakpoint data block unit is triggered.

7. The vehicle OTA upgrade method as described in claim 6, characterized in that, The method further includes: If an abnormal level upgrade package exists, calculate the second data block unit verification value for each data block unit in the abnormal level upgrade package; The second data block check value of the same data block unit is compared with the first data block check value. The first data block check value is calculated based on each data block unit in the exception level upgrade package before the interruption. If the second data block check value of a data block unit is different from the first data block check value, the data block unit is determined to be an abnormal data block unit. Reinstall the abnormal data block unit.

8. The vehicle OTA upgrade method according to any one of claims 1-5, characterized in that, After the vehicle OTA upgrade is completed, the method also includes: Reboot the vehicle target module, load the newly upgraded firmware and functions, and perform compatibility testing; If the compatibility test passes, the breakpoint marker library and the old firmware backup are deleted to complete the upgrade. The breakpoint marker library is used to store the installation data. If the compatibility test fails, the old version data at each level is restored according to the old version firmware storage address recorded in the breakpoint marker library, and all files of this upgrade are deleted. The installation data also includes the old version firmware storage address.

9. A vehicle OTA upgrade device, characterized in that, The device includes: The acquisition module is used to obtain OTA upgrade packages; The data splitting module is used to split the OTA upgrade package into at least two tier upgrade packages, and to split the data of each tier upgrade package into at least two data block units; The installation module is used to install each level of the upgrade package sequentially according to a preset hierarchical installation order during the installation phase of the OTA upgrade package, and to record the installation data of each data block unit. The upgrade module is used to continue the upgrade from the breakpoint data block unit when the vehicle OTA upgrade is restarted if an interruption occurs during the upgrade process, until the vehicle OTA upgrade is completed. The breakpoint data block unit is the data block unit after the last data block unit with the installation status set to "installed". The installation status is obtained based on the installation data.

10. A vehicle, characterized in that, The vehicle includes a cockpit domain controller and a vehicle domain controller, wherein: The cockpit domain controller is used to obtain OTA upgrade packages; The vehicle domain controller is used to split the OTA upgrade package into at least two tiered upgrade packages, and to split the data of each tiered upgrade package into at least two data block units. It is also used to construct a breakpoint marker library, which, during the installation phase of the OTA upgrade package, sequentially installs each tiered upgrade package according to a preset tiered installation order, records the installation data of each data block unit, and, if an interruption occurs during the vehicle OTA upgrade process, resumes the upgrade from the breakpoint data block unit when the vehicle OTA upgrade is restarted, until the vehicle OTA upgrade is complete. The breakpoint data block unit is the data block unit following the last data block unit whose installation status is "installed," and the installation status is obtained based on the installation data.

Images