Software upgrading method, device and storage medium of vehicle

Abstract

Embodiments of the present application provide a software upgrading method and device for a vehicle and a storage medium, and relate to the technical field of intelligent driving. The method comprises: in response to an upgrading package download instruction sent by a cloud server, downloading an upgrading package of software to be upgraded in the vehicle according to the upgrading package download instruction; in the case where an upgrading instruction of the software to be upgraded is received, calling a software upgrading interface to determine an upgrading strategy of the software to be upgraded; the software upgrading interface is adapted to the underlying hardware operation of different vehicle chips; and based on the upgrading strategy and the upgrading package, the software to be upgraded is upgraded. The scheme of the present application improves the upgrading efficiency of the software to be upgraded in the vehicle.

Description

Technical Field

[0001] This application relates to the field of intelligent driving technology, and in particular to a method, device and storage medium for upgrading vehicle software. Background Technology

[0002] As vehicles become increasingly intelligent, the types and number of in-vehicle software programs are also growing. In some scenarios, it is necessary to upgrade these in-vehicle software programs.

[0003] In related technologies, when upgrading the various in-vehicle software deployed on a vehicle is required, a software upgrade program adapted to the intelligent driving chip corresponding to the in-vehicle software can be designed. The upgraded software is then performed according to this program. However, this method is relatively inefficient for upgrading in-vehicle software. Summary of the Invention

[0004] This application provides a method, device, and storage medium for upgrading vehicle software, thereby improving the efficiency of upgrading software in the vehicle.

[0005] In a first aspect, embodiments of this application provide a software upgrade method for a vehicle, comprising:

[0006] In response to the upgrade package download instruction sent by the cloud server, the upgrade package for the software to be upgraded in the vehicle is downloaded according to the upgrade package download instruction;

[0007] Upon receiving an upgrade instruction for the software to be upgraded, the software upgrade interface is invoked to determine the upgrade strategy for the software to be upgraded; the software upgrade interface is adapted to the underlying hardware operations of different automotive chips.

[0008] Based on the upgrade strategy and upgrade package, the software to be upgraded is upgraded.

[0009] In some embodiments, invoking a software upgrade interface to determine the upgrade strategy for the software to be upgraded includes:

[0010] The target chip corresponding to the software to be upgraded is determined through the software upgrade interface;

[0011] The upgrade strategy is determined based on the mapping relationship between the chip and the upgrade strategy, and the target chip.

[0012] In some embodiments, the software to be upgraded is upgraded based on an upgrade strategy and an upgrade package, including:

[0013] Determine the type of upgrade package; the upgrade package type is either a full package or a differential package.

[0014] The software to be upgraded is processed according to the upgrade package, upgrade strategy, and upgrade package type.

[0015] In some embodiments, the software to be upgraded is upgraded according to the upgrade strategy and the type of upgrade package, including:

[0016] Based on the type and type of the upgrade package, determine the target upgrade package for the software to be upgraded;

[0017] Based on the target upgrade package and upgrade strategy, the software to be upgraded is upgraded.

[0018] In some embodiments, determining the target upgrade package for the software to be upgraded based on the type and type of the upgrade package includes:

[0019] If the upgrade package type is a full package, then the upgrade package will be identified as the target upgrade package;

[0020] When the upgrade package is of the differential package type, the target upgrade package is determined based on the upgrade package and the current upgrade package of the software to be upgraded.

[0021] In some embodiments, downloading an upgrade package for the software to be upgraded in the vehicle according to an upgrade package download instruction includes:

[0022] The upgrade package download command is parsed and processed to determine the download path of the upgrade package;

[0023] Download the upgrade package from the download path.

[0024] In some embodiments, the upgrade package is generated by the cloud server based on the vehicle information and the hardware and software information of the target chip corresponding to the software to be upgraded; the vehicle information and the hardware and software information are sent by the vehicle to the cloud server.

[0025] In some embodiments, after receiving the upgrade package download instruction, the method further includes:

[0026] The upgrade package download command is parsed and processed to obtain the version information of the upgrade package;

[0027] Determine whether an upgrade package needs to be downloaded based on the version information and the current version information of the software to be upgraded;

[0028] If an upgrade package needs to be downloaded, download the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instructions.

[0029] In some embodiments, determining whether an upgrade package needs to be downloaded based on version information and the current version information of the software to be upgraded includes:

[0030] If the version information differs from the current version information, it is determined that an upgrade package needs to be downloaded;

[0031] If the version information is the same as the current version information, it is determined that no upgrade package needs to be downloaded.

[0032] In some embodiments, after downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction, the method further includes:

[0033] Determine the download result of the upgrade package; the download result is either successful or failed.

[0034] Send the download results to the cloud server.

[0035] In some embodiments, an interactive interface is deployed on the vehicle, and if the download result is successful, the method further includes:

[0036] The software upgrade prompt is displayed on the interactive interface to indicate whether the software to be upgraded should be upgraded.

[0037] In response to the confirmation upgrade action on the interactive interface, confirm that the upgrade instruction has been received.

[0038] In some embodiments, the upgrade package includes a verification code for the upgrade package. After downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction, the method further includes:

[0039] The upgrade package is processed based on a preset hash algorithm to obtain the hash value of the upgrade package;

[0040] The verification result of the upgrade package is determined based on the hash value and the checksum; the verification result is either successful or unsuccessful.

[0041] In some embodiments, determining the verification result of the upgrade package based on the hash value and the checksum includes:

[0042] If the hash value and the checksum are the same, the verification result is determined to be successful.

[0043] If the hash value and the checksum are different, the verification result is determined to be a verification failure.

[0044] In some embodiments, during the upgrade process of the software to be upgraded, the method further includes:

[0045] The upgrade progress and status of the software to be upgraded are determined according to a preset cycle; the upgrade status is either normal or abnormal.

[0046] The upgrade progress and status are displayed on the interactive interface.

[0047] In some embodiments, when the upgrade status is abnormal, the method further includes:

[0048] Terminate the upgrade process for the software to be upgraded and control the software to run at the current version;

[0049] Identify the fault information that led to the upgrade of the software.

[0050] Secondly, embodiments of this application provide a vehicle software upgrade device, the device comprising:

[0051] The download module is used to respond to the upgrade package download instruction sent by the cloud server and download the upgrade package of the software to be upgraded in the vehicle according to the upgrade package download instruction;

[0052] The determination module is used to call the software upgrade interface to determine the upgrade strategy for the software to be upgraded when an upgrade instruction for the software to be upgraded is received; the software upgrade interface is adapted to the underlying hardware operations of different automotive chips.

[0053] The upgrade module is used to upgrade the software to be upgraded based on the upgrade strategy and upgrade package.

[0054] In some embodiments, the determining module is specifically used for:

[0055] The target chip corresponding to the software to be upgraded is determined through the software upgrade interface;

[0056] The upgrade strategy is determined based on the mapping relationship between the chip and the upgrade strategy, and the target chip.

[0057] In some embodiments, the upgrade module is specifically used for:

[0058] Determine the type of upgrade package; the upgrade package type is either a full package or a differential package.

[0059] The software to be upgraded is processed according to the upgrade package, upgrade strategy, and upgrade package type.

[0060] In some embodiments, the upgrade module is specifically used for:

[0061] Based on the type and type of the upgrade package, determine the target upgrade package for the software to be upgraded;

[0062] Based on the target upgrade package and upgrade strategy, the software to be upgraded is upgraded.

[0063] In some embodiments, the upgrade module is specifically used for:

[0064] If the upgrade package type is a full package, then the upgrade package will be identified as the target upgrade package;

[0065] When the upgrade package is of the differential package type, the target upgrade package is determined based on the upgrade package and the current upgrade package of the software to be upgraded.

[0066] In some embodiments, the download module is specifically used for:

[0067] The upgrade package download command is parsed and processed to determine the download path of the upgrade package;

[0068] Download the upgrade package from the download path.

[0069] In some embodiments, the upgrade package is generated by the cloud server based on the vehicle information and the hardware and software information of the target chip corresponding to the software to be upgraded; the vehicle information and the hardware and software information are sent by the vehicle to the cloud server.

[0070] In some embodiments, after receiving the upgrade package download instruction, the device further includes a first processing module, which is specifically used for:

[0071] The upgrade package download command is parsed and processed to obtain the version information of the upgrade package;

[0072] Determine whether an upgrade package needs to be downloaded based on the version information and the current version information of the software to be upgraded;

[0073] If an upgrade package needs to be downloaded, download the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instructions.

[0074] In some embodiments, the first processing module is specifically used for:

[0075] If the version information differs from the current version information, it is determined that an upgrade package needs to be downloaded;

[0076] If the version information is the same as the current version information, it is determined that no upgrade package needs to be downloaded.

[0077] In some embodiments, after downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction, the device further includes a second processing module, the second processing module being specifically used for:

[0078] Determine the download result of the upgrade package; the download result is either successful or failed.

[0079] Send the download results to the cloud server.

[0080] In some embodiments, an interactive interface is deployed on the vehicle, and if the download result is successful, the second processing module is further configured to:

[0081] The software upgrade prompt is displayed on the interactive interface to indicate whether the software to be upgraded should be upgraded.

[0082] In response to the confirmation upgrade action on the interactive interface, confirm that the upgrade instruction has been received.

[0083] In some embodiments, the upgrade package includes a verification code for the upgrade package. The device downloads the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction. The device also includes a verification module, which is specifically used for:

[0084] The upgrade package is processed based on a preset hash algorithm to obtain the hash value of the upgrade package;

[0085] The verification result of the upgrade package is determined based on the hash value and the checksum; the verification result is either successful or unsuccessful.

[0086] In some embodiments, the verification module is specifically used for:

[0087] If the hash value and the checksum are the same, the verification result is determined to be successful.

[0088] If the hash value and the checksum are different, the verification result is determined to be a verification failure.

[0089] In some embodiments, during the upgrade process of the software to be upgraded, the apparatus further includes a third processing module, which is specifically used for:

[0090] The upgrade progress and status of the software to be upgraded are determined according to a preset cycle; the upgrade status is either normal or abnormal.

[0091] The upgrade progress and status are displayed on the interactive interface.

[0092] In some embodiments, when the upgrade status is an abnormal state, the third processing module is further configured to:

[0093] Terminate the upgrade process for the software to be upgraded and control the software to run at the current version;

[0094] Identify the fault information that led to the upgrade of the software.

[0095] Thirdly, embodiments of this application provide a software upgrade device for a vehicle, comprising:

[0096] At least one processor; and

[0097] A memory that is communicatively connected to at least one processor; wherein,

[0098] The memory stores instructions that can be executed by at least one processor to cause the at least one processor to perform the software upgrade method for the vehicle involved in the first aspect and any possible implementation.

[0099] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the software upgrade method for a vehicle as described in the first aspect and any possible implementation.

[0100] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the software upgrade method for a vehicle as described in the first aspect and any possible implementation.

[0101] The vehicle software upgrade method, device, and storage medium provided in this application embodiment allow the vehicle to obtain the upgrade package of the software to be upgraded by responding to a download command issued by the cloud. Upon receiving the upgrade command, the vehicle calls a unified software upgrade interface that is compatible with the underlying hardware operations of different automotive chips to determine the upgrade strategy, thus unifying the entire process of upgrade package download, upgrade strategy matching, and software upgrade execution. Therefore, the vehicle software upgrade method provided in this application can shield the underlying upgrade differences between different automotive chip platforms, ensuring a high degree of consistency in the software upgrade process across multiple chip platforms. This improves the cross-platform compatibility and overall upgrade reliability of vehicle software upgrades, avoids the need to repeatedly develop adaptation programs for each chip platform, and thereby improves the efficiency of automotive software upgrades. Attached Figure Description

[0102] 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.

[0103] Figure 1 This is a schematic diagram illustrating the applicable scenarios provided in the embodiments of this application;

[0104] Figure 2 A schematic flowchart illustrating a vehicle software upgrade method provided in an embodiment of this application;

[0105] Figure 3 A schematic diagram illustrating a download upgrade package provided in an embodiment of this application;

[0106] Figure 4 This application provides a schematic diagram of a process for upgrading software to be upgraded, as illustrated in an embodiment of the present application.

[0107] Figure 5 This application provides a schematic diagram of the architecture of a cloud server.

[0108] Figure 6 A platform-based schematic diagram of an OTA toolchain provided in this application embodiment;

[0109] Figure 7This is a schematic diagram illustrating how a packaging tool generates an upgrade package, as provided in an embodiment of this application.

[0110] Figure 8 This application provides a schematic diagram illustrating the packaging process for an upgrade package.

[0111] Figure 9 A schematic diagram of a vehicle architecture provided for an embodiment of this application;

[0112] Figure 10 A schematic diagram of a chip call interface submodule provided in an embodiment of this application;

[0113] Figure 11 A schematic diagram illustrating an OTA (Over-The-Air) host computer upgrade provided in an embodiment of this application;

[0114] Figure 12 A schematic diagram of a vehicle software upgrade device provided in an embodiment of this application;

[0115] Figure 13 This is a schematic diagram of the structure of a vehicle software upgrade device provided in an embodiment of this application.

[0116] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0117] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0118] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0119] To facilitate understanding, the following will be combined with... Figure 1 The application scenarios applicable to the embodiments of this application will be briefly described below.

[0120] Figure 1 This is a schematic diagram illustrating the applicable scenarios provided in the embodiments of this application, such as... Figure 1 As shown, the system includes a cloud server 11 and a vehicle 12. The vehicle 12 houses multiple in-vehicle software applications. For example, the multiple in-vehicle software applications include vehicle software 1 and vehicle software 2.

[0121] In practical applications, taking in-vehicle software 1 as an example, cloud server 11 can compare the current version information of in-vehicle software 1 reported by vehicle 12 with the latest version information of in-vehicle software 1 in cloud server 11 in real time. If the latest version information differs from the current version information, an upgrade package for in-vehicle software 1 is generated, and a download instruction for the upgrade package is sent to vehicle 12. Vehicle 12 can download the upgrade package for in-vehicle software 1 according to the download instruction and upgrade in-vehicle software 1 based on the upgrade package.

[0122] It should be noted that, Figure 1 This is merely an example to illustrate a system architecture diagram, and is not a limitation on system architecture diagrams.

[0123] As vehicles become increasingly intelligent, the types and number of in-vehicle software programs are also growing. In some scenarios, it is necessary to upgrade these in-vehicle software programs. One such upgrade method is over-the-air (OTA) technology.

[0124] In related technologies, when upgrading the various in-vehicle software deployed on a vehicle is required, a cloud server can design a software upgrade program adapted to the target chip based on the chip type and the underlying upgrade strategy of that chip type, and then send the upgrade task to the vehicle. The upgrade task includes the software upgrade program and upgrade package for the software to be upgraded. After receiving the upgrade task, the vehicle can parse and process it to obtain the software upgrade program and upgrade package. The vehicle then uses the software upgrade program to call the underlying interface of the target chip and upgrades the software to be upgraded based on the upgrade package to obtain the upgraded in-vehicle software.

[0125] However, different target chip types have significantly different underlying hardware and software architectures, requiring the design of separate software upgrade programs for each target chip, resulting in low upgrade efficiency. Furthermore, vehicles typically deploy multiple automotive chips, and upgrading the software for multiple chips involves a significant workload for staff who repeatedly develop upgrade programs for each chip.

[0126] To address the aforementioned technical issues, this application provides a vehicle software upgrade method. The vehicle obtains the upgrade package for the software to be upgraded by responding to a download command issued from the cloud. Upon receiving the upgrade command, the vehicle calls a unified software upgrade interface that is compatible with the underlying hardware operations of different automotive chips to determine the upgrade strategy. This unifies the entire process of upgrade package download, upgrade strategy matching, and software upgrade execution. Therefore, the vehicle software upgrade method provided by this application can shield the underlying upgrade differences between different automotive chip platforms, ensuring a high degree of consistency in the software upgrade process across multiple chip platforms. This improves the cross-platform compatibility and overall reliability of vehicle software upgrades, avoids the need for repeatedly developing adaptation programs for each chip platform, thereby improving the efficiency of automotive software upgrades and reducing the workload of manually developing repetitive software programs.

[0127] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0128] Figure 2 This is a schematic flowchart illustrating a vehicle software upgrade method provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 The method may include the following steps:

[0129] S21. In response to the upgrade package download instruction sent by the cloud server, download the upgrade package of the software to be upgraded in the vehicle according to the upgrade package download instruction.

[0130] The cloud server is a service cluster deployed in the remote backend of the vehicle. It undertakes the OTA management function of the whole vehicle, can store various in-vehicle software upgrade packages, maintain the vehicle software and hardware version ledger, can issue download instructions to the vehicle, receive version information and upgrade results reported by the vehicle, and realize remote unified management and control of the software update tasks of the entire network of vehicles.

[0131] The vehicle is the subject of this application. It is equipped with multiple domain controllers, various vehicle chips and vehicle software, and can establish communication connections with cloud servers. It can receive various instructions issued by the cloud and complete OTA local execution processes such as upgrade package download, policy parsing, firmware flashing, and status reporting.

[0132] The upgrade package download command is a standardized signaling message sent from the cloud server to the vehicle. In some embodiments, the upgrade package download command carries information such as the upgrade package access address, the target on-board device identifier, and the target software version. The upgrade package download command is used to notify the vehicle to start the resource retrieval process, serving as the trigger for the vehicle to begin downloading the upgrade package.

[0133] The software to be upgraded consists of the vehicle firmware and applications running on the vehicle domain controller and intelligent driving chip, and new versions exist for iterative updates. The upgrade package is a data package encapsulating the firmware resources of the software to be upgraded, integrating information such as firmware configuration, partition configuration, hash verification data, and version compatibility identifiers. In some embodiments, the upgrade package can be a binary package file.

[0134] In some embodiments, the cloud server can compare the current version information of the software to be upgraded reported by the vehicle with the latest version information of the software to be upgraded. If the current version information and the latest version information are inconsistent, an upgrade package download instruction is generated and sent to the vehicle. After receiving the upgrade package download instruction, the vehicle can parse the upgrade package download instruction to obtain the download address of the upgrade package of the software to be upgraded, and download the software to be upgraded based on the download address.

[0135] S22. Upon receiving an upgrade instruction for the software to be upgraded, the software upgrade interface is invoked to determine the upgrade strategy for the software to be upgraded; the software upgrade interface is adapted to the underlying hardware operations of different vehicle chips.

[0136] The upgrade command is used to notify the vehicle to officially start the flashing process for the software to be upgraded.

[0137] The software upgrade interface is a pre-defined standardized program call interface in the vehicle, with unified input parameters, output parameters, and call timing specifications. In some embodiments, the software upgrade interface can serve as an intermediary layer between upper-layer upgrade services and lower-layer chip drivers in the vehicle, providing a unified call entry point, being compatible with multiple automotive chips, and isolating the differentiated hardware operation logic of various chips.

[0138] The software upgrade interface can encapsulate the underlying hardware operations of different automotive chips. These underlying hardware operations may include, for example, flash memory erasure and writing, storage partition switching, boot sector update, boot flag writing, rollback flag setting, chip reset control, hardware status reading, and security access control, as well as other chip-specific operations.

[0139] An upgrade strategy is a set of control information that guides the software to be upgraded on how to perform the upgrade. In some embodiments, an upgrade strategy may include upgrade processing order, pre-upgrade checks, target write area, write method, activation conditions, restart requirements, rollback conditions, and upgrade result determination rules.

[0140] In some embodiments, an interactive interface is deployed on the vehicle. The interactive interface is a visual human-machine interface deployed inside the vehicle. When the vehicle successfully downloads the upgrade package, a software upgrade prompt for the software to be upgraded can be displayed on the interactive interface; the software upgrade prompt is used to indicate whether to proceed with the upgrade process; in response to a confirmation upgrade operation on the interactive interface, it is confirmed that the upgrade instruction has been received.

[0141] Software upgrade prompts are visual prompts displayed on the vehicle's interactive interface to inform drivers and passengers that there is a new version of software available for upgrade. The prompts clearly indicate whether drivers and passengers should initiate the upgrade process for the software to be upgraded, thus enabling pre-confirmation of the upgrade action.

[0142] Optionally, in response to a driver or passenger clicking "Confirm Upgrade" on the interactive interface, the vehicle can confirm that it has received the upgrade command. Optionally, the driver or passenger can send the upgrade command to the vehicle via the client.

[0143] In some embodiments, when a vehicle receives an upgrade command, it does not directly enter the flashing process. Instead, it passes the software identifier to be upgraded, upgrade package metadata, the vehicle's current chip platform identifier, the current power status, the vehicle's operating status, and local version information as input parameters to the software upgrade interface, so that the software upgrade interface can output an upgrade strategy suitable for the current software to be upgraded.

[0144] In some embodiments, the vehicle may determine the upgrade strategy as follows: determine the target chip corresponding to the software to be upgraded through the software upgrade interface; determine the upgrade strategy based on the mapping relationship between the chip and the upgrade strategy and the target chip.

[0145] The target chip is the automotive chip hardware that carries the software to be upgraded. The target chip can be, for example, a System-on-Chip (SOC) chip or a Microcontroller Unit (MCU) chip. In some embodiments, different target chips have different memory management and firmware burning mechanisms, and their corresponding upgrade constraints are different.

[0146] The mapping relationship between chips and upgrade strategies is established through a pre-stored rule data table on the vehicle's local machine, binding various automotive chip models with their specific upgrade execution rules. This mapping relationship records information such as flashing methods, verification rules, and partition control requirements for different chips.

[0147] In some embodiments, the vehicle can determine whether a target chip exists in the mapping relationship between chips and upgrade strategies, and if a target chip exists, determine the upgrade strategy corresponding to the target chip as the upgrade strategy for the software to be upgraded.

[0148] S23. Based on the upgrade strategy and upgrade package, perform upgrade processing on the software to be upgraded.

[0149] In some embodiments, after downloading the upgrade package and determining the upgrade strategy, the vehicle can control the underlying upgrade execution unit to prepare the storage partition corresponding to the software to be upgraded, based on the target write area information in the upgrade strategy. This preparation includes, for example, erasing the spare partition, locking the currently running partition, setting the upgrade flag, or switching to upgrade session mode. Then, the vehicle writes the data from the upgrade package to the target area in a preset manner and confirms completion. For example, if the upgrade strategy is an A / B partition switching strategy, the vehicle writes the new version of the software information to the inactive partition and updates the boot selection flag after confirming successful writing. If the upgrade strategy is an in-place overwrite strategy, the vehicle erases and writes to the target area sequentially according to the strategy definition, while retaining the recovery information required for rollback. If the upgrade strategy requires controlling the sequential relationship of multiple software objects, the vehicle performs upgrades on each object sequentially according to the processing order defined in the strategy, proceeding to the next object only after the previous object's status meets the success condition.

[0150] exist Figure 2 In the illustrated embodiment, the vehicle obtains the upgrade package for the software to be upgraded by responding to a download command issued from the cloud. Upon receiving the upgrade command, it calls a unified software upgrade interface that is compatible with the underlying hardware operations of different automotive chips to determine the upgrade strategy, thus unifying the entire process of upgrade package download, upgrade strategy matching, and software upgrade execution. Therefore, the vehicle software upgrade method provided in this application can shield the underlying upgrade differences between different automotive chip platforms, ensuring a high degree of consistency in the software upgrade process across multiple chip platforms. This improves the cross-platform compatibility and overall upgrade reliability of vehicle software upgrades, avoids the need to repeatedly develop adaptation programs for each chip platform, and thereby improves the efficiency of automotive software upgrades.

[0151] exist Figure 2 Based on the illustrated embodiment, the following, in conjunction with Figure 3 The process of downloading the upgrade package for the vehicle in this embodiment is described. The process of determining the vehicle's driving status is further described.

[0152] Figure 3 This is a schematic diagram illustrating a process for downloading an upgrade package, as provided in an embodiment of this application. Figure 3 As shown, the process may include:

[0153] S31. Receive the upgrade package download instruction sent by the cloud server, parse the upgrade package download instruction, and obtain the download path of the upgrade package.

[0154] The download path is the resource location address of the upgrade package carried in the upgrade package download instruction, which is used to instruct the vehicle to pull the upgrade package from the storage location corresponding to the download path.

[0155] In some embodiments, when generating an upgrade package download instruction, the cloud server can include the download path in the instruction according to preset rules. Correspondingly, after receiving the upgrade package download instruction, the vehicle can parse the download path from the instruction according to preset rules.

[0156] S32. Send the download path to the cloud server.

[0157] In some embodiments, after receiving an upgrade package download instruction, the vehicle may send a download path to the cloud service so that the cloud server can determine that the vehicle has received the upgrade package download instruction.

[0158] S33. Download the upgrade package according to the download path.

[0159] The upgrade package is generated by the cloud server based on the vehicle information and the hardware and software information of the target chip corresponding to the software to be upgraded; the vehicle information and hardware and software information are sent by the vehicle to the cloud server.

[0160] Vehicle information is a set of data proactively reported by the vehicle to the cloud server, used to identify the vehicle and its hardware configuration. Vehicle information may include, for example, the vehicle identification number (VIN), vehicle model configuration, and the type of domain controller it uses. Hardware and software information is data reported by the vehicle reflecting the operating status of the target chip. Hardware and software information may include, for example, the target chip's model number, current firmware version, hardware parameters, and deployed software version.

[0161] In some embodiments, the cloud server can generate an upgrade package adapted to the current vehicle and target chip based on vehicle information and hardware / software information.

[0162] In some embodiments, after receiving an upgrade package download instruction, the vehicle can also parse the upgrade package download instruction to obtain the version information of the upgrade package; determine whether it is necessary to download the upgrade package based on the version information and the current version information of the software to be upgraded; if it is necessary to download the upgrade package, download the upgrade package of the software to be upgraded in the vehicle according to the upgrade package download instruction.

[0163] Version information is a data identifier that identifies the software version attribute within an upgrade package, including the new version number, version iteration identifier, and applicable hardware scope. Current version information refers to the version information of the upgrade package for the software to be upgraded, stored in the vehicle.

[0164] In some embodiments, the upgrade package download instruction carries version information of the upgrade package. The vehicle can parse the upgrade package download instruction to obtain the version information of the upgrade package. The vehicle can determine whether to download the upgrade package based on the version information and the current version information of the software to be upgraded in the following ways: if the version information is different from the current version information, it is determined that the upgrade package needs to be downloaded; if the version information is the same as the current version information, it is determined that the upgrade package does not need to be downloaded.

[0165] If the version information differs from the current version information, it indicates that the new version carried by the upgrade package is inconsistent with the existing software version in the vehicle, and the conditions for a version update are met. Therefore, the vehicle needs to download the upgrade package. If the version information is the same as the current version information, it indicates that the existing software version in the vehicle is consistent with the new version carried by the upgrade package, and there is no need to download the software package again. Therefore, it is determined that the upgrade package does not need to be downloaded.

[0166] Therefore, when a vehicle needs to download an upgrade package, it downloads the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction.

[0167] S34. Determine the download result of the upgrade package; the download result is either successful or failed.

[0168] The download result is a judgment conclusion formed after the vehicle completes the upgrade package transmission process, used to identify the completion status of this upgrade package data transmission task. In some embodiments, the download result is either download successful or download failed. A successful download indicates that the vehicle received all upgrade package data completely and without interruption, without any transmission interruption, data loss, file truncation, or other anomalies, and the vehicle can perform subsequent parsing and verification work based on this complete upgrade package. A download failure indicates that an abnormal situation occurred during the upgrade package transmission process, and the vehicle could not obtain available upgrade package resources, thus preventing the upgrade process from continuing. Abnormal situations may include, for example, communication disconnection, network timeout, data stream loss, or incomplete files.

[0169] Optionally, after downloading the upgrade package, the vehicle can perform a verification process on the upgrade package to determine the verification result. Specifically, the vehicle can process the upgrade package based on a preset hash algorithm to obtain the hash value of the upgrade package; determine the verification result of the upgrade package based on the hash value and the checksum; the verification result is either successful or unsuccessful.

[0170] The preset hash algorithm is a pre-configured, fixed one-way encryption rule used by the vehicle. This algorithm performs operations on the binary data of the complete upgrade package, generating a fixed-length verification message with unique data characteristics. Even a minor modification to the original upgrade package data will result in a significant change in the final output, thus verifying whether the upgrade package has been tampered with. The hash value is the verification message obtained after the vehicle processes the upgrade package using the preset hash algorithm. The checksum is the hash value obtained by the cloud server after processing the original upgrade package using the preset hash algorithm. In some embodiments, the upgrade package includes a checksum.

[0171] The verification result indicates whether the upgrade package has been tampered with. In some embodiments, the verification result is either verification passed or verification failed. Verification passed indicates that the upgrade package has not been tampered with. Verification failed indicates that the upgrade package has been tampered with.

[0172] After the vehicle receives the hash value of the upgrade package, the verification result can be determined based on the hash value and the checksum as follows: if the hash value and the checksum are the same, the verification result is determined to be successful; if the hash value and the checksum are different, the verification result is determined to be unsuccessful.

[0173] If the hash value and checksum match, it means the binary data of the upgrade package received by the vehicle is consistent with the original data sent by the cloud server. The upgrade package did not experience file corruption, data loss, or tampering during transmission and caching. Therefore, the vehicle determines the verification result as successful. If the hash value and checksum differ, it means the binary data of the upgrade package received by the vehicle differs from the original data sent by the cloud server. The upgrade package experienced file corruption, data loss, or tampering during transmission and caching. Therefore, the vehicle determines the verification result as failed.

[0174] In some embodiments, after downloading the upgrade package, the vehicle can determine the download result based on whether the download process was complete, whether it was interrupted, whether the verification was successful, and whether the storage was successful. Specifically, if the download process was complete, there was no download interruption, the verification was successful, and the storage was successful, the vehicle determines the download result as successful. If the download process was incomplete, there was a download interruption, the verification failed, or the storage failed at least once, the vehicle determines the download result as failed.

[0175] S35. Send the download results to the cloud server.

[0176] After confirming the download result, the vehicle can send the download result to the cloud server so that the cloud server can know in a timely manner whether the upgrade package has been successfully downloaded to the vehicle, and determine whether to resend the upgrade package download instruction accordingly.

[0177] exist Figure 3 In the illustrated embodiment, the vehicle obtains the upgrade package download path by parsing the upgrade package download command to retrieve the upgrade package. It compares the upgrade package version information sent by the cloud server with the current version information of the onboard software, triggering the download of the upgrade package as needed to avoid invalid transmission. Furthermore, after the download is complete, the download result is fed back to the cloud server for status synchronization, and upgrade human-machine confirmation is completed through the onboard interface. Simultaneously, a hash algorithm combined with a checksum is introduced to verify the integrity of the upgrade package. This enables the coordinated operation of each stage of the upgrade task pre-screening, transmission status control, human-machine authorization confirmation, and upgrade package security verification. While saving onboard communication traffic, it ensures that the upgrade package is not tampered with or damaged, improving the orderliness, security, and overall operational efficiency of the remote onboard software upgrade process.

[0178] Based on the above embodiments, the following is combined with Figure 4 The process of upgrading the software to be upgraded in the vehicle in the embodiments of this application will be further described.

[0179] Figure 4 This is a schematic diagram illustrating a process for upgrading software to be upgraded, provided as an embodiment of this application. Figure 4 As shown, the process may include the following steps:

[0180] S41. Upon receiving an upgrade instruction for the software to be upgraded, determine the type of the upgrade package; the upgrade package type is either a full package or a differential package.

[0181] The upgrade package type is a classification identifier used to distinguish the internal data structure and deployment method of the upgrade package. The upgrade package type is either a full package or a differential package. A full package indicates that the upgrade package contains a complete firmware image of the software to be upgraded, without relying on existing software files on the vehicle's local storage. Regardless of the current version of the onboard software, this upgrade package can be used directly to complete the complete flashing process. A differential package indicates that the upgrade package only stores the difference data between the old and new software versions and does not contain a complete firmware image. The vehicle needs to read the existing local software files and combine them with the differential data to synthesize a complete new firmware version.

[0182] In some embodiments, the upgrade package includes an upgrade package type identifier. After downloading the upgrade package, the vehicle can determine the type of the upgrade package based on the upgrade package type identifier within the upgrade package.

[0183] S42. Based on the upgrade package, upgrade strategy, and type of upgrade package, perform the upgrade process for the software to be upgraded.

[0184] In some embodiments, the vehicle may perform the upgrade process on the software to be upgraded based on the upgrade package, upgrade strategy, and upgrade package type as follows: determine the target upgrade package for the software to be upgraded based on the upgrade package type and upgrade package; and perform the upgrade process on the software to be upgraded based on the target upgrade package and upgrade strategy.

[0185] The target upgrade package is a valid software data package that can be directly used for chip-level programming, formed by parsing and restoring the original upgrade package based on the upgrade package type. In some embodiments, the vehicle determines the target upgrade package as follows: if the upgrade package type is a full package, the upgrade package is determined as the target upgrade package; if the upgrade package type is a differential package, the target upgrade package is determined based on the upgrade package and the current upgrade package of the software to be upgraded.

[0186] If the upgrade package is a full package, it means that the upgrade package already contains a complete, directly programmable firmware image of the software to be upgraded. It does not require splicing together existing local software files, so the vehicle can identify this upgrade package as the target upgrade package. If the upgrade package is a differential package, it means that the upgrade package only stores the differences between the old and new versions and lacks complete firmware resources. Therefore, it cannot be directly used for programming. The vehicle needs to perform a differential merging update based on the upgrade package and the existing local old software files to generate a complete firmware and obtain the target upgrade package.

[0187] In some embodiments, the vehicle can determine the firmware corresponding to the target chip in the target upgrade package and perform a burning operation on the firmware to achieve the upgrade processing of the software to be upgraded.

[0188] Optionally, before upgrading the software, the vehicle determines whether the target upgrade package is compatible with the target chip, and upgrades the software only if the target upgrade package is compatible with the target chip.

[0189] Optionally, before upgrading the software, the vehicle can determine its current battery level, parking status, and processor load, and based on these factors, determine whether the vehicle currently meets preset upgrade conditions. If the vehicle meets the preset upgrade conditions, the software upgrade is then performed.

[0190] Optionally, the vehicle can use a preset algorithm to verify the target upgrade package to determine its legality and completeness. If the target upgrade package is found to be legal and complete, the software to be upgraded will be upgraded.

[0191] S43. During the upgrade process of the software to be upgraded, the upgrade progress and upgrade status of the software to be upgraded are determined according to the preset cycle; the upgrade status is normal or abnormal.

[0192] The preset cycle is a fixed time interval rule pre-configured in the vehicle, used to specify how often the vehicle should collect upgrade-related data. Upgrade progress is a data indicator that quantifies the progress of the software upgrade process, visually reflecting the current completion percentage of the upgrade task, usually expressed as a percentage or stage indicator.

[0193] Upgrade status is a marker used to describe the overall operation of the upgrade process. In some embodiments, the upgrade status is either normal or abnormal. A normal status indicates that all steps of the current upgrade process are executing normally, without communication interruptions, writing failures, data verification errors, or other faults, and the target upgrade package can be successfully written to the hardware storage area. An abnormal status indicates that the upgrade process has encountered upgrade faults. These faults could include, for example, communication disconnection, writing errors, failed writing verification, or insufficient storage resources.

[0194] In some embodiments, the vehicle can continuously collect the amount of data that has been written and the total amount of data to be written during the firmware burning process, and calculate the current task completion percentage according to preset calculation rules based on the current parsing, burning, and verification process stages, thereby determining the upgrade progress.

[0195] The vehicle can collect multi-dimensional operational information during the software upgrade process, such as communication link status, burning return instructions, verification results, and hardware resource feedback signals. It can then compare this multi-dimensional operational information with preset information to determine the upgrade status.

[0196] S44. Display the upgrade progress and upgrade status on the interactive interface.

[0197] In some embodiments, after the vehicle determines the upgrade progress and status, it can display the real-time upgrade progress and status on the interactive interface to transform the background software upgrade process into visual information and eliminate information blind spots for drivers and passengers.

[0198] S45. If the upgrade status is abnormal, terminate the upgrade process of the software to be upgraded and control the software to be upgraded to run at the current version.

[0199] In some embodiments, when the upgrade status is abnormal, the vehicle can terminate the currently executing software upgrade process and stop performing subsequent operations such as firmware burning and partition writing, while controlling the vehicle system to continue running the version of software stored locally before the upgrade.

[0200] This allows for timely interruption of upgrade processes with potential failure risks, abandonment of new versions of the program that have not yet been deployed, and avoids issues such as domain controller crashes and malfunctions caused by attempting to run incomplete or defective new versions of the program. This ensures that the vehicle software maintains a stable and usable operating state and prevents the vehicle domain controller from becoming unavailable due to upgrade anomalies.

[0201] S46. Determine the fault information for upgrading the software.

[0202] The fault information is a standardized set of fault description data collected and summarized when an anomaly occurs during the vehicle upgrade process. Fault information may include, for example, the stage at which the fault occurred, the anomaly type code, the communication status, the upgrade package identifier, and the target chip number.

[0203] In some embodiments, when the upgrade status is abnormal, the vehicle can collect the corresponding abnormal code, the stage of the fault, the target chip identifier, and upgrade package related information, and process the above information to determine the fault information.

[0204] Optionally, after the vehicle has identified the fault information, it can send the fault information to the cloud server so that staff can analyze the fault and troubleshoot the problem.

[0205] exist Figure 4 In the illustrated embodiment, the vehicle can generate target upgrade packages using differentiated processing methods based on different types of upgrade packages and perform software upgrades in conjunction with upgrade strategies. During the upgrade execution phase, upgrade progress and status are periodically collected and displayed intuitively through an interactive interface, enabling visualized monitoring of the upgrade process. In the event of an abnormal upgrade status, the upgrade process can be promptly terminated, maintaining the continued operation of the current stable software version while generating corresponding fault information. This approach not only adapts to various upgrade package deployment schemes and standardizes the entire upgrade process logic but also mitigates the risks of system downtime and functional failures caused by upgrade anomalies, facilitating the tracing and troubleshooting of abnormal issues and improving the reliability and maintainability of the remote upgrade process for in-vehicle software.

[0206] The above embodiments illustrate the vehicle software upgrade method provided in this application. The cloud server and vehicle involved in this application will be further described below with reference to specific embodiments.

[0207] Figure 5 This document provides a schematic diagram of a cloud server architecture as an embodiment of this application. Figure 5As shown, the cloud servers include a vehicle cloud service platform, an OTA cloud service platform, a content delivery network (CDN) cloud service platform, a continuous integration / continuous delivery (CICD) platform, and an OTA toolchain.

[0208] The vehicle cloud server platform is a comprehensive cloud solution designed for intelligent connected vehicles. It provides services such as vehicle network access, unified vehicle management, in-vehicle data processing, and business compliance support, building a stable, reliable, and highly scalable foundation for connected vehicle services. The platform is bound to multiple unique identification information, including the vehicle identification number (VIN), serial number (SN), and integrated circuit card identifier (ICCID), ensuring reliable vehicle identification. For OTA (Over-The-Air) remote upgrades, the platform provides version scheduling capabilities, periodically pushing new software resources to vehicles to support the orderly implementation of remote software updates.

[0209] The OTA cloud service platform is a cloud-based infrastructure built on wireless networks, providing remote software upgrade capabilities for intelligent vehicles. It supports two types of online update services: Firmware Over-the-Air (FOTA) and Software Over-the-Air (SOTA). Based on remote distribution of new program versions, it enables vehicle function iteration, system vulnerability patching, and overall vehicle software performance optimization. The OTA cloud service platform supports collaborative upgrades across multiple vehicle-level controllers, covering various vehicle hardware units such as the powertrain, cockpit, and intelligent driving domains. It provides unified management of upgrade task scheduling, upgrade package distribution, upgrade status collection, and upgrade result aggregation for multiple hardware nodes, supporting remote management of the entire vehicle's software versions.

[0210] The CDN cloud service platform is a content delivery network solution customized for intelligent connected vehicle application scenarios. By deploying numerous edge caching nodes along roads, in urban areas, and at regional hubs, it caches large-capacity business data such as high-precision map data packets, OTA upgrade packages, and in-vehicle multimedia entertainment resources locally. When a vehicle initiates a data request, the nearest edge node provides the data transmission service, thereby shortening the data transmission distance, reducing network latency, achieving efficient distribution of large-capacity resources and a continuous, stable network connection, and ensuring that vehicles can obtain various critical in-vehicle business data in real time.

[0211] CICD is an automated system supporting continuous integration and continuous delivery of software, spanning the entire software lifecycle from code submission, software building, automated testing, version release to over-the-air (OTA) upgrades for the entire vehicle. In the context of intelligent vehicle R&D, CICD can transcend the application boundaries of traditional information technology environments, embed itself into automotive-grade development processes, and deeply collaborate with OTA cloud platforms to build an integrated closed-loop pipeline of "cloud-based R&D and building - automated testing and verification - security and compliance verification - batch canary release," continuously outputting verified and usable software versions to ensure efficient, safe, and controllable iteration of intelligent vehicle in-vehicle software.

[0212] The OTA toolchain is a complete set of tools supporting the development and release of OTA updates for vehicles. It is compatible with various automotive chip platforms and can create OTA upgrade packages in various formats, including full upgrade packages, differential upgrade packages, and independent single packages. It also provides secure signing capabilities for upgrade packages, ensuring that the upgrade packages are not tampered with during transmission and execution. The OTA toolchain interfaces with the CICD (Continuous Integration Center) system, completing the version packaging and security hardening processes to achieve a closed-loop, end-to-end cloud-based OTA business. It also provides a host computer for OTA development and debugging on various chip platforms, facilitating debugging and verification by staff and accelerating the iteration speed of automotive software versions.

[0213] The following is combined Figure 6 The OTA toolchain in the embodiments of this application is described. Figure 6 This is a platform-based schematic diagram of an OTA toolchain provided in an embodiment of this application. For example... Figure 6 As shown, the OTA toolchain includes two components: a packaging tool and an in-vehicle upgrade and debugging tool, providing a complete set of support capabilities for vehicle OTA software version distribution and debugging.

[0214] The packaging tool is designed for CI / CD (Continuous Integration) processes. Based on platform-based configuration and standardized unified compilation and packaging instructions, it supports automated generation of OTA (Over-The-Air) upgrade packages adapted to various chip platforms, outputs a unified binary format, and pushes it to the OTA cloud. Simultaneously, the packaging tool can build full OTA software upgrade packages adapted to SOC and MCU hardware carriers, supports generating corresponding signature files based on various RSA asymmetric encryption algorithms, supports differential upgrade package construction, and has built-in flexibly configurable upgrade verification strategies to implement control logic such as version rollback prevention, partition synchronization, partition verification, and file verification.

[0215] Regarding packaging tools, the following section combines... Figure 7 The process of generating upgrade packages using the packaging tool in the embodiments of this application is described. Figure 7 This diagram illustrates a packaging tool used to generate an upgrade package, as provided in an embodiment of this application. Figure 7As shown, the packaging tool can first perform initialization and image preparation. Specifically, for chip platforms 1 to n, the packaging tool pulls the corresponding underlying software image packages for each chip, simultaneously completes the application software package image building, and receives the software package resources output by the CICD pipeline integration and compilation to form complete image raw materials.

[0216] The packaging tool performs a unified signature operation on the collected software image packages and application software image packages, assigning each image a unique and trusted identifier to initially prevent image files from being tampered with. Then, based on the signed image resources, the packaging tool chooses to build a differential package or a full package as needed.

[0217] Furthermore, the packaging tool can compress and format the upgrade package, compressing and encapsulating the original data of the differential or full package, shielding the differences in file directories and resource layouts across different chip platforms, and encapsulating it into a unified and standardized data structure. Finally, the packaging tool can perform secure signing and cloud push, performing a hash operation on the standardized compressed upgrade package to obtain the corresponding hash digest value, then using the RSA algorithm to complete a secondary secure signature, generating a matching .rsa signature file, and finally pushing the complete OTA upgrade package with signature information and a unified binary encapsulation format (.cbf) to the OTA cloud platform for storage management. Specifically, this can be combined with... Figure 8 To understand.

[0218] The following is combined Figure 8 The process of packaging the upgrade package by the packaging tool in the embodiments of this application is described. Figure 8 This is a schematic diagram illustrating the packaging process of an upgrade package, as provided in an embodiment of this application. Figure 8 As shown, the underlying software package content and directory interface differ for different chip platforms. The packaging tool first aggregates various original upgrade resources such as image files, partition table configurations, OTA flashing programs, and configuration parameters, and compresses all resources into a .zstd or .zip archive. The packaging tool performs a hash operation on the compressed data package to generate a SHA256 or SHA512 hash digest, and combines it with a preset RSA algorithm to complete the signature operation, outputting a .rsa signature file to ensure that the upgrade package cannot be illegally tampered with during transmission.

[0219] Then, the packaging tool integrates the compressed data packet with the signature information, encapsulating it into a unified .cbf binary format file as the final upgrade package. This upgrade package contains embedded identification information such as the OTA upgrade package version number, compatible vehicle model information, domain controller hardware model, and supporting software version. Based on the unified .cbf binary encapsulation specification, the differences in the underlying resource structure of multiple chip platforms can be masked. The vehicle cloud platform can accurately distribute the upgrade package based on the compatibility information carried by the upgrade package, pushing the upgrade package only to vehicles with matching hardware conditions and prompting users to perform software version updates.

[0220] The vehicle-mounted upgrade and debugging tool is deployed locally on the vehicle's industrial control computer, performing OTA upgrades for hardware units such as the Autonomous Driving Domain Controller (ADCC). During the development and debugging phase, it supports flexible selection of various upgrade methods, including full packages, differential packages, and independent functional module upgrade packages, improving cross-platform adaptation and debugging convenience. The vehicle-mounted upgrade and debugging tool can also integrate with host computer tools to conduct system testing, verifying software versions released in the CICD pipeline, thus connecting the development, integration, and testing stages to form a complete software iteration closed loop.

[0221] Figure 9 This is a schematic diagram of a vehicle architecture provided as an embodiment of this application. For example... Figure 9 As shown, the vehicle is equipped with an Integrated Cockpit Controller (ICC) domain controller module and an ADCC domain controller module.

[0222] The ICC domain control module serves as the main control node for OTA upgrades within the vehicle OTA upgrade system. It is the core management hardware unit for in-vehicle OTA upgrade services, coordinating all processes including human-machine interaction, upgrade task scheduling, multi-ECU (Electronic Control Unit) flashing control, and vehicle-cloud data interaction. The ICC domain control module acts as the central hub for vehicle upgrade tasks, connecting various in-vehicle ECUs with cloud-based OTA services. It centrally handles version information collection, upgrade package distribution, status aggregation, and anomaly handling. Through the collaborative work of its internal sub-modules, it supports the implementation of multi-ECU collaborative remote upgrades for the entire vehicle.

[0223] In some embodiments, the ICC domain control module includes a human-machine interaction sub-module, an OTA main control sub-module, and a diagnostic flashing host computer. The human-machine interaction sub-module is deployed inside the ICC domain control, and establishes a communication link with the OTA main control program based on the in-vehicle device management protocol. This sub-module undertakes the function of interaction between the driver and passengers and the vehicle-wide OTA upgrade system, can push software upgrade notifications and upgrade-related prompt information to users, receive user operation instructions such as confirming and canceling upgrades, display the OTA upgrade progress and upgrade operation status in real time, and synchronously push abnormality reminders when an upgrade fails, realizing visualization of the upgrade process and human-machine operation interaction.

[0224] The OTA main control sub-module is the main upgrade configuration management program in the ICC domain control module, and undertakes the core function of vehicle-cloud interaction. The OTA main control sub-module collects the software and hardware version information of all ECUs in the vehicle and uploads it to the OTA cloud server, receives the OTA upgrade task instruction issued by the cloud, and completes the upgrade task policy analysis and process scheduling. The OTA main control sub-module uniformly manages the download, security signature verification, local storage of the upgrade package and the distribution work to each ECU, continuously collects the download status and upgrade execution result of each ECU and transmits them back to the cloud. At the same time, the OTA main control sub-module has advanced management capabilities such as remote diagnosis, breakpoint resume transmission, power-off resume upgrade, OTA upgrade abnormality identification and emergency disposal, ensuring the stable and reliable execution of the vehicle-wide upgrade process.

[0225] The diagnostic flashing host computer is a diagnostic control node supporting the ICC domain control, and is responsible for the sending and receiving of instructions related to in-vehicle diagnosis of the whole vehicle. The diagnostic flashing host computer can read various on-board ECU hardware identifiers, version information and operating parameters, issue flashing control instructions to manage the software upgrade action of each ECU, continuously collect the upgrade execution status and fault information of each electronic unit in the whole vehicle range, provide underlying diagnostic data support for the OTA main control sub-module, cooperate to complete the orderly flashing of the full-domain controllers, and ensure that the whole vehicle upgrade process is monitorable and traceable.

[0226] The ADCC domain control module is the OTA upgrade slave control node in the vehicle-wide OTA architecture, which is used to receive the upgrade instruction issued by the ICC domain control, undertake the function of remote self-upgrade execution of the software of ADCC related hardware units, rely on the collaboration of multiple internal functional sub-modules to complete communication transmission, security verification, image restoration and underlying chip flashing, adapt to the differentiated hardware environments of multiple types of chip platforms, can cooperate with the ICC domain control to realize the multi-domain hierarchical collaborative upgrade of the whole vehicle, and complete the software version iteration, fault repair and function optimization of each controller in the ADCC domain.

[0227] In some embodiments, the ADCC domain controller module includes a diagnostic communication and download engine submodule, an OTA platform submodule, a chip call interface submodule, and a differential engine submodule. The diagnostic communication and download engine submodule is based on the Diagnostic Communication over Internet Protocol (DoIP) protocol to build a standardized Unified Diagnostic Services (UDS) flashing service program. It establishes an interaction channel through the vehicle-cloud OTA unified interface and the OTA platform service program to manage the ADCC domain controller's self-upgrade process and simultaneously feed back various OTA upgrade operation statuses to the ICC domain controller's diagnostic flashing host computer. The download engine relies on the DoIP transmission protocol to complete the reception of OTA package data and store it in dedicated storage space. The entire data download action is decoupled from the upgrade business execution process, enabling data pre-downloading, breakpoint resumption, and other capabilities to ensure stable and complete reception of upgrade package data.

[0228] The OTA platform submodule is a dedicated upgrade management service for the ADCC chip platform, implementing standardized vehicle-to-cloud OTA unified interface interaction logic. This submodule is responsible for collecting and reporting device hardware and software version information, performing system operation status self-checks, completing upgrade package decompression and parsing, RSA digital signature security verification, triggering the ADCC domain controller OTA self-upgrade process, continuously collecting upgrade progress and results, and reporting them to the upper-layer diagnostic service layer. It is the core service unit that coordinates ADCC domain controller upgrade security verification and process scheduling.

[0229] The chip call interface submodule provides a standardized and unified upgrade call interface adapted to various chip platforms, which can be directly called by the OTA platform submodule. It encapsulates unified functional interfaces for different chip platforms, and the interface capabilities mainly include hardware initialization, starting the upgrade task, terminating the upgrade task, reading the upgrade progress, querying the upgrade running status, reading the current system running partition, and performing system partition switching. This shields the differences in the underlying chip hardware and software interfaces, reducing the workload of adapting OTA upgrade programs for multiple chip platforms.

[0230] Specifically, it can be combined with Figure 10 To understand, Figure 10 This is a schematic diagram of a chip call interface submodule provided in an embodiment of this application. Figure 10 As shown, the chip call interface submodule includes the vehicle-cloud OTA unified interface, OTA platform service, chip OTA unified interface, and chip OTA adaptation module.

[0231] Among them, the unified vehicle-to-cloud OTA interface is a standardized top-level interface module for ADCC domain control to interact with the vehicle-to-cloud, and is used to carry the core docking functions of vehicle-to-cloud interaction for whole vehicle OTA business. This interface integrates a number of standardized interaction capabilities, including software development kit initialization, software development kit deinitialization, device host version number reporting feedback, upgrade start status notification, host upgrade task start, upgrade progress query, upgrade result query, differential upgrade pre-restore processing, pre-installation task start, pre-installation task stop, host version activation, and other full-set interface functions. It can fully support OTA command interaction, status synchronization and version management between the cloud and the vehicle, and provide a standardized vehicle-to-cloud interaction foundation for ADCC domain control OTA self-upgrade business.

[0232] The OTA platform service is the core upgrade business processing service for ADCC domain controllers, and it is composed of a client interaction unit, an internal communication unit, and a server processing unit. The OTA platform service encapsulates the client interaction unit into a platform-standard interface, which is then cross-compiled to generate a dynamic library, achieving layered decoupling of the vehicle-cloud OTA upgrade business logic. The internal communication unit of the OTA platform service relies on a proprietary communication protocol to complete internal data interaction and protocol parsing, establishing a data path between the client interaction unit and the server processing unit. The server processing unit, as the concrete implementation entity of the unified vehicle-cloud OTA interface, integrates functions such as version validity verification, upgrade package decompression and parsing, upgrade package security signature verification, upgrade progress and result summary statistics, system partition switching, and version activation and reset. It can also persistently store upgrade status markers and fault error codes, enabling the entire OTA upgrade process to be controllable, traceable, and location-based.

[0233] The unified chip OTA interface is a standardized, universal interface layer for ADCC domain controllers to interface with various underlying chip platforms, used to unify the OTA upgrade operation call specifications for various chips. This interface encapsulates the basic interface capabilities required for the entire chip upgrade process, mainly including core functions such as chip initialization, chip deinitialization, upgrade task initiation, upgrade task stopping, upgrade progress acquisition, upgrade running status acquisition, system current running partition query, and system partition switching. It can shield the underlying interface differences between different chip platforms, providing unified and stable underlying chip operation capabilities for upper-layer OTA services, and improving the universality and adaptability of OTA upgrades across multiple chip platforms.

[0234] The chip OTA adaptation module is an adaptation and conversion module that connects the ADCC domain controller with upper-layer OTA services and board-level underlying drivers. It is mainly used to complete the differentiated adaptation of OTA capabilities for different chip platforms. This module uniformly encapsulates the board-level underlying OTA upgrade standard interface, providing a unified call entry point for upper-layer services. It performs targeted adaptation development for different chip platforms. For chip platforms where the underlying board-level driver has fully implemented the OTA upgrade interface, the underlying capabilities can be directly reused to complete the upgrade call. For chip platforms with incomplete underlying interfaces, this module can be used to complete the adaptation and expansion, supporting software OTA upgrades for various hardware carriers such as on-chip systems, microcontrollers, switching equipment, and sensors, and achieving full-domain OTA upgrade compatibility and adaptation for multiple hardware and chip platforms.

[0235] The differential engine submodule is a cross-platform differential tool based on an open-source differential restoration algorithm, cross-compiled to provide differential upgrade support for the entire vehicle OTA system and coordinate the entire process of ADCC domain control differential upgrades. The differential engine submodule consists of two main parts: a cloud-based differential package generation tool and an on-board differential package restoration engine. The cloud-based tool is used to generate differential upgrade packages by comparing old and new versions. The on-board engine, relying on differential data and combining it with local baseline firmware, synthesizes a complete image, supporting OTA upgrade deployment in differential package format. This reduces the upgrade package transmission size, saves on-board network traffic, and adapts to remote upgrade needs in bandwidth-constrained scenarios.

[0236] In some embodiments, an OTA (Over-The-Air) host computer is also deployed in the vehicle. The OTA host computer is used during vehicle R&D, debugging, software testing, and bench verification phases, and is generally deployed in a test industrial control computer, interacting with vehicle domain controllers such as ADCC and ICC via the vehicle diagnostic communication link. In some scenarios, it is necessary to upgrade the OTA host computer. The following section combines... Figure 11 The process of upgrading the OTA host computer in the embodiments of this application will be described.

[0237] Figure 11 This is a schematic diagram illustrating an OTA (Over-The-Air) host computer upgrade provided in an embodiment of this application. Figure 11 As shown, the cloud server completes the creation, compression, secure signing, and packaging of the upgrade package, generates upgrade resources adapted to various automotive chip platforms, and distributes the completed upgrade package to an external test industrial control computer, providing a compliant upgrade data source for subsequent vehicle-side flashing and debugging.

[0238] The industrial control computer receives the upgrade package resource based on the supporting OTA host computer tool, and performs two types of core operations in parallel: on the one hand, it calls the corresponding diagnostic service to transmit the upgrade package file through the diagnostic download engine and store it in the vehicle's dedicated storage area; on the other hand, it sends a standardized diagnostic unified service protocol instruction to the vehicle diagnostic flashing service to complete the initialization wake-up and flashing preparation of the vehicle upgrade task, and establishes the upgrade interaction link between the host computer and the vehicle domain controller.

[0239] The vehicle-side diagnostic download engine accurately stores the OTA upgrade package transmitted from the host computer to a dedicated storage area in the system's preset path, achieving isolation and reliable storage of the upgrade package resources. Subsequently, the ADCC domain controller's OTA platform service can actively read the upgrade package itself and the corresponding signature file in the dedicated storage area, providing an effective data source for subsequent security verification and upgrade parsing.

[0240] After reading the upgrade resources, the OTA platform service sequentially completes preprocessing operations such as upgrade package decompression, integrity verification, and RSA security signature verification. Once the upgrade package is confirmed to be legal, complete, and untampered with, the vehicle OTA upgrade process is officially triggered. Simultaneously, based on the user datagram protocol's private communication protocol, the OTA platform service issues standardized upgrade execution commands to the lower-level chip's unified OTA interface through the vehicle-cloud OTA unified interface, establishing an upgrade call channel between the upper-layer service and the lower-level chip.

[0241] The vehicle employs differentiated flashing logic for upgrades based on the boot characteristics of different chip platforms: For the first type of chip platform that does not require switching boot partitions, the firmware flashing is initiated directly by calling the chip's underlying OTA upgrade capability, with real-time collection of upgrade progress and running status. After the upgrade is completed, a facet-off closing operation is performed; For the second type of chip platform that requires switching boot modes, the boot partition mode switch is completed first, and then the underlying OTA upgrade task is initiated, with the upgrade progress and status monitored throughout. After the upgrade is completed, facet-off closing operations are performed simultaneously to adapt to the upgrade and adaptation requirements of different hardware platforms.

[0242] During the entire system upgrade process, the OTA platform service continuously polls and monitors the upgrade progress, operating status, and abnormal information, and records the upgrade process data in real time. After all upgrade tasks are completed, the upgrade results, fault codes, and other key information are summarized in a unified manner to complete the closed-loop recording and reporting of upgrade data, thereby achieving traceability and controllability of the entire host computer OTA upgrade process.

[0243] Figure 12 This is a schematic diagram of a vehicle software upgrade device provided in an embodiment of this application. Please refer to [link / reference]. Figure 12 The vehicle's software upgrade device 120 may include:

[0244] Download module 121 is used to respond to the upgrade package download instruction sent by the cloud server and download the upgrade package of the software to be upgraded in the vehicle according to the upgrade package download instruction;

[0245] The determination module 122 is used to call the software upgrade interface to determine the upgrade strategy of the software to be upgraded when an upgrade instruction for the software to be upgraded is received; the software upgrade interface is adapted to the underlying hardware operation of different vehicle chips.

[0246] Upgrade module 123 is used to upgrade the software to be upgraded based on the upgrade strategy and upgrade package.

[0247] The vehicle software upgrade device 120 provided in this application embodiment can execute the technical solutions in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0248] Figure 13 This is a schematic diagram of the structure of a vehicle software upgrade device provided in an embodiment of this application. Figure 13 As shown, the vehicle's software upgrade device 130 may include a memory 131 and at least one processor 132. Exemplarily, the memory 131 and the at least one processor 132 are interconnected via a bus 133.

[0249] Memory 131 is used to store program instructions;

[0250] At least one processor 132 is configured to execute program instructions stored in the memory to cause the vehicle software upgrade device 130 to perform the vehicle software upgrade method in the above method embodiment.

[0251] Optionally, the aforementioned processor can be a central processing unit (CPU), a graphics processing unit (GPU), other general-purpose processors, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0252] The vehicle software upgrade device 130 provided in this application embodiment can execute the technical solutions in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.

[0253] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the vehicle software upgrade method as described in the above method embodiments.

[0254] This application provides a computer program product, including a computer program that, when executed by a processor, implements the vehicle software upgrade method described in the above method embodiments.

[0255] This application provides a chip that stores a computer program. When the computer program is executed by the chip, it implements the vehicle software upgrade method described in the above method embodiments.

[0256] This application provides a chip module that stores a computer program. When the computer program is executed by the chip module, it implements the vehicle software upgrade method described in the above method embodiments.

[0257] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0258] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0259] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0260] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0261] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, Field Programmable Gate Array (FPGA), DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random-Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0262] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0263] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0264] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0265] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for upgrading the software of a vehicle, characterized in that, Applied to vehicles, the method includes: In response to an upgrade package download instruction sent by the cloud server, the upgrade package for the software to be upgraded in the vehicle is downloaded according to the upgrade package download instruction; Upon receiving an upgrade instruction for the software to be upgraded, the software upgrade interface is invoked to determine the upgrade strategy for the software to be upgraded; the software upgrade interface is adapted to the underlying hardware operations of different automotive chips. Based on the upgrade strategy and the upgrade package, the software to be upgraded is upgraded.

2. The method according to claim 1, characterized in that, The step of calling the software upgrade interface to determine the upgrade strategy for the software to be upgraded includes: The target chip corresponding to the software to be upgraded is determined through the software upgrade interface; The upgrade strategy is determined based on the mapping relationship between the chip and the upgrade strategy.

3. The method according to claim 1 or 2, characterized in that, The upgrade process for the software to be upgraded, based on the upgrade strategy and the upgrade package, includes: The type of the upgrade package is determined; the upgrade package type is either a full package or a differential package. The software to be upgraded is upgraded according to the upgrade package, the upgrade strategy, and the type of the upgrade package.

4. The method according to claim 3, characterized in that, The step of upgrading the software to be upgraded according to the upgrade strategy and the type of the upgrade package includes: Based on the type of the upgrade package and the upgrade package itself, determine the target upgrade package for the software to be upgraded; The software to be upgraded is upgraded according to the target upgrade package and the upgrade strategy.

5. The method according to claim 4, characterized in that, The step of determining the target upgrade package for the software to be upgraded based on the type and the upgrade package includes: If the upgrade package type is the full package type, the upgrade package is determined as the target upgrade package; When the upgrade package type is the differential package type, the target upgrade package is determined based on the upgrade package and the current upgrade package of the software to be upgraded.

6. The method according to claim 1 or 2, characterized in that, The step of downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction includes: The download command for the upgrade package is parsed and processed to determine the download path of the upgrade package; Download the upgrade package according to the download path.

7. The method according to claim 1 or 2, characterized in that, The upgrade package is generated by the cloud server based on the vehicle information and the hardware and software information of the target chip corresponding to the software to be upgraded; the vehicle information and the hardware and software information are sent by the vehicle to the cloud server.

8. The method according to claim 1 or 2, characterized in that, After receiving the upgrade package download instruction, the method further includes: The upgrade package download command is parsed to obtain the version information of the upgrade package; Based on the version information and the current version information of the software to be upgraded, determine whether it is necessary to download the upgrade package; If the upgrade package needs to be downloaded, the upgrade package for the software to be upgraded in the vehicle is downloaded according to the upgrade package download instruction.

9. The method according to claim 8, characterized in that, The step of determining whether to download the upgrade package based on the version information and the current version information of the software to be upgraded includes: If the version information differs from the current version information, it is determined that the upgrade package needs to be downloaded; If the version information is the same as the current version information, it is determined that the upgrade package does not need to be downloaded.

10. The method according to claim 1 or 2, characterized in that, After downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction, the method further includes: Determine the download result of the upgrade package; the download result is either successful or failed. The download result is sent to the cloud server.

11. The method according to claim 10, characterized in that, The vehicle is equipped with an interactive interface. If the download result indicates a successful download, the method further includes: The interactive interface displays a software upgrade prompt for the software to be upgraded; the software upgrade prompt is used to indicate whether to upgrade the software to be upgraded. In response to the confirmation upgrade operation of the interactive interface, it is confirmed that the upgrade instruction has been received.

12. The method according to claim 1 or 2, characterized in that, The upgrade package includes a verification code for the upgrade package. After downloading the upgrade package for the software to be upgraded in the vehicle according to the upgrade package download instruction, the method further includes: The upgrade package is processed based on a preset hash algorithm to obtain the hash value of the upgrade package; The verification result of the upgrade package is determined based on the hash value and the checksum; the verification result is either successful or unsuccessful.

13. The method according to claim 12, characterized in that, The step of determining the verification result of the upgrade package based on the hash value and the checksum includes: If the hash value is the same as the check code, the verification result is determined to be a successful verification. If the hash value is different from the checksum, the check result is determined to be a check failure.

14. The method according to claim 1 or 2, characterized in that, During the upgrade process of the software to be upgraded, the method further includes: The upgrade progress and upgrade status of the software to be upgraded are determined according to a preset cycle; the upgrade status is either a normal status or an abnormal status. The upgrade progress and upgrade status are displayed on the interactive interface.

15. The method according to claim 14, characterized in that, In the case that the upgrade status is the abnormal status, the method further includes: Terminate the upgrade process for the software to be upgraded and control the software to run at the current version; The fault information for upgrading the software to be upgraded is determined.

16. A software upgrade device for a vehicle, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, causes the at least one processor to perform the software upgrade method for the vehicle according to any one of claims 1 to 15.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the software upgrade method for the vehicle as described in any one of claims 1 to 15.

18. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the software upgrade method for the vehicle according to any one of claims 1 to 15.

Images