Vehicle ota upgrade task pre-download method and device, and vehicle

Abstract

The embodiment of the present application relates to the technical field of over-the-air download, and discloses a vehicle OTA upgrade task pre-download method and device and a vehicle, which comprises the following steps: the vehicle receives upgrade task information and corresponding task state information; for a pre-release state, the vehicle acquires upgrade package version information carried in the upgrade task information, compares the upgrade package version information with ECU current version information cached locally, and if there is a version difference and the vehicle meets a download trigger condition, starts an upgrade package download process; for a release state, the vehicle detects a download state of an upgrade package corresponding to the OTA upgrade task information in the local cache, if the download state of the upgrade package is that all data of the upgrade package has been downloaded and passed verification, enters a waiting installation state; if the download state of the upgrade package is that part of the data has been downloaded, resumes the download process of the upgrade package; and if the data of the upgrade package has not been downloaded, starts the download process of the upgrade package. The present application improves the success rate of download.

Description

Technical Field

[0001] This invention relates to the field of over-the-air (OTA) download technology, specifically to a method, apparatus, and vehicle for pre-downloading vehicle OTA upgrade tasks. Background Technology

[0002] With the deep integration of the automotive industry and information technology, vehicles have gradually evolved from traditional means of transportation into intelligent and connected mobile terminals, and their popularity continues to increase, providing unprecedented flexibility and convenience for people's travel. However, in the process of rapidly upgrading the level of vehicle intelligence, the number of Electronic Control Units (ECUs) in vehicles has exploded, especially core intelligent ECUs such as intelligent driving domain controllers and in-vehicle infotainment systems. The functional complexity of their firmware programs is constantly increasing, resulting in a significant increase in the size of the corresponding Over-the-Air (OTA) upgrade package files. However, the transmission of large-capacity upgrade packages requires a large amount of network bandwidth resources, and the transmission time is greatly increased. This not only makes them susceptible to network fluctuations, leading to upgrade interruptions and failures, but may also affect the normal use of the vehicle's network functions.

[0003] Therefore, it is necessary to develop a new method, device, and vehicle for pre-downloading vehicle OTA upgrade tasks. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of this application is to provide a method, device and vehicle for pre-downloading vehicle OTA upgrade tasks, which can alleviate cloud bandwidth pressure and improve the success rate of download by pre-downloading OTA upgrade packages and handling differentiated download status.

[0005] In a first aspect, embodiments of this application provide a method for pre-downloading a vehicle OTA upgrade task, comprising the following steps:

[0006] The vehicle receives upgrade task information and corresponding task status information from the cloud, including pre-release status and release status.

[0007] In the pre-release state, the vehicle obtains the upgrade package version information carried in the upgrade task information, compares the upgrade package version information with the current ECU version information cached locally, and if there is a version difference, and the vehicle meets the download trigger conditions, the upgrade package download process is started.

[0008] Regarding the release status, the vehicle detects the download status of the upgrade package corresponding to the upgrade task information in the local cache. If the download status of the upgrade package is that all data of the upgrade package has been downloaded and verified, it enters the waiting-to-install status; if the download status of the upgrade package is that some data has been downloaded, the download process of the upgrade package is resumed; if the data of the upgrade package has not been downloaded, the download process of the upgrade package is started.

[0009] In the above technical solution, downloading is initiated based on version differences and download trigger conditions in the pre-release state, which can complete the pre-download of the upgrade package in advance, avoiding cloud bandwidth congestion caused by concentrated downloads after release (thus alleviating cloud bandwidth pressure) and excessively long vehicle download waiting times. In the release state, corresponding operations are performed based on the locally cached download status (e.g., fully completed, partially completed, and not downloaded), ensuring the continuity of the upgrade process. The pre-download mechanism allows users to directly enter the waiting-to-install state after the upgrade task is officially released without waiting for a long download. Differentiated processing for different download statuses avoids duplicate downloads or invalid operations (i.e., improving the download success rate) and reduces vehicle-side resource consumption.

[0010] One possible implementation supports resume download during the download of the software package. The resume download is achieved by the vehicle recording the segment information of the downloaded file in real time. If an abnormal situation occurs and the download is paused, the remaining part can be resumed based on the segment information after the normal download is restored.

[0011] The above technical solution avoids the need to start downloading the upgrade package from scratch in case of network fluctuations or power outages while the vehicle is in motion, significantly reducing the data consumption and time costs of repeated downloads. The design of real-time recording of segment information makes the download process resistant to interference, ensuring accurate resumption even after multiple interruptions, thus improving the success rate of downloading large upgrade packages on the vehicle side.

[0012] One possible implementation is that the vehicle detects the download status of the upgrade package corresponding to the upgrade task information in its local cache, specifically as follows:

[0013] If the hash value and version number of the local upgrade package and the target upgrade package in the cloud are the same and the download is complete, it is determined that all data of the upgrade package has been downloaded and verified.

[0014] If a portion of the pre-downloaded fragments of the upgrade package is stored locally, the version number and hash value of the pre-downloaded fragments are extracted and compared with the version number and hash value of the target upgrade package in the cloud. If the comparison is consistent, it is determined that part of the data has been downloaded, and the remaining part of the target upgrade package is downloaded.

[0015] If the version number and hash value of the pre-downloaded fragment stored locally are inconsistent with the version number and hash value of the target upgrade package, delete the pre-downloaded fragment and re-download the complete file of the target upgrade package.

[0016] In the above technical solution, the version number is used to distinguish the iterative versions of the upgrade package, and the hash value is used to verify file integrity. This dual verification effectively avoids the risk of upgrade failure due to outdated local fragment versions, file corruption, or tampering. Valid fragments can be directly resumed, while invalid fragments are deleted promptly. This avoids invalid fragments occupying storage space and prevents upgrade failures caused by fragment errors, thereby improving the utilization efficiency of storage resources.

[0017] One possible implementation also includes:

[0018] After the upgrade package is downloaded, store the upgrade package;

[0019] If the file size of the upgrade package is greater than the preset storage capacity threshold, it indicates that the upgrade package is a large-capacity upgrade package, and a large-capacity upgrade package caching strategy is adopted.

[0020] The specific cache placeholder strategy for large-capacity upgrade packages is as follows:

[0021] Implement a rule of not deleting large-capacity upgrade packages that are not necessary in the local cache. When downloading the same type of upgrade package again, first compare the upgrade package to be downloaded with the large-capacity upgrade package stored locally. If they match, the large-capacity upgrade package stored locally is reused directly. If they do not match, the large-capacity upgrade package stored locally is deleted and downloaded again.

[0022] In the above technical solution, when upgrade packages of the same type match, the cache is reused, eliminating the need for repeated downloads and saving vehicle traffic and cloud bandwidth. This is particularly suitable for frequent iteration scenarios involving large-capacity upgrade packages, such as vehicle controllers and autonomous driving systems. The control rule of not deleting unless absolutely necessary (e.g., deleting the large-capacity upgrade package in the local cache only when the upgrade package to be downloaded does not match the locally cached upgrade package, the local storage space reaches a preset threshold and the cached package has a lower priority than higher-priority files, the cached package data is corrupted, or a proactive deletion instruction is received; otherwise, the large-capacity upgrade package in the local cache is retained) avoids reuse failures caused by blindly deleting the cache. Deleting and re-downloading when there is a mismatch prevents invalid cache from occupying space, thus resolving the contradiction between storing and reusing large-capacity upgrade packages.

[0023] One possible implementation is to initiate a silent download mechanism for the upgrade package when the vehicle meets the download trigger conditions in the pre-release state. That is, the entire upgrade package download process is executed in the background, and the vehicle does not display any information related to the download.

[0024] In the above technical solution, silent downloading runs in the background without popping up a download interface to interfere with the user's driving operations or vehicle usage, thus avoiding the user's perception burden for non-urgent upgrade tasks. Silent downloading during the pre-release phase allows for the preparation of upgrade packages without the user's awareness, laying the foundation for rapid installation after release and shortening the waiting time from upgrade release to installation completion.

[0025] In one possible implementation, the upgrade task information also includes a recommended download time;

[0026] The silent download mechanism is triggered when the vehicle is powered on or when the vehicle is not used within the recommended download time.

[0027] In the above technical solution, downloading is initiated when the vehicle is powered on (e.g., while idling or charging) or during a recommended time period (e.g., during nighttime idleness). This avoids consuming network and computing resources while the user is driving or using the vehicle, ensuring that normal vehicle functions are not affected. Based on the triggering conditions of the recommended time, the vehicle can be guided to complete the download during periods of low network load and stable power supply, improving download speed and success rate.

[0028] In one possible implementation, the recommended download time is generated by the cloud based on its own resource utilization.

[0029] In the above technical solution, the cloud generates a recommended time based on its own resource utilization (such as bandwidth usage and server load), which can avoid peak cloud resource periods, prevent cloud congestion caused by a large number of vehicles downloading at the same time, and improve the overall stability of the OTA upgrade system.

[0030] One possible implementation involves displaying download progress when resuming or initiating the download process of the upgrade package in relation to the release status. The download progress includes at least one of the following: download completion percentage and estimated remaining download time.

[0031] In the above technical solution, the release status is a formal upgrade task, and displaying the download progress allows users to clearly understand the upgrade process and make it easier for them to arrange their time reasonably (such as choosing a free time to wait for the download to complete).

[0032] Secondly, embodiments of this application provide a vehicle OTA upgrade task pre-download device, which is deployed in a hybrid vehicle and includes a memory and a processor. The memory is used to store a computer program, and the processor is used to call the computer program to execute the vehicle OTA upgrade task pre-download method of this invention.

[0033] In the above technical solution, downloading is initiated based on version differences and download trigger conditions in the pre-release state, which can complete the pre-download of the upgrade package in advance, avoiding cloud bandwidth congestion caused by concentrated downloads after release (thus alleviating cloud bandwidth pressure) and excessively long vehicle download waiting times. In the release state, corresponding operations are performed based on the locally cached download status (e.g., fully completed, partially completed, and not downloaded), ensuring the continuity of the upgrade process. The pre-download mechanism allows users to directly enter the waiting-to-install state after the upgrade task is officially released without waiting for a long download. Differentiated processing for different download statuses avoids duplicate downloads or invalid operations (i.e., improving the download success rate) and reduces vehicle-side resource consumption.

[0034] Thirdly, embodiments of this application provide a vehicle that includes the vehicle OTA upgrade task pre-download device described in this invention. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.

[0036] Figure 1 This is a block diagram illustrating a vehicle-to-cloud connection as disclosed in an embodiment of this application;

[0037] Figure 2 This is a block diagram of a vehicle OTA upgrade task pre-download device disclosed in an embodiment of this application;

[0038] Figure 3 This is a block diagram of a vehicle-mounted terminal system disclosed in an embodiment of this application;

[0039] Figure 4 This is a block diagram of a cloud-based application disclosed in an embodiment of this application;

[0040] Figure 5 This is a flowchart of a vehicle OTA upgrade task pre-download method disclosed in an embodiment of this application;

[0041] Figure 6 This is a schematic diagram of the pre-download process disclosed in an embodiment of this application;

[0042] Explanation of reference numerals in the attached figures:

[0043] 1-Vehicle; 2-OTA upgrade task pre-download device; 21-Memory; 22-Processor; 3-Cloud; 31-Cloud task scheduling center; 32-Software distribution server; 33-Upgrade package database; 34-Vehicle information database; 4-Vehicle terminal system; 41-ECU control module; 42-Vehicle communication module; 43-Local processing module; 44-Local cache module. Detailed Implementation

[0044] The embodiments of this application will be described in further detail below with reference to the accompanying drawings and examples. The detailed description of the following embodiments and the accompanying drawings are used to illustrate the principles of this application by way of example, but should not be used to limit the scope of this application, that is, this application is not limited to the described embodiments.

[0045] Please see Figure 1 , Figure 1 This is a block diagram illustrating the connection between vehicle 1 and cloud 3 as disclosed in an embodiment of this application. Vehicle 1 can be, but is not limited to, a pure electric vehicle (PEV / BEV), a hybrid electric vehicle (HEV), a range-extended electric vehicle (REEV), a plug-in hybrid electric vehicle (PHEV), or a new energy vehicle. A vehicle 1 includes the vehicle OTA upgrade task pre-download device 2 of this application.

[0046] Please see Figure 2 , Figure 2 This is a block diagram of a vehicle OTA upgrade task pre-download device disclosed in an embodiment of this application, which is deployed in vehicle 1. The vehicle OTA upgrade task pre-download device 2 includes a memory 21 and a processor 22. The memory 21 is used to store computer programs, and the processor 22 is used to call the computer programs to execute the vehicle OTA upgrade task pre-download method in the embodiment of this application.

[0047] Please see Figure 3 , Figure 3This is a block diagram of the vehicle-mounted terminal system disclosed in this application embodiment. To realize the function of the vehicle OTA upgrade task pre-download device 2, the vehicle needs to be equipped with hardware including a vehicle-mounted terminal system 4. The vehicle-mounted terminal system 4 includes an ECU control module 41, a vehicle-mounted communication module 42, a local processing module 43, and a local cache module 44. The ECU control module 41 establishes communication with each ECU in the vehicle, executes the installation and deployment of upgrade packages, and provides feedback on the ECU upgrade status. The vehicle-mounted communication module 42 is responsible for establishing a communication connection with the cloud 3, realizing the periodic reporting of ECU hardware and software version information, receiving upgrade tasks, downloading upgrade packages, and providing feedback on upgrade status. The local processing module 43 is used to receive task information sent by the cloud 3, parse task parameters, and execute logic such as upgrade package download, cache management, and upgrade deployment scheduling. The local cache module 44 is used to store pre-downloaded upgrade package files and supports temporary storage and reuse of interrupted data. Furthermore, the vehicle 1 and the cloud 3 achieve data interaction and collaborative work through a wireless communication network.

[0048] Please see Figure 4 , Figure 4 The diagram below illustrates the cloud-based system 3 as disclosed in this application. To facilitate the implementation of the vehicle OTA upgrade task pre-download device 2, the cloud-based system 3 requires a cloud-based task scheduling center 31, a software distribution server 32, an upgrade package database 33, and a vehicle information database 34. The cloud-based task scheduling center 31, as the core control unit, is responsible for the creation, status management, distribution planning, and resource scheduling of upgrade tasks. It possesses functions such as vehicle information comparison, server resource monitoring, and task priority sorting. The software distribution server 32 stores OTA upgrade packages corresponding to various ECUs, provides distributed download services, and supports real-time monitoring and data reporting of bandwidth usage and connection count. The upgrade package database 33 stores upgrade package files of different versions and ECU models, along with corresponding version information and verification information. The vehicle information database 34 stores basic information of connected vehicles (vehicle model, vehicle identification number (VIN)), ECU configuration information (ECU hardware / software number, version), historical hardware / software version information, and real-time status data (network status, battery status), etc.

[0049] In order to facilitate the function of the vehicle OTA upgrade task pre-download device 2, the cloud task scheduling center 31 is configured to compare the ECU hardware and software version information reported by the vehicle periodically with the latest task version information in the upgrade package database 33. When it is determined that there is an ECU to be upgraded, the upgrade task issuance process is triggered.

[0050] To support the function of the vehicle OTA upgrade task pre-download device 2, the cloud task scheduling center 31 is also configured to: dynamically adjust the task distribution scope and order based on the current resource usage of the software distribution server 32 (bandwidth and number of connections) and the network status (network type and signal strength) and vehicle status (battery level and whether it is in motion) reported by the vehicle when issuing tasks. During the pre-release stage, tasks are issued in small batches and continuously to vehicles in the market. For example, when the bandwidth usage of the software distribution server 32 is found to be higher than a first preset threshold (e.g., 80%) during a certain period, the recommended download time field for a small number of vehicles with strong network signals and in a stationary state is set to this time period, and tasks are issued in small batches based on the recommended download time; or, the issuance of non-urgent tasks is delayed; when a time period with bandwidth usage lower than a second preset threshold (e.g., 30%) is identified, the task distribution scope is expanded, increasing the number of vehicles receiving tasks and starting downloads during this time period each day, ensuring efficient resource utilization.

[0051] Please see Figure 5 , Figure 5 This is a flowchart illustrating the vehicle OTA upgrade task pre-download method disclosed in an embodiment of this application.

[0052] In this embodiment of the application, a method for pre-downloading a vehicle OTA upgrade task includes the following steps:

[0053] The vehicle receives upgrade task information and corresponding task status information from the cloud. The task status information includes pre-release status and release status.

[0054] For the pre-release state, the vehicle obtains the upgrade package version information carried in the upgrade task information, compares the upgrade package version information with the current ECU version information cached locally, and if there is a version difference, and the vehicle meets the download trigger conditions, the upgrade package download process is started.

[0055] Regarding the release status, the vehicle checks the download status of the upgrade package corresponding to the upgrade task information in the local cache. If the download status of the upgrade package indicates that all data of the upgrade package has been downloaded and verified, it enters the waiting-to-install state; if the download status of the upgrade package indicates that some data has been downloaded, the download process of the upgrade package is resumed; if the data of the upgrade package has not been downloaded, the download process of the upgrade package is started.

[0056] This application initiates downloads based on version differences and download trigger conditions in the pre-release state, enabling early pre-download of the upgrade package. This avoids cloud bandwidth congestion (alleviating bandwidth pressure on Cloud 2) and excessively long download waiting times for Vehicle 1 caused by concentrated downloads after release. In the release state, corresponding operations are performed based on the locally cached download status (e.g., fully completed, partially completed, and not downloaded), ensuring the continuity of the upgrade process. The pre-download mechanism allows users to directly enter the installation-ready state after the upgrade task is officially released without waiting for a long download. Differentiated handling of different download statuses avoids duplicate downloads or invalid operations (i.e., improving the download success rate) and reduces resource consumption on the vehicle side.

[0057] In one possible embodiment, the task status information, in addition to the pre-release and release statuses mentioned above, also includes the task deactivated status. For different task statuses, the cloud-based task scheduling center 31 will execute different distribution logic, as follows:

[0058] Task deactivated: The cloud-based task scheduling center 31 will not issue upgrade tasks to any vehicles, which will not be elaborated here.

[0059] Pre-release status: The cloud-based task scheduling center 31 sets the task status to pre-release and simultaneously obtains real-time resource status data such as bandwidth utilization and current connection count from the software distribution server 32 to dynamically plan task distribution. For pre-release tasks, the task information distributed by the cloud 31 includes a task ID and a field for a recommended download time (this recommended download time is generated based on the resource utilization of the software distribution server 32, such as a period with low bandwidth utilization, such as 00:00-06:00 at night).

[0060] After receiving the OTA upgrade task information, the vehicle terminal system 4's local processing module 43 first extracts the upgrade package version information carried in the task information and performs a preliminary comparison with the ECU current version information stored in the local cache module 44. If there is a version difference and the vehicle meets the download trigger conditions, the upgrade package download process is started. At this time, the local processing module 43 automatically wakes up the vehicle communication module 42, the local cache module 44 and other related nodes to start the background download.

[0061] Release Status: The cloud-based task scheduling center 31 switches the task status to "release," meaning the cloud-based task scheduling center 31 officially releases the upgrade task and issues task instructions to all vehicles awaiting upgrades. When the vehicle-mounted terminal system 4 receives the task information in the release status, its local processing module 43 first checks whether the local cache module 44 already stores the upgrade package corresponding to the task information (i.e., the upgrade package that has been downloaded during the pre-release phase; if so, it directly displays a "pending installation" status prompt to the user). If it is stored, it directly enters the pending installation state; if it is not stored (e.g., the vehicle did not complete the download during the recommended pre-release period, or it is a newly connected vehicle) or only partially stored, for the case of no storage, the upgrade package download process is immediately initiated; for the case of only partially stored (i.e., only partial data pre-download is completed), the download process is immediately resumed.

[0062] In one possible embodiment, the download process supports resumeable interruptions. The vehicle records the downloaded file segments in real time. If an abnormal situation occurs (e.g., network interruption, vehicle power failure), the download is paused. Once normal operation is restored (e.g., network connection restored or vehicle power restored), the remaining portion is resumed based on the segment information, eliminating the need to re-transmit the complete file. This application addresses the issue of downloading upgrade packages from scratch due to network fluctuations or power outages while the vehicle is in motion, significantly reducing the bandwidth consumption and time costs of repeated downloads. The real-time segment information recording design makes the download process resistant to interference, allowing for accurate resumption even after multiple interruptions, thus improving the success rate of downloading large upgrade packages on the vehicle side.

[0063] In one possible embodiment, the vehicle detects the download status of the upgrade package corresponding to the upgrade task information in the local cache. Specifically, if the hash value and version number of the local upgrade package are consistent with those of the target upgrade package in the cloud, and the download is complete, it is determined that all data of the upgrade package has been downloaded and verified. If a partial pre-download fragment of the upgrade package is stored locally, the version number and hash value of the pre-download fragment are extracted and compared with the version number and hash value of the target upgrade package in the cloud. If the comparison is consistent, it is determined that part of the data has been downloaded, and the remaining part of the target upgrade package continues to be downloaded. If the version number and hash value of the pre-download fragment stored locally are inconsistent with the version number and hash value of the target upgrade package, the pre-download fragment is deleted, and the complete file of the target upgrade package is downloaded again to ensure the integrity of the upgrade package and the accuracy of the version. In this application, the version number is used to distinguish the iterative version of the upgrade package, and the hash value is used to verify the integrity of the file. The dual verification can effectively avoid the risk of upgrade failure due to outdated local fragment versions, file corruption, or tampering. Valid fragments can be directly resumed, while invalid fragments are deleted in a timely manner. This not only avoids invalid fragments occupying storage space but also prevents upgrade failures caused by fragmentation errors, thereby improving the utilization efficiency of storage resources.

[0064] In one possible embodiment, the method further includes: storing the upgrade package after downloading; if the file size of the upgrade package exceeds a preset storage capacity threshold, it indicates that the upgrade package is a large-capacity upgrade package, and a large-capacity upgrade package caching placeholder strategy is adopted. Specifically, the large-capacity upgrade package caching placeholder strategy involves: implementing a control rule of not deleting unnecessary large-capacity upgrade packages in the local cache; when downloading the same type of upgrade package again, first comparing the upgrade package to be downloaded with the locally stored large-capacity upgrade package for consistency; if they match, the locally cached large-capacity upgrade package is directly reused; if they do not match, the locally stored large-capacity upgrade package is deleted and downloaded again. Using local caching serves both as a placeholder, preventing insufficient storage space from causing download failures, and avoiding duplicate downloads.

[0065] In one possible embodiment, for the pre-release state, when the vehicle meets the download trigger conditions, a silent download mechanism for the upgrade package is initiated. This means the entire upgrade package download process is executed in the background, and the vehicle does not display any download-related information; that is, no UI interface or notification information is shown to the user, avoiding interference with the user's normal vehicle use. Silent downloading in the background does not cause the download interface to pop up and interfere with the user's driving operations or vehicle usage flow, avoiding the user's perception burden for non-urgent upgrade tasks. Silent downloading in the pre-release stage can complete the upgrade package preparation without the user's awareness, laying the foundation for rapid installation after release and shortening the waiting time from upgrade release to installation completion.

[0066] In one possible embodiment, since the upgrade task information also includes a recommended download time, the silent download mechanism is triggered when the vehicle is powered on or when the vehicle is not used during the recommended download time (i.e., it is off or in a dormant state). The download is initiated when the vehicle is powered on (e.g., idling or charging) or during the recommended download time (e.g., idle at night), avoiding the occupation of network and computing resources while the user is driving or using the vehicle, ensuring that normal vehicle functions are not affected. Based on the recommended time trigger condition, the vehicle can be guided to complete the download during periods of low network load and stable power supply, improving download speed and success rate.

[0067] In one possible embodiment, for the release status, when resuming and initiating the upgrade package download process, the download progress is displayed. The download progress includes at least one of the following: download completion percentage and estimated remaining download time. Since the release status represents a formal upgrade task, displaying the download progress allows users to clearly understand the upgrade process's progress, facilitating them to allocate their time appropriately (e.g., choosing a free time slot to wait for the download to complete).

[0068] In one possible embodiment, after the upgrade package is downloaded, the local processing module 43 performs an integrity check on the upgrade package (based on a preset hash algorithm to verify the consistency of the upgrade package). If the check passes, the upgrade package is stored in the local cache module 44 and associated with the corresponding task ID, ECU identifier and version information for easy subsequent installation and version tracking. If the check fails, a re-download process is triggered and a check failure log is sent to the cloud 3.

[0069] Please see Figure 6 , Figure 6 This is a schematic diagram of the pre-download process disclosed in an embodiment of this application.

[0070] For example, taking the upgrade of the intelligent driving domain controller of a 2023 intelligent connected sedan of a certain brand (target vehicle) as an example, the vehicle-cloud collaboration process in the OTA pre-release and release stages is explained in detail. The target vehicle is equipped with an intelligent driving domain controller (ECU model: HWA.100.23), the upgrade package size is 8GB, the current version of the target vehicle is SWD.1.5, and the target upgrade version is SWD.2.0.

[0071] 1. Implementation prerequisites

[0072] Cloud 3: Deploys a cloud task scheduling center 31, a software distribution server 32, an upgrade package database 33, and a vehicle information database 34. The upgrade package database 33 stores the target version SWD.2.0 upgrade package (hash value: SHA256-9B4668FD44DD00BECC23319F40E003AABDCEA5F8A0B0ED8B28075EC7ABFD8092). The vehicle information database 34 stores basic vehicle information (including VIN code, ECU configuration, and current version).

[0073] Vehicle-side terminal system configuration: Supports 4G / 5G communication, 16GB local cache, and has the function of collecting vehicle status (including power-on, sleep, driving and stationary). It supports downloading upgrade packages and installation conditions (e.g., stationary and battery level ≥ 30%) according to the pre-release recommended download time.

[0074] Resource thresholds: The first threshold for resource usage of the software distribution server 32 is 80%, and the second threshold is 30%. File comparison is based on software and hardware numbers, version numbers, and hash value verification, and supports breakpoint resume and version rollback.

[0075] Number of vehicles: 20,000.

[0076] Core Implementation Process (Focusing on Pre-release and Release Phases)

[0077] 2. Pre-process

[0078] After completing the upgrade package development (vehicle version release) and regulatory filing (regulatory filing) in Cloud 3, an upgrade task (task ID: OTA-2023-ADC-100.23) is created, and the core process begins.

[0079] 3. OTA pre-release

[0080] Cloud 3 task distribution logic:

[0081] The cloud-based task scheduling center 31 sets the task status to "pre-release" and monitors the bandwidth utilization of the software distribution server 32 in real time (assuming the current average bandwidth utilization is 25%, which is lower than 30%), and plans a recommended download time window (01:00-05:00).

[0082] The pre-release task is sent to all target vehicles in batches and time periods (each time period is 1 hour, each batch is 5,000 vehicles, and the target of 20,000 vehicles is sent within 4 hours). The task information includes: task ID, target version SWD.2.0, recommended download time, file hash value, and compatible ECU identifier. At the same time, the sending rate is dynamically adjusted based on the status data reported by the vehicles (network signal, battery level).

[0083] Vehicle-side download and processing logic:

[0084] After receiving the task, the vehicle communication module 42 compares the local ECU identifier with the target ECU, and the version (SWD.1.5) with the target version (SWD.2.0). After confirming the differences, the download preparation is started.

[0085] Scenario 1: When the vehicle is powered on and stationary within the recommended time (e.g., when the user temporarily parks), the background silent download will start directly without displaying any UI prompts. The download process supports resuming interrupted downloads (e.g., if the network is interrupted at 02:30, it will resume at 02:45 after the network is restored, and the download will continue based on the 4GB segments that have already been downloaded).

[0086] Scenario 2: When the vehicle is powered off and put to sleep within the recommended time (parked at night), the local processing module 43 automatically wakes up the vehicle communication module and the local cache module 44, starts silent download, and automatically puts the relevant nodes to sleep after the download is completed;

[0087] File verification: After downloading, the local file is compared with the target file in the cloud using a hash algorithm (the hash values ​​are consistent). If the verification is successful, the file is stored in the local cache module 44 and associated with the task ID and ECU identifier.

[0088] Pre-release phase results: 90% of the target vehicles (a total of 18,000 vehicles) completed the download and verification of the upgrade package during the pre-release phase, and the local cached valid upgrade package.

[0089] 4. Transition Process

[0090] Cloud-based 3-stage screening will be used to pre-download 10% of vehicles (2000 vehicles) to perform gray-scale testing, monitor the installation success rate (99.2%), and trigger the full release conditions after confirming no abnormalities and passing the regulatory filing.

[0091] 5. OTA Release (Core Process Two)

[0092] Cloud-based full distribution logic:

[0093] The cloud-based task scheduling center 31 switches the task status to "release" and issues the task release instruction to all 20,000 target vehicles, while simultaneously granting full download access to the software distribution server 32.

[0094] Vehicle-side differentiation processing logic:

[0095] Scenario 1: Vehicles that have completed pre-downloading (18,000 vehicles):

[0096] The local processing module 43 detects that there is a valid upgrade package in the local cache module 44 (same version number, same hash verification) and immediately displays a UI prompt on the vehicle's central control screen: "Intelligent driving system can be upgraded, do you want to install it now?"

[0097] After user confirmation, the vehicle status is checked (stationary + 35% battery, meeting installation conditions), and the installation process is started directly, with the installation progress (0%-100%) reported to the cloud in real time.

[0098] Scenario 2: Vehicles that have not completed pre-downloading (2000 vehicles):

[0099] Local processing module 43 starts downloading the upgrade package and displays the download progress (such as download percentage and remaining time) on the OTA user interface.

[0100] File comparison during download: ① If the local cache module 44 contains some pre-downloaded segments (e.g., 2GB), compare the version number and hash value with the target file, and continue downloading the remaining 6GB; ② If the version number of the local segment does not match the version number of the target file, or the local task hash value does not match the hash value of the target file, delete the local segment and download the complete package again.

[0101] 6. Post-installation testing and troubleshooting:

[0102] Vehicle-side terminal system self-test: After installation, the system reads and transmits the software version number of the ECU and reports it to the cloud.

[0103] Cloud-based 3D verification: The cloud-based 3D verification compares the version number (SWD.2.0) and hash value reported by the vehicle terminal system to confirm the validity of the upgrade.

[0104] Rollback mechanism: For the three vehicles that failed to install, the vehicle side automatically rolls back. The vehicle side calls the original version (SWD.1.5) upgrade package of the local cache module 44 to perform the rollback. After the rollback, it performs a self-check and reports again.

[0105] In this embodiment, the computer program may include program code, which includes computer-executable instructions. The memory may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The processor may be a central processing unit (CPU), a microcontroller unit (MCU), or an application-specific integrated circuit (ASIC).

[0106] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for pre-downloading vehicle OTA upgrade tasks, characterized in that, Includes the following steps: The vehicle receives upgrade task information and corresponding task status information from the cloud, including pre-release status and release status. In the pre-release state, the vehicle obtains the upgrade package version information carried in the upgrade task information, compares the upgrade package version information with the current ECU version information cached locally, and if there is a version difference, and the vehicle meets the download trigger conditions, the upgrade package download process is started. Regarding the release status, the vehicle detects the download status of the upgrade package corresponding to the upgrade task information in the local cache. If the download status of the upgrade package is that all data of the upgrade package has been downloaded and verified, then it enters the waiting-to-install status; if the download status of the upgrade package is that some data has been downloaded, then the download process of the upgrade package is resumed. If the upgrade package data has not been downloaded, the upgrade package download process will be initiated.

2. The vehicle OTA upgrade task pre-download method according to claim 1, characterized in that, The download process supports resume download. The resume download is achieved by the vehicle recording the segment information of the downloaded file in real time. If an abnormal situation occurs and the download is paused, the remaining part will be resumed based on the segment information after the normal operation is restored.

3. The vehicle OTA upgrade task pre-download method according to claim 1, characterized in that, The download status of the upgrade package corresponding to the upgrade task information in the vehicle's local cache is specifically as follows: If the hash value and version number of the local upgrade package and the target upgrade package in the cloud are the same and the download is complete, it is determined that all data of the upgrade package has been downloaded and verified. If a portion of the pre-downloaded fragments of the upgrade package is stored locally, the version number and hash value of the pre-downloaded fragments are extracted and compared with the version number and hash value of the target upgrade package in the cloud. If the comparison is consistent, it is determined that part of the data has been downloaded, and the remaining part of the target upgrade package is downloaded. If the version number and hash value of the pre-downloaded fragment stored locally are inconsistent with the version number and hash value of the target upgrade package, delete the pre-downloaded fragment and re-download the complete file of the target upgrade package.

4. The vehicle OTA upgrade task pre-download method according to claim 1, characterized in that, Also includes: After the upgrade package is downloaded, store the upgrade package; If the file size of the upgrade package is greater than the preset storage capacity threshold, it indicates that the upgrade package is a large-capacity upgrade package, and a large-capacity upgrade package caching strategy is adopted. The specific cache placeholder strategy for large-capacity upgrade packages is as follows: Implement a rule of not deleting large-capacity upgrade packages that are not necessary in the local cache. When downloading the same type of upgrade package again, first compare the upgrade package to be downloaded with the large-capacity upgrade package stored locally. If they match, the large-capacity upgrade package stored locally is reused directly. If they do not match, the large-capacity upgrade package stored locally is deleted and downloaded again.

5. The vehicle OTA upgrade task pre-download method according to claim 1, characterized in that, For the pre-release state, when the vehicle meets the download trigger conditions, a silent download mechanism for the upgrade package is initiated, meaning that the entire upgrade package download process is executed in the background, and the vehicle does not display any information related to the download.

6. The vehicle OTA upgrade task pre-download method according to claim 5, characterized in that, The upgrade task information also includes a recommended download time; The silent download mechanism is triggered when the vehicle is powered on or when the vehicle is not used within the recommended download time.

7. The vehicle OTA upgrade task pre-download method according to claim 6, characterized in that, The recommended download time is generated by the cloud based on its own resource utilization.

8. The vehicle OTA upgrade task pre-download method according to claim 1, characterized in that, In response to the release status, when resuming the download process of the upgrade package and starting the download process of the upgrade package, the download progress is displayed, and the download progress includes at least one of the following: download completion percentage and estimated remaining download time.

9. A vehicle OTA upgrade task pre-download device, installed in a vehicle (1), characterized in that, It includes a memory (21) and a processor (22), the memory (21) being used to store a computer program and the processor (22) being used to invoke the computer program to execute the vehicle OTA upgrade task pre-download method as described in any one of claims 1 to 8.

10. A vehicle, characterized in that, Includes the vehicle OTA upgrade task pre-download device (2) as described in claim 9.

Images