Updating method and system for vehicle-mounted software in vehicle, vehicle and storage medium

Abstract

The embodiment of the invention provides a method and system for updating vehicle-mounted software in a vehicle, the vehicle and a storage medium, and the method comprises the steps: responding to at least one piece of to-be-updated vehicle-mounted software in the vehicle, and obtaining the storage information of an updating data packet of the vehicle-mounted software, the storage information is at least used for representing the number of a plurality of sub-data blocks obtained after the update data packet is divided and the storage positions of the sub-data blocks; based on the area where the vehicle is located and the number of the multiple sub-data blocks, multiple target cloud servers used for transmitting the multiple sub-data blocks and transmission strategies corresponding to the target cloud servers are determined; sending the transmission strategy to a corresponding target cloud server; acquiring a plurality of sub-data blocks transmitted by using a plurality of target cloud servers according to the transmission strategy; and updating the vehicle-mounted software by utilizing the acquired multiple sub-data blocks. The technical problem of low processing efficiency of the data in the vehicle is solved.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a method, system, vehicle, and storage medium for updating in-vehicle software. Background Technology

[0002] Currently, traditional over-the-air (OTA) updates for vehicles typically rely on a single download channel for data transmission. However, given the complexity of in-vehicle systems and the large volume of files, the transmission speed and efficiency of a single channel are relatively low. Especially in environments with poor network conditions or limited bandwidth, the entire OTA update process can be significantly prolonged, resulting in low data processing efficiency within the vehicle. Summary of the Invention

[0003] This application provides a method, system, vehicle, and storage medium for updating in-vehicle software, to at least solve the technical problem of low data processing efficiency in vehicles.

[0004] According to one aspect of the embodiments of this application, a method for updating in-vehicle software in a vehicle is provided. The method may include: in response to the presence of at least one in-vehicle software to be updated in the vehicle, obtaining storage information of an update data packet for the in-vehicle software, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks; based on the region where the vehicle is located and the number of multiple sub-data blocks, determining multiple target cloud servers for transmitting the multiple sub-data blocks, and a corresponding transmission strategy for each target cloud server, wherein the transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at their storage locations to the vehicle; sending the transmission strategy to the corresponding target cloud servers; obtaining the multiple sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategy; and updating the in-vehicle software using the obtained multiple sub-data blocks.

[0005] Furthermore, based on the region where the vehicle is located and the number of multiple sub-data blocks, multiple target cloud servers for transmitting the multiple sub-data blocks are determined, as well as the corresponding transmission strategies for the target cloud servers. This includes: determining multiple cloud servers deployed in the region; determining the data transmission speed of the cloud servers; and, based on the data transmission speed and the number of multiple sub-data blocks, determining multiple target cloud servers among the multiple cloud servers, as well as the corresponding transmission strategies for the target cloud servers.

[0006] Furthermore, based on the data transmission speed and the number of multiple sub-data blocks, multiple target cloud servers among multiple cloud servers are determined, as well as the corresponding transmission strategies for the target cloud servers. This includes: determining the network status of the vehicle; based on the network status, determining the number of data channels used to transmit multiple sub-data blocks, wherein the data channels are used for data communication between the vehicle and the target cloud servers; and based on the number of channels, the data transmission speed, and the number of multiple sub-data blocks, determining multiple target cloud servers from the multiple cloud servers, and determining the corresponding transmission strategies for the target cloud servers.

[0007] Furthermore, based on the number of channels, data transmission speed, and the number of multiple sub-data blocks, multiple target cloud servers are determined from multiple cloud servers, including: determining the target number of target cloud servers based on the number of channels and the number of multiple sub-data blocks; and filtering out the target number of cloud servers from multiple cloud servers based on the data transmission speed, thus obtaining multiple cloud servers.

[0008] Further, sending the transmission strategy to the corresponding target cloud server includes: generating a data transmission instruction based on the transmission strategy, wherein the data transmission instruction is used to indicate the storage location of the sub-data blocks to be transmitted on the target cloud server, and the transmission order of at least one sub-data block; sending the data transmission instruction to the corresponding target cloud server; and obtaining the sub-data blocks transmitted by the target cloud server according to the transmission strategy, including: controlling the target cloud server to distribute the sub-data blocks at the storage location to the vehicle according to the transmission order in the data transmission instruction; and obtaining the sub-data blocks transmitted by the target cloud server.

[0009] Furthermore, the vehicle software is updated using the acquired multiple sub-data blocks, including: merging the acquired multiple sub-data blocks to obtain an update data packet; and updating the vehicle software using the update data packet.

[0010] Furthermore, the acquired multiple sub-data blocks are merged to obtain an updated data packet, including: in response to the sub-data blocks being transmitted to the vehicle, the sub-data blocks are verified to obtain a verification result; in response to the verification result indicating that the integrity of the sub-data blocks is not greater than the integrity threshold, the target cloud server is called again to transmit the sub-data blocks; in response to the verification result indicating that the integrity is greater than the integrity threshold and multiple sub-data blocks have been transmitted to the vehicle, the multiple sub-data blocks are merged to obtain an updated data packet.

[0011] According to one aspect of the embodiments of this application, a system for updating in-vehicle software in a vehicle is provided. The system includes: a vehicle, configured to, in response to the presence of at least one in-vehicle software to be updated in the vehicle, acquire storage information of an update data packet for updating the in-vehicle software, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks; based on the region where the vehicle is located and the number of multiple sub-data blocks, determine multiple target cloud servers for transmitting the multiple sub-data blocks, and a transmission strategy corresponding to the target cloud servers, wherein the transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at their storage locations to the vehicle; send the transmission strategy to the corresponding target cloud servers; acquire the multiple sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategy; update the in-vehicle software using the acquired multiple sub-data blocks; and target cloud servers, configured to distribute and transmit the sub-data blocks at their storage locations to the vehicle according to the transmission strategy.

[0012] According to one aspect of the embodiments of this application, an apparatus for updating in-vehicle software in a vehicle is also provided. The apparatus may include: a first acquisition unit, configured to acquire storage information of an update data packet of the in-vehicle software in response to the presence of at least one in-vehicle software to be updated in the vehicle, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks; a determination unit, configured to determine multiple target cloud servers for transmitting the multiple sub-data blocks, and a transmission strategy corresponding to the target cloud servers, based on the region where the vehicle is located and the number of multiple sub-data blocks, wherein the transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at their storage locations to the vehicle; a transmission unit, configured to send the transmission strategy to the corresponding target cloud servers; a second acquisition unit, configured to acquire the multiple sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategy; and an update unit, configured to update the in-vehicle software using the acquired multiple sub-data blocks.

[0013] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0015] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0018] In this embodiment, when at least one piece of in-vehicle software to be updated exists in the vehicle, the storage information of the update data package of the in-vehicle software is obtained. Based on this storage information, the number of sub-data blocks after the update data package is split, and the storage location of the sub-data blocks, can be determined. Based on the region where the vehicle is located and the number of sub-data blocks, multiple target cloud servers for transmitting the multiple sub-data blocks, and the transmission strategy of the target cloud servers, can be determined. The transmission strategy can be used to request the target cloud servers to transmit the sub-data blocks at the storage locations to the vehicle. The transmission strategy can be transmitted to the target cloud servers, and the target cloud servers transmit the sub-data blocks from the storage locations to the vehicle according to the transmission strategy. The vehicle obtains the sub-data blocks transmitted by the target cloud servers and uses the obtained multiple sub-data blocks to update the in-vehicle software, thereby completing the update of the in-vehicle software. This solves the technical problem of low data processing efficiency in the vehicle and achieves the technical effect of improving the data processing efficiency in the vehicle. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a flowchart of a method for updating in-vehicle software in a vehicle according to an embodiment of this application;

[0021] Figure 2 This is a flowchart of a distributed download method based on multiple servers according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of an in-vehicle software update system according to an embodiment of this application;

[0023] Figure 4This is a schematic diagram of an in-vehicle software update device according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] According to an embodiment of this application, a method embodiment for updating in-vehicle software in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0027] This embodiment provides a method for updating in-vehicle software. Figure 1 This is a flowchart illustrating a method for updating in-vehicle software in a vehicle according to an embodiment of this application. Figure 1 As shown, the process may include the following steps:

[0028] Step S102: In response to the presence of at least one vehicle software to be updated in the vehicle, obtain the storage information of the update data packet of the vehicle software, wherein the storage information is used to characterize at least the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks.

[0029] In the technical solution provided in step S102 of this application, the aforementioned vehicle software may include firmware that directly interacts with the hardware to implement specific functions, as well as software that provides more advanced operations and applications. For example, it may be a program running on the vehicle's electronic control unit and other intelligent devices, which can be used to control and manage various electronic systems of the vehicle, including but not limited to the powertrain system, safety system, infotainment system, communication system, and driver assistance system. It should be noted that this is only an example and does not specifically limit the type of vehicle software.

[0030] Optionally, the aforementioned update data package, also known as the in-vehicle software system, can be used to update the in-vehicle software. It may contain a set of files and instructions necessary for the software update and can be pushed to the vehicle via OTA (Over-The-Air) updates to upgrade or repair the in-vehicle software. This update data package can be the latest software version or patch; for example, it may include software code, configuration files, user manuals, etc. The aforementioned storage information can be used to determine the storage location of the update data package and the number of sub-data blocks obtained after dividing the update data package. This information may include, but is not limited to, the identifier of the update data package, the size and number of each sub-data block, and its specific storage location on the cloud server. It should be noted that this is merely an example and no specific restrictions are placed on the type of storage information.

[0031] Optionally, when the in-vehicle software needs to be updated, the vehicle's in-vehicle system may determine whether there is in-vehicle software to be updated. Once it is confirmed that there is in-vehicle software to be updated, the storage information of the software update data package can be obtained from the cloud. This storage information may include the number of multiple sub-data blocks after the update data package is broken down, the size of each sub-data block, and the storage location of the sub-data block on the cloud server.

[0032] Optionally, the cloud-based system can pre-divide the update data package of at least one in-vehicle software into multiple sub-data blocks. These sub-data blocks can be stored separately in a storage system, such as a storage object, database, or data warehouse. When at least one in-vehicle software needs updating, the storage information of the update data package can be determined. This storage information may include the storage location of the data package and the number of sub-data blocks. This storage location can be used to determine the database where the sub-data blocks are placed.

[0033] Step S104: Based on the region where the vehicle is located and the number of multiple sub-data blocks, determine multiple target cloud servers for transmitting the multiple sub-data blocks, as well as the transmission strategy corresponding to the target cloud servers. The transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at the storage location to the vehicle.

[0034] In the technical solution provided in step S104 of this application, the target cloud server can be a server used to transmit sub-data blocks, or a server deployed within the target range of the vehicle. The transmission strategy can be used to determine the target cloud server for transmitting sub-data blocks and to determine the transmission information of the target cloud server, such as the transmission time, the transmitted sub-data blocks, and the location of the sub-data blocks. It should be noted that this is merely an example and does not impose specific limitations on the content included in the transmission strategy.

[0035] Optionally, after determining the storage information of the update data packet, the number of sub-data blocks and their storage locations can be determined based on this information. Further, within the target area where the vehicle is located, multiple cloud servers may be included. After determining the number of sub-data blocks and their storage locations, the target cloud server for transmitting the sub-data blocks and its corresponding transmission strategy can be determined. The target cloud server, according to this transmission strategy, can determine which storage location's sub-data block to transmit to the vehicle.

[0036] Optionally, based on the vehicle's current geographical location and the number of sub-data blocks to be downloaded, the in-vehicle system can intelligently select multiple target cloud servers and formulate a transmission strategy for each target cloud server. This transmission strategy may include deciding which sub-data blocks to download from which storage location, and dynamically adjusting the priority and connection method for downloading sub-data blocks based on current network conditions and server performance (such as bandwidth, latency, and packet loss rate). For example, if the vehicle is located in the United States, it may prioritize downloading from servers located in the United States to reduce network latency. It should be noted that the method of selecting target cloud servers here is merely illustrative and is not specifically limited. Any method that determines the target cloud server based on the vehicle's location and the number of sub-data blocks should be within the scope of protection of this application.

[0037] Optionally, based on factors such as the vehicle's geographical location, network conditions, and server load, multiple cloud servers can be selected as data download sources to distribute download pressure and improve download speed. For example, servers with close geographical proximity can be prioritized to reduce network latency; servers with high network bandwidth, low packet loss rate, and low latency can be evaluated and selected; and servers with excessive load can be avoided to ensure download efficiency. Furthermore, based on the number of sub-data blocks and the target cloud server, the corresponding transmission strategy for that target cloud server can be determined. According to this transmission strategy, the target cloud server can be requested to transmit the sub-data blocks from their storage location to the vehicle.

[0038] For example, suppose a vehicle needs to download an update data package from the cloud, which can be pre-divided into 20 data blocks. The vehicle system can open 10 parallel download channels. The first 5 channels use at least one target cloud server in Region 1 to download data blocks 1 to 5, and the last 5 channels use at least one target cloud server in Region 2 to download data blocks 6 to 20. The vehicle system can also continuously monitor the bandwidth usage and download speed of each channel. If it detects insufficient bandwidth in a certain channel, it can automatically adjust the download task or assign the task of that channel to other channels with more sufficient bandwidth. If the download of a data block fails, the vehicle system can automatically initiate a retry, selecting a server with stable bandwidth to re-download the data block. After multiple sub-data blocks have been downloaded, the vehicle system can also use a verification algorithm to verify the integrity of each data block to ensure that all data blocks have not been tampered with and can be securely merged into an application update.

[0039] Optionally, through the above transmission strategy, the vehicle system can complete OTA software updates efficiently and stably. Even in the case of poor network conditions or high server load, it can ensure reliable data transmission through dynamic adjustment and retry mechanisms, thereby significantly improving the user update experience.

[0040] Step S106: Send the transmission strategy to the corresponding target cloud server.

[0041] In the technical solution provided in step S106 of this application, after determining the transmission strategy, the transmission strategy can be sent to the corresponding target cloud server to request the target cloud server to transmit the sub-data block at the storage location to the vehicle according to the transmission strategy.

[0042] Optionally, after determining the target cloud server and its respective transmission strategy, the vehicle system can send the transmission strategy to the corresponding target cloud server. This step is equivalent to sending a request to the target cloud server, asking how and when to start transmitting data blocks. Sending the transmission strategy ensures that the server can start data transmission according to the optimal path and time schedule.

[0043] Step S108: Obtain multiple sub-data blocks transmitted using multiple target cloud servers according to a transmission strategy.

[0044] In the technical solution provided in step S108 of this application, after the transmission strategy is sent to the corresponding target cloud server, the target cloud server can determine the sub-data blocks to be transmitted, the time for transmitting the sub-data blocks, and other information according to the transmission strategy, and transmit the sub-data blocks according to the transmission strategy. The vehicle can obtain multiple sub-data blocks transmitted by the target cloud server.

[0045] Optionally, the vehicle-mounted system, according to the transmission strategy determined in S104, uses multiple target cloud servers to download multiple sub-data blocks in parallel. The download process can utilize multiple network channels between the vehicle-mounted system and the cloud servers, with each channel used to download one sub-data block. If a channel or server fails, the system will automatically switch to another channel or server to ensure the continuity and success of the download process.

[0046] Step S110: Update the vehicle software using the acquired multiple sub-data blocks.

[0047] In the technical solution provided by step S110 of this application, after obtaining multiple sub-data blocks, the vehicle software can be updated using the multiple sub-data blocks.

[0048] Optionally, after all sub-data blocks have been successfully downloaded to the vehicle's local storage, the vehicle system can merge the multiple data blocks to restore a complete update data package. The vehicle system can then begin the update process, applying the new software version from the update data package to replace the existing vehicle software. The vehicle software update process may include steps such as verifying the integrity of the data package, decompressing the software package, updating configuration files, and restarting relevant services to ensure a smooth upgrade of the vehicle software.

[0049] Through steps S102 to S110, when at least one piece of in-vehicle software to be updated exists in the vehicle, the storage information of the update data package of the in-vehicle software is obtained. Based on this storage information, the number of sub-data blocks after the update data package is split, and the storage location of the sub-data blocks, can be determined. Based on the region where the vehicle is located and the number of sub-data blocks, multiple target cloud servers for transmitting multiple sub-data blocks, and the transmission strategy of the target cloud servers, can be determined. This transmission strategy can be used to request the target cloud servers to transmit the sub-data blocks from their storage locations to the vehicle. The transmission strategy can be transmitted to the target cloud servers, and the target cloud servers, according to the transmission strategy, transmit the sub-data blocks from their storage locations to the vehicle. The vehicle obtains the sub-data blocks transmitted by the target cloud servers and uses the obtained multiple sub-data blocks to update the in-vehicle software, thereby completing the update of the in-vehicle software. This solves the technical problem of low data processing efficiency in vehicles, and thus achieves the technical effect of improving the data processing efficiency in vehicles.

[0050] The above-mentioned method of this application will be further described below.

[0051] In this embodiment, after determining the region where the vehicle is located and the number of sub-data blocks, the target cloud server for transmitting the sub-data blocks, as well as the transmission strategy of the target cloud server, can be determined based on the region where the vehicle is located and the number of multiple sub-data blocks. This process will be further described below.

[0052] As an optional implementation, step S104 involves determining multiple target cloud servers for transmitting the multiple sub-data blocks, and the corresponding transmission strategies for the target cloud servers, based on the area where the vehicle is located and the number of multiple sub-data blocks. This includes: determining multiple cloud servers deployed in the area; determining the data transmission speed of the cloud servers; and determining multiple target cloud servers among the multiple cloud servers, and the corresponding transmission strategies for the target cloud servers, based on the data transmission speed and the number of multiple sub-data blocks.

[0053] In this embodiment, the aforementioned data transmission speed can be used to characterize the actual network performance and data traffic volume of the cloud server, and can be correlated with the network's physical bandwidth, the cloud server's processing power, network latency, etc. The data transmission speed of the cloud server can be determined using network speed testing tools, uploading and downloading small amounts of test data, performance monitoring tools, etc. It should be noted that this is merely an example, and no specific limitations are imposed on the methods used to determine the data transmission speed.

[0054] Optionally, by monitoring and testing the data transmission speed of the cloud servers, the most suitable server can be intelligently selected, and an effective transmission strategy can be formulated to ensure that the updates of the vehicle software are both fast and stable, thereby providing users with a seamless update experience. Therefore, this embodiment identifies multiple cloud servers in the area where the vehicle is located and determines the data transmission speed of each cloud server. Based on this data transmission speed, a suitable cloud server for data transmission can be determined. Furthermore, based on the number of data blocks, the number of cloud servers to be selected can be determined. Thus, based on the data transmission speed and the number of data blocks, multiple target cloud servers can be identified. Moreover, based on the data transmission speed and the number of data blocks of each target cloud server, the data transmission time and the number of sub-data blocks to be transmitted for each target cloud server can be determined, thereby obtaining the transmission strategy corresponding to the target cloud server.

[0055] For example, by determining the area where the vehicle is located, and based on multiple servers within that area, the target server for data transmission can be identified. The default cloud server for that area can be prioritized. If the service speed and stability of the cloud server in that area are low, a cloud server in another area can be selected for data transmission. It should be noted that the method for determining the target cloud server is not specifically limited here; any method based on the cloud server's data transmission speed and the number of sub-data blocks should be within the scope of protection of this application.

[0056] Optionally, to reduce data transmission latency, considering that data transmission from a geographically nearby server to the vehicle is generally faster than remote transmission, multiple cloud servers deployed in the vehicle's current location area can be identified. After determining the cloud servers, their data transmission speeds can be determined. This can be done by sending test packets and measuring round-trip time, throughput, and packet loss rate to select the optimal cloud server for data transmission. Finally, based on the server's transmission speed and the number of sub-data blocks, intelligent decisions can be made regarding which servers should be the target cloud servers, and how to effectively utilize these servers for data transmission can be determined. Methods for determining target cloud servers can involve strategies such as load balancing, parallel downloading, and dynamic scheduling to ensure fast, stable, and efficient data transmission. Furthermore, a transmission strategy can be specified for the target cloud server. For example, if the vehicle's onboard system can handle multiple download channels simultaneously, it can be determined that sub-data blocks will be downloaded in parallel from multiple target cloud servers. During the download process, if network fluctuations occur on any target cloud server, causing a decrease in transmission speed, some download tasks can be automatically switched to other cloud servers to maintain stable download speeds. Simultaneously, to ensure the reliability of data transmission, a retry mechanism can be set for each sub-data block; that is, if a download fails on one server, the same sub-data block will be automatically retried from another server. It should be noted that the above transmission strategy can be determined in various ways, such as by pre-defined allocation requirements or data transmission requirements determining multiple transmission strategies for multiple target cloud servers. No specific restrictions are placed on the method of determining the transmission strategy for each target cloud server here.

[0057] Optionally, through the above steps, the in-vehicle system can intelligently select the optimal data transmission path and formulate effective transmission strategies based on the vehicle's geographical location and the real-time transmission performance of the cloud server. This includes not only identifying the target cloud server but also dynamically adjusting transmission tasks to cope with network fluctuations, ensuring fast, stable, and secure OTA updates, thereby improving data processing efficiency.

[0058] In this embodiment, after determining the data transmission speed and the number of sub-data blocks, the following steps can be used to determine the target cloud server and its corresponding transmission strategy among multiple cloud servers, based on the data transmission speed and the number of sub-data blocks. The method is further described below.

[0059] As an optional implementation, based on the data transmission speed and the number of multiple sub-data blocks, multiple target cloud servers are determined from multiple cloud servers, and the corresponding transmission strategies for the target cloud servers are determined. This includes: determining the network status of the vehicle; determining the number of data channels used to transmit multiple sub-data blocks based on the network status, wherein the data channels are used for data communication between the vehicle and the target cloud servers; and determining multiple target cloud servers from multiple cloud servers based on the number of channels, the data transmission speed, and the number of multiple sub-data blocks, and determining the corresponding transmission strategies for the target cloud servers.

[0060] In this embodiment, the aforementioned network status can be used to characterize the vehicle's ability and conditions to receive and send data at a given moment. It can be used to determine the data transmission quality and efficiency during OTA updates and is associated with indicators such as the vehicle's connection type, signal strength, and network bandwidth. It may include data such as network connection type, network strength, and network packet loss rate. It should be noted that this is merely an illustrative example, and no specific limitations are placed on the content included in the network status.

[0061] For example, suppose during an OTA update, the vehicle is currently parked in a residential area, with both Wireless Fidelity (Wi-Fi) and Fourth Generation (4G) network options available. The Wi-Fi signal strength is -45 dBm, bandwidth is 100 megabits per second (Mbps), latency is 10 milliseconds, and packet loss rate is 1%. The 4G network signal strength is -80 dBm, bandwidth is 30 Mbps, latency is 50 milliseconds, and packet loss rate is 3%. In this situation, the vehicle system can prioritize Wi-Fi for the OTA update because Wi-Fi offers a stronger signal, higher bandwidth, lower latency, and lower packet loss rate. Therefore, the vehicle's network status at this time can be determined as: using Wi-Fi for signal transmission, network bandwidth of 100 Mbps, and network latency of 10 milliseconds.

[0062] Optionally, the aforementioned data channel can refer to a virtual path established between the vehicle and the target cloud server, which can be used to transmit data (i.e., sub-data blocks). In a parallel download strategy, the number and management of data channels directly affect the efficiency and speed of sub-data block downloads.

[0063] For example, taking the aforementioned OTA update as an example, the vehicle selected a Wi-Fi network for the update, with a total bandwidth of 100Mbps. The vehicle system decided to open 10 data channels, meaning each channel could use a maximum of 10Mbps of bandwidth for data transmission. If the update data packet was divided into 30 sub-data blocks, the vehicle system could download the sub-data blocks in parallel through the aforementioned data channels, thereby reducing the overall download time for multiple sub-data blocks. For instance, the first 5 data channels could be configured to connect to 5 different cloud servers, with each cloud server used to transmit 6 sub-data blocks. This way, even if one channel or server experiences a problem, the other channels can still remain operational, ensuring that the entire download process is not significantly affected. Furthermore, the vehicle system can dynamically adjust the bandwidth allocation of each channel based on real-time network conditions. If it detects low transmission efficiency on certain channels, it can reallocate some sub-data blocks from those channels to other more efficient channels.

[0064] Optionally, the network status of the vehicle can be determined. Based on the network status, the number of data channels used for transmitting sub-data blocks can be determined, and these data channels can be used for transmitting sub-data blocks. Further, based on the number of channels, the data transmission speed of the cloud server, and the number of multiple sub-data blocks, the target cloud server for transmitting multiple sub-data blocks can be determined, and based on the data transmission speed and the number of sub-data blocks, the corresponding transmission strategy for the target cloud server can be determined.

[0065] Optionally, network status is a crucial prerequisite for efficient OTA updates of the vehicle system, while proper configuration and management of data channels are key to accelerating data transmission and improving download efficiency. By intelligently detecting network status and flexibly configuring data channels, vehicles can ensure fast, stable, and secure software updates even under complex network conditions, providing drivers with a superior update experience.

[0066] Optionally, during OTA updates, the vehicle system can utilize a parallel download mechanism to simultaneously download multiple data blocks from multiple target cloud servers. Assuming the vehicle is connected to a 5G network, five parallel data channels can be activated to download sub-data blocks. Furthermore, the allocation of download tasks can be dynamically adjusted by monitoring the bandwidth utilization of each channel in real time. If the bandwidth utilization of a certain data channel is too high, the tasks on that channel can be automatically reduced, and the data transmission tasks can be allocated to data channels with lower but more stable bandwidth, ensuring balanced network traffic and efficient execution of download tasks.

[0067] Optionally, the in-vehicle system can detect the vehicle's current network status to determine the network connection type (e.g., Wi-Fi, 4G / 5G, cellular data), signal strength, bandwidth availability, latency, and packet loss rate. Based on the network status, it determines the number of data channels used to transmit multiple sub-data blocks. The in-vehicle system can intelligently select the target cloud server and customize the transmission strategy based on the number of available data channels, the data transmission speed of each cloud server, and the number of sub-data blocks to be downloaded.

[0068] For example, the vehicle-mounted system determines the number of data channels that can be opened simultaneously based on the acquired network status information. The number of channels should be set with full consideration of the current network bandwidth and processing capacity to improve overall data transmission speed through parallel downloading. For instance, based on a good 5G network condition, the vehicle-mounted system can decide to open 10 data channels simultaneously for parallel downloading, thus fully utilizing the 100Mbps bandwidth to accelerate download speed. Assume the update data package that the vehicle-mounted system needs to download is divided into 30 sub-data blocks, and there are four available cloud servers in the vehicle's area: Server_1, Server_2, Server_3, and Server_4, with data transmission speeds of 25Mbps, 30Mbps, 20Mbps, and 25Mbps respectively. Since the vehicle-mounted system previously decided to use 10 data channels for simultaneous downloading, Server_2, due to its highest data transmission speed of 30Mbps, is prioritized as the primary server to handle more download tasks. The remaining servers are ranked according to their transmission speed, with Server_1 and Server_4 both being second choices, and Server_3 being ranked last due to its lowest speed. The vehicle system can determine that Server_2 will be responsible for downloading 10 data channels (e.g., downloading the first 10 sub-data blocks). Server_1 and Server_4 will each be responsible for 4 data channels (downloading the middle 8 sub-data blocks respectively), while Server_3, due to its slower speed, will only have 2 data channels (used to download the remaining 4 sub-data blocks).

[0069] Furthermore, if the download process reveals that the transmission speed of some servers is lower than expected, or if the vehicle network status changes (such as a decrease in bandwidth), the onboard system can recalculate the channel allocation and dynamically schedule the download tasks of data blocks to maintain optimal download speed. For example, if the data transmission speed of Server_2 suddenly drops to 15Mbps during the download process, the onboard system will detect this change and recalculate the data channel allocation. The onboard system can then transfer some data download tasks from Server_2 to Server_1 and Server_4 to maintain the overall download speed. Simultaneously, the onboard system will continuously monitor the performance of all cloud servers; if the transmission speed of Server_3 improves, its download tasks may also be adjusted to maximize the overall download speed.

[0070] In this embodiment, through the above steps, the in-vehicle system can intelligently select the target cloud server and customize an efficient transmission strategy based on the vehicle's current network status, the cloud server's data transmission speed, and the segmentation of update data packets. This method not only improves the download speed and efficiency of OTA updates but also flexibly responds to changes in the network environment, ensuring the robustness of the update process and optimizing the user experience.

[0071] In this embodiment, after determining the number of channels and the number of multiple sub-data blocks, a target number of target cloud servers can be determined based on the number of channels and the number of multiple sub-data blocks. Based on this target data, a target cloud server for data transmission is selected from multiple cloud servers. The method is further described below.

[0072] As an optional implementation, multiple target cloud servers are determined from multiple cloud servers based on the number of channels, data transmission speed, and the number of multiple sub-data blocks. This includes: determining the target number of target cloud servers based on the number of channels and the number of multiple sub-data blocks; and filtering out the target number of cloud servers from multiple cloud servers based on the data transmission speed to obtain multiple target cloud servers.

[0073] In this embodiment, the vehicle-mounted system can calculate how many cloud servers need to be downloaded simultaneously to achieve the required efficiency, based on the number of currently available data channels and the total number of sub-data blocks to be downloaded. Determining the target number should avoid server overload and ensure reasonable allocation of network resources. After determining the target number of servers that need to work simultaneously, the fastest and best-performing server can be selected from the server list based on the data transmission speed of each cloud server, and designated as the target cloud server. Download tasks can be assigned to these multiple target servers, thereby achieving rapid download of sub-data blocks through the parallel data channels of multiple target cloud controllers.

[0074] For example, the vehicle system can determine the number of target cloud servers. Since it can handle 20 data channels simultaneously and there are 40 sub-data blocks, ideally each server needs to be able to handle at least 2 channels to ensure all sub-data blocks can be downloaded quickly in parallel channels. Therefore, the vehicle system initially decides to select a maximum of 10 servers from 5 candidate servers (each server handling at least 2 channels), but this depends on the actual data transmission speed of the servers. Based on the data transmission speed of the 5 servers, the vehicle system will first select the fastest server. If each server needs to handle at least 2 channels, then target cloud server one (Server_A) can handle 2 channels (downloading 4 sub-data blocks); target cloud server two (Server_B) can handle 2 channels (downloading 4 sub-data blocks); target cloud server three (Server_C) can handle 2 channels (downloading 4 sub-data blocks); and target cloud server four (Server_D) can handle 2 channels (downloading 4 sub-data blocks). At this point, 8 channels remain unallocated. Since the data transfer speed of the cloud server (Server_E) is relatively low, only 10Mbps, it can be used as the target cloud server to handle the remaining sub-data blocks to be transferred. However, considering efficiency, other faster cloud servers could be sought, or only the first four servers could be used, with each server handling more channels. For example, Server_A and Server_B could each handle 5 channels, and Server_C and Server_D could each handle 4 channels. Through the above selection, Server_A, Server_B, Server_C, and Server_D can be identified as the target cloud servers. These multiple target cloud servers will share the task of downloading 40 sub-data blocks in parallel through 20 data channels. Server_A and Server_B, being the fastest, will handle more download tasks, while Server_C and Server_D will handle fewer tasks.

[0075] Optionally, during the download of sub-data blocks, the performance of each data channel and the target cloud server can be continuously monitored. If the data transfer speed of a target cloud server suddenly drops, some download tasks can be transferred to other cloud servers to maintain optimal overall download speed. This dynamic adjustment mechanism ensures that OTA updates remain efficient and stable even when network conditions change.

[0076] Through the steps described above, the in-vehicle system can intelligently select the optimal target cloud server for parallel data download based on current network conditions and the number of sub-data blocks to be downloaded. This significantly reduces the total OTA update time and improves the stability and efficiency of the update process. This method is not only applicable to OTA updates of in-vehicle software but can also be extended to any scenario requiring efficient parallel data transmission, such as large-scale data distribution and remote file synchronization, to enhance user experience and system performance.

[0077] In this embodiment, after determining the transmission strategy, the transmission strategy can be converted to obtain a data transmission instruction. This data transmission instruction can then be transmitted to the target cloud server to instruct the target cloud server to transmit the sub-data blocks according to the transmission strategy. The method will be further described below.

[0078] As an optional implementation, sending the transmission strategy to the corresponding target cloud server includes: generating a data transmission instruction based on the transmission strategy, wherein the data transmission instruction is used to indicate the storage location of the sub-data blocks to be transmitted on the target cloud server, and the transmission order of at least one sub-data block; sending the data transmission instruction to the corresponding target cloud server; and obtaining the sub-data blocks transmitted by the target cloud server according to the transmission strategy, including: controlling the target cloud server to distribute the sub-data blocks at the storage location to the vehicle according to the transmission order in the data transmission instruction; and obtaining the sub-data blocks transmitted by the target cloud server.

[0079] In this embodiment, a data transmission instruction can be generated based on a transmission strategy. This instruction can be used to instruct the target cloud server to transmit sub-data blocks at a storage location according to the transmission strategy. The data transmission instruction may include the number of sub-data blocks to be transmitted by the target cloud server and the storage location of the sub-data blocks, and can be used to instruct the target cloud server to transmit the sub-data blocks at the storage location to the vehicle.

[0080] Optionally, the vehicle-mounted system can create detailed data transmission instructions based on a pre-determined transmission strategy. These instructions can include information such as the storage location and transmission order of sub-data blocks, guiding the target cloud server to execute precise and optimized data transmission. The vehicle can send the generated data transmission instructions to the selected target cloud server via the network. Upon receiving the instructions, the target cloud server can begin preparing for data transmission based on their content. The vehicle-mounted system can remotely control the target cloud server to begin data transmission via the sent instructions. The target cloud server, according to the storage location and transmission order of the sub-data blocks specified in the instructions, distributes the sub-data blocks to the vehicle's memory through pre-defined parallel data channels. The vehicle-mounted system can receive and integrate the sub-data blocks transmitted from each target cloud server.

[0081] For example, by generating and sending data transmission instructions to the target cloud server, the in-vehicle system can precisely control the distributed data transmission process, ensuring that sub-data blocks are transmitted to the vehicle quickly and stably in the optimal order and storage location. This intelligent control mechanism not only improves the efficiency of OTA updates but also ensures the reliability of the update process, thereby achieving the technical effect of improving data transmission efficiency and solving the technical problem of low data transmission efficiency.

[0082] For example, suppose a vehicle needs to perform an OTA update package of approximately 1 gigabyte (GB). This 1GB update package can be divided into 10 data blocks of 100MB each. Then, multiple cloud servers (e.g., servers A, B, and C) can be selected for distributed downloading. Each server is used to download 5 data blocks. The vehicle's onboard system intelligently selects the most suitable server for downloading based on network bandwidth conditions and dynamically adjusts the download task for each server. When the download progress on a certain server is slow, the system automatically switches to other, better servers to ensure download stability and speed.

[0083] In this embodiment, after the target cloud server transmits multiple sub-data blocks to the vehicle, the multiple sub-data blocks can be merged to obtain an update data packet. This update data packet can then be used to update the vehicle's onboard software. The method is further described below.

[0084] As an optional implementation, step S110, which involves updating the vehicle software using the acquired multiple sub-data blocks, includes: merging the acquired multiple sub-data blocks to obtain an update data packet; and updating the vehicle software using the update data packet.

[0085] In this embodiment, multiple sub-data blocks can be merged to obtain an update data packet, which can then be used to update the vehicle software.

[0086] Optionally, after the vehicle system completes the download of the sub-data blocks, the acquired, scattered sub-data blocks can be merged and reassembled into the original complete update data package. Once the multiple sub-data blocks are correctly merged to form the update data package, the vehicle system can use this data package to update the vehicle software to be updated.

[0087] For example, suppose a car needs to receive a 2GB software update package. To speed up the download and improve network resource utilization, the system in the cloud can divide the update package into several sub-blocks for distributed download. For instance, the update package could be divided into 100 sub-blocks, each approximately 20MB in size. These sub-blocks are downloaded in parallel to the vehicle's storage from different target cloud servers (such as Server_1, Server_2, and Server_3) via multiple data channels. After downloading multiple sub-blocks, the in-vehicle system can perform integrity checks on them to ensure the correctness of each sub-block. Once all sub-blocks have been successfully downloaded and passed the integrity check, they can be merged into a single complete update package in their original order. The merged update package can then be imported into the in-vehicle software's update module, which decompresses the package and applies the update code to the existing software version. This may include replacing old files, updating database entries, and modifying configuration files to accommodate the new version's feature improvements and bug fixes. Once the update is complete, a notification message can be sent to inform you that the in-vehicle software update is finished, and a system restart may be required to activate the update.

[0088] In this embodiment, by employing distributed downloading and merging downloaded sub-data blocks, the OTA update mechanism of the in-vehicle system can effectively manage and update complex software packages, maintaining efficiency and reliability even with large file volumes. This mechanism not only optimizes the use of network resources but also improves the efficiency of in-vehicle software maintenance and upgrades, which is crucial for enhancing vehicle performance and safety.

[0089] In this embodiment, after transmitting multiple sub-data blocks to the vehicle, the integrity of the sub-data blocks can be verified. If the verification result meets the preset requirements, it can be determined that the sub-data blocks have been transmitted completely to the vehicle. If the sub-data blocks have not been transmitted completely to the vehicle, the corresponding sub-data blocks can be retransmitted so that the vehicle receives the complete sub-data blocks. The method is further described below.

[0090] As an optional implementation, the acquired multiple sub-data blocks are merged to obtain an updated data packet, including: in response to the sub-data blocks being transmitted to the vehicle, the sub-data blocks are verified to obtain a verification result; in response to the verification result indicating that the integrity of the sub-data blocks is not greater than the integrity threshold, the target cloud server is called again to transmit the sub-data blocks; in response to the verification result indicating that the integrity is greater than the integrity threshold and multiple sub-data blocks have been transmitted to the vehicle, the multiple sub-data blocks are merged to obtain an updated data packet.

[0091] In this embodiment, when a sub-data block is transmitted to the vehicle, its integrity can be verified to obtain a verification result. This verification result can be used to characterize the integrity of the sub-data block. If the integrity level of the sub-data block is greater than the integrity level threshold, it can be determined that the sub-data block is complete and meets the requirements. If the integrity level of the sub-data block is not greater than the integrity level threshold, it can be determined that the sub-data block is incomplete, and the target cloud server can be called again to transmit the sub-data block. This process continues until the verification results of all sub-data blocks indicate that their integrity level is greater than the integrity level threshold. Then, multiple sub-data blocks can be merged to obtain an updated data packet. The aforementioned integrity level threshold can be a pre-set value used to verify the integrity of the sub-data blocks.

[0092] Optionally, during the OTA update process, downloaded sub-data blocks can be stored in a temporary cache area within the vehicle's onboard storage. Each sub-data block is downloaded independently in the background. Once downloaded, the sub-data blocks can be automatically stored in the vehicle's hard drive and merged. After all data blocks have been downloaded, the update package can be applied uniformly, and update progress can be reported, ensuring a seamless update process.

[0093] Optionally, ensuring the integrity of downloaded sub-data blocks is a crucial step during the OTA update process of in-vehicle software. To achieve this, the in-vehicle system in this embodiment can perform integrity verification on each sub-data block after receiving it. Only when the integrity of the data blocks meets a preset threshold will multiple data blocks be merged to obtain a complete update package.

[0094] Optionally, after the sub-data block is transmitted from the cloud server to the vehicle via the network, the in-vehicle system can perform an integrity check on the sub-data block. The check can employ hash algorithms (such as SHA-256), cyclic redundancy check (CRC), or other effective data verification mechanisms to ensure that the sub-data block has not been corrupted or damaged during transmission, thus obtaining a check result. This check result can be used to characterize whether the sub-data block is complete and the degree of its integrity. It should be noted that the check method described here is merely illustrative and does not impose any specific limitations.

[0095] Optionally, if the verification result, used to characterize the integrity of a sub-data block, does not meet a preset threshold—that is, the data block is considered damaged or incomplete—the in-vehicle system can automatically trigger a process to re-download the sub-data block. This can be achieved by sending a request to the target cloud server, instructing it to retransmit the problematic sub-data block. This process may also include a network path switching procedure to select a more stable connection to improve the download success rate.

[0096] Optionally, after the received multiple sub-data blocks have been verified, if the integrity level of all the sub-data blocks is higher than a preset threshold, it indicates that the multiple sub-data blocks have been completely transmitted to the vehicle. At this time, the vehicle system can start a merging process to merge the acquired multiple sub-data blocks into a complete update data packet in a pre-planned order.

[0097] By following the steps described above, it can be ensured that each sub-data block acquired by the vehicle is complete and reliable, thereby reducing the update failure rate caused by transmission errors. Furthermore, by repeatedly requesting the re-download of incomplete data blocks, the system can also cope with network fluctuations and data transmission anomalies, enhancing the stability and robustness of the OTA update process, ultimately enabling the vehicle software to complete updates efficiently and securely.

[0098] In this embodiment, in response to an anomaly occurring during the transmission of sub-data blocks from the target cloud server to the vehicle, the target cloud server is replaced by a backup cloud server, wherein the bandwidth of the backup cloud server is higher than that of the target cloud server; the backup cloud server is invoked to transmit the sub-data blocks to the vehicle.

[0099] Optionally, assuming the vehicle system is downloading a sub-data block from an update package, and the download fails due to network fluctuations, a retry mechanism can automatically initiate a retry process for the download task. To ensure a successful download, the download path can be switched, reconnecting to a different cloud server with higher bandwidth, while simultaneously performing data block integrity checks to ensure the downloaded data block is error-free. If the download still fails, other network paths can be tried until the download succeeds.

[0100] The method described in this embodiment will be further illustrated with examples below.

[0101] Currently, traditional OTA updates typically rely on a single download channel for data transmission. This is particularly problematic when in-vehicle systems are complex and contain large amounts of data, where the speed and efficiency of a single channel often become a bottleneck. Especially in poor network conditions or with limited bandwidth, the entire OTA update process can be significantly prolonged, impacting the user experience.

[0102] In related technologies, OTA updates for in-vehicle software suffer from problems such as large upgrade package file size, unstable transmission speed, and long OTA update process. To address these issues, this embodiment proposes an OTA update optimization method based on distributed downloading and parallel processing. This method significantly improves the efficiency and stability of OTA updates by decomposing OTA update tasks, employing a distributed download architecture, multi-channel parallel processing, and dynamic bandwidth adjustment. It not only optimizes network bandwidth utilization and reduces download time but also effectively responds to changes in the network environment, enhancing the robustness of the OTA update process.

[0103] Optionally, this method utilizes distributed downloading and parallel processing, leveraging multiple servers and network channels to simultaneously download multiple data blocks, significantly improving the download speed and efficiency of OTA updates and reducing the time required for updates. Simultaneously, the distributed downloading and load balancing mechanism effectively reduces bandwidth congestion, optimizes network bandwidth utilization, and ensures reasonable bandwidth allocation across channels and servers. Intelligent retry mechanisms and download path switching effectively address network fluctuations and interruptions, ensuring the stability of the OTA update process. Furthermore, this method, through real-time feedback and user interaction functions, allows users to monitor update progress and make corresponding adjustments at any time, enhancing the user experience.

[0104] Figure 2 This is a flowchart of a distributed download method based on multiple servers according to an embodiment of this application, such as... Figure 2 As shown, the method may include the following steps:

[0105] Step S202: Divide the update data packet into multiple sub-data blocks.

[0106] In this embodiment, the update data packet can be divided using a cloud-based system to obtain multiple sub-data blocks.

[0107] Step S204: Select multiple target cloud servers, and each target cloud server can be allocated a portion of the sub-data blocks.

[0108] In this embodiment, multiple target cloud servers can be selected for data transmission. After determining multiple target cloud servers, a corresponding sub-data block can be allocated to each target cloud server to complete the transmission of the sub-data block using the target cloud server.

[0109] Step S206: Based on the real-time network bandwidth, select a suitable path from the target cloud server to start downloading.

[0110] In this embodiment, after determining the target cloud server, the optimal path can be selected from the target cloud server to start downloading sub-data blocks based on real-time network bandwidth. Data blocks allocated to each target cloud server can be downloaded in parallel.

[0111] Optionally, the transmission strategy may include a data transmission path corresponding to the target cloud server, which may be a data channel used to transmit the sub-data block.

[0112] Step S208: Monitor the download speed of each target cloud server.

[0113] In this embodiment, during the transmission of sub-data blocks on the target cloud server, the download speed of each target cloud server and the task completion status of the target cloud server can be continuously monitored.

[0114] Step S210: Determine if the target cloud server has a problem with slow data transmission.

[0115] In this embodiment, during the transmission of sub-data blocks by the target cloud server, it can be determined whether there is a problem with slow data transmission on the target cloud server. If there is, step S212 can be executed; if not, step S214 can be executed.

[0116] Step S212: Pause the slow data transfer task to the target cloud server.

[0117] In this embodiment, if a slow download problem is detected on the target cloud server, the slow-progressing task server can be paused, and the incomplete sub-data blocks can be reassigned to other suitable target cloud servers.

[0118] Step S214: Confirm that all sub-data blocks have been downloaded.

[0119] In this embodiment, it is determined whether all multiple sub-data blocks have been downloaded. If all multiple sub-data blocks have been downloaded, the integrity of the sub-data blocks can be verified.

[0120] Optionally, suppose the vehicle needs to perform an OTA update package of approximately 1GB. The system first divides the 1GB update package into 10 data blocks of 100MB each. Then, the system selects multiple cloud servers (e.g., servers A, B, and C) for distributed downloading. Each server is used to download 5 data blocks. The vehicle's onboard system intelligently selects the most suitable server for downloading based on network bandwidth conditions and dynamically adjusts the download task for each server. When the download progress on a certain server is slow, the system automatically switches to other better servers to ensure download stability and speed.

[0121] Step S2016: Write the complete update data package into the vehicle system and perform the installation.

[0122] In this embodiment, after obtaining multiple sub-data blocks, the multiple sub-data blocks can be merged to obtain an update data package. The complete update data package can be written into the vehicle system and installed to complete the update of the vehicle software.

[0123] Optionally, during OTA updates, the vehicle system downloads multiple sub-data blocks simultaneously using a parallel download mechanism. Assuming the vehicle is connected to a 5G network, the vehicle system decides to open five parallel channels for downloading. It can dynamically adjust the allocation of download tasks by monitoring the bandwidth usage of each data channel in real time. If the bandwidth utilization of a certain data channel is too high, the vehicle system can automatically reduce the number of tasks on that channel and allocate them to channels with lower but more stable bandwidth, ensuring balanced network traffic and efficient execution of download tasks.

[0124] Optionally, assuming the vehicle system is downloading a sub-data block from an update data package, and the download fails due to network fluctuations, a retry mechanism can automatically initiate a retry process for the download task. To ensure a successful download, the vehicle system can choose to switch download paths and reconnect to a target cloud server with higher bandwidth, while simultaneously performing integrity checks on the sub-data block to ensure it is error-free. If the download still fails, the vehicle system can continue trying other network paths until the download succeeds.

[0125] Optionally, during the OTA update process, downloaded data blocks can be stored in a temporary cache area within the vehicle's storage space. Each data block is downloaded independently in the background. After downloading, the vehicle system can automatically store the acquired sub-data blocks to the vehicle's hard drive and merge them. Once multiple sub-data blocks have been downloaded, the vehicle system can apply the update data package uniformly and provide update progress feedback, ensuring a seamless update process for the system.

[0126] This embodiment implements a method for updating in-vehicle software. When updating at least one piece of in-vehicle software, the method obtains the storage information of the update data package. Based on this storage information, the number of sub-data blocks after the update data package is split, and the storage location of the sub-data blocks, can be determined. Based on the region where the vehicle is located and the number of sub-data blocks, multiple target cloud servers for transmitting the multiple sub-data blocks, and the transmission strategy of the target cloud servers, can be determined. This transmission strategy can be used to request the target cloud servers to transmit the sub-data blocks from their storage locations to the vehicle. The transmission strategy can be transmitted to the target cloud servers, and the target cloud servers, according to the transmission strategy, transmit the sub-data blocks from their storage locations to the vehicle. The vehicle obtains the sub-data blocks transmitted by the target cloud servers and uses the obtained multiple sub-data blocks to update the in-vehicle software, thereby completing the update and solving the technical problem of low data processing efficiency in vehicles, thus achieving the technical effect of improving the data processing efficiency in vehicles.

[0127] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0128] According to an embodiment of this application, an embodiment of a vehicle software update system is also provided. It should be noted that this system can be used to execute the above-described vehicle software update method.

[0129] Figure 3 This is a schematic diagram of an in-vehicle software update system according to an embodiment of this application. Figure 3 As shown, the vehicle software update system may include: vehicle 32 and target cloud server 34.

[0130] Vehicle 32 is configured to, in response to the presence of at least one in-vehicle software to be updated in the vehicle, acquire storage information of an update data packet for updating the in-vehicle software, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after the update data packet is divided, and the storage location of the sub-data blocks; based on the region where the vehicle is located and the number of multiple sub-data blocks, determine multiple target cloud servers for transmitting the multiple sub-data blocks, and the corresponding transmission strategy for the target cloud servers, wherein the transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at the storage location to the vehicle; send the transmission strategy to the corresponding target cloud servers; acquire the multiple sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategy; and update the in-vehicle software using the acquired multiple sub-data blocks.

[0131] Alternatively, the aforementioned vehicle can be a vehicle-mounted unit.

[0132] The target cloud server 34 is used to distribute and transmit sub-data blocks from the storage location to the vehicle according to the transmission strategy.

[0133] Optionally, the system may also include a cloud-based system, which can be used to divide update data packets into multiple sub-data blocks based on a pre-defined update strategy. The update strategy may include, at a minimum, dividing the update data packets based on their size or the software type of the in-vehicle software to be updated. No specific limitations are placed on the cloud-based system for data packet division.

[0134] This embodiment proposes a system for updating in-vehicle software. In response to the presence of at least one piece of in-vehicle software to be updated within the vehicle, the system acquires storage information of an update data package for updating the in-vehicle software. This storage information at least indicates the number of sub-data blocks obtained after dividing the update data package, and the storage location of the sub-data blocks. Based on the region where the vehicle is located and the number of sub-data blocks, the system determines multiple target cloud servers for transmitting the sub-data blocks, and the corresponding transmission strategies for each target cloud server. The transmission strategies at least request the target cloud servers to transmit the sub-data blocks from their storage locations to the vehicle. The system then sends the transmission strategies to the corresponding target cloud servers. It acquires the sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategies. The system updates the in-vehicle software using the acquired sub-data blocks. Finally, it distributes the sub-data blocks from their storage locations to the vehicle via the target cloud servers according to the transmission strategies. This system solves the technical problem of low data processing efficiency in vehicles, thereby improving the technical effect of data processing efficiency in vehicles.

[0135] According to an embodiment of this application, an embodiment of a vehicle software update device is provided. It should be noted that the device can be used to execute the above-described vehicle software update method.

[0136] Figure 4 This is a schematic diagram of an in-vehicle software update device according to an embodiment of this application. Figure 4 As shown, the vehicle software update device may include: a data acquisition unit 42, a first determination unit 44, a second determination unit 46, and a control unit 48.

[0137] The first acquisition unit 42 is used to acquire the storage information of the update data packet of the vehicle software in response to the existence of at least one vehicle software to be updated in the vehicle. The storage information is used to characterize at least the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks.

[0138] The determining unit 44 is used to determine multiple target cloud servers for transmitting multiple sub-data blocks and the corresponding transmission strategies of the target cloud servers based on the region where the vehicle is located and the number of multiple sub-data blocks. The transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at the storage location to the vehicle.

[0139] The transmission unit 46 is used to send the transmission strategy to the corresponding target cloud server.

[0140] The second acquisition unit 48 is used to acquire multiple sub-data blocks transmitted using multiple target cloud servers in accordance with a transmission strategy.

[0141] Update unit 410 is used to update the vehicle software using the acquired multiple sub-data blocks.

[0142] Optionally, the determining unit 44 may further include: a determining module, used to determine multiple cloud servers deployed in the region; determine the data transmission speed of the cloud servers; and, based on the data transmission speed and the number of multiple sub-data blocks, determine multiple target cloud servers among the multiple cloud servers, as well as the transmission strategy corresponding to the target cloud servers.

[0143] Optionally, the determining module may further include: a determining submodule, used to determine the network status of the vehicle; based on the network status, determining the number of data channels used for transmitting multiple sub-data blocks, wherein the data channels are used for data communication between the vehicle and the target cloud server; and based on the number of channels, data transmission speed and the number of multiple sub-data blocks, determining multiple target cloud servers from multiple cloud servers, and determining the transmission strategy corresponding to the target cloud servers.

[0144] Optionally, the determination submodule can also be used to determine the target number of target cloud servers based on the number of channels and the number of multiple sub-data blocks; and to filter out the target number of cloud servers from multiple cloud servers based on the data transmission speed, thereby obtaining multiple target cloud servers.

[0145] Optionally, the transmission unit may further include: a generation module, configured to generate a data transmission instruction based on a transmission strategy, wherein the data transmission instruction indicates the storage location of the sub-data blocks to be transmitted on the target cloud server, and the transmission order of at least one sub-data block; send the data transmission instruction to the corresponding target cloud server; and obtain the sub-data blocks transmitted by the target cloud server according to the transmission strategy, including: controlling the target cloud server to distribute the sub-data blocks at the storage location to the vehicle according to the transmission order in the data transmission instruction; and obtaining the sub-data blocks transmitted by the target cloud server.

[0146] Optionally, the update unit 410 may further include: a processing module for merging the acquired multiple sub-data blocks to obtain an update data packet; and using the update data packet to update the vehicle software.

[0147] Optionally, the processing module may further include: a verification unit, configured to verify the sub-data block in response to its transmission to the vehicle and obtain a verification result; in response to the verification result indicating that the integrity of the sub-data block is not greater than the integrity threshold, to re-invoke the target cloud server to transmit the sub-data block; and in response to the verification result indicating that the integrity is greater than the integrity threshold and that multiple sub-data blocks have been transmitted to the vehicle, to merge the multiple sub-data blocks to obtain an updated data packet.

[0148] In the vehicle software update device of this embodiment, a first acquisition unit acquires the storage information of the update data packet of the vehicle software in response to the presence of at least one piece of vehicle software to be updated in the vehicle. The storage information is used to characterize at least the number of multiple sub-data blocks obtained after dividing the update data packet, and the storage location of the sub-data blocks. A determination unit determines multiple target cloud servers for transmitting the multiple sub-data blocks and the corresponding transmission strategy of the target cloud servers based on the region where the vehicle is located and the number of multiple sub-data blocks. The transmission strategy is used to request the target cloud servers to transmit the sub-data blocks at the storage location to the vehicle. A transmission unit sends the transmission strategy to the corresponding target cloud servers. A second acquisition unit acquires the multiple sub-data blocks transmitted by the multiple target cloud servers according to the transmission strategy. An update unit uses the acquired multiple sub-data blocks to update the vehicle software, thereby solving the technical problem of low data processing efficiency in the vehicle and achieving the technical effect of improving the data processing efficiency in the vehicle.

[0149] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0150] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0151] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0152] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0153] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0154] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0156] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0157] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0159] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for updating in-vehicle software, characterized in that, include: In response to the presence of at least one in-vehicle software in the vehicle that needs to be updated, the storage information of the update data package of the in-vehicle software is obtained, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after dividing the update data package, and the storage location of the sub-data blocks. Based on the region where the vehicle is located and the number of the multiple sub-data blocks, multiple target cloud servers for transmitting the multiple sub-data blocks are determined, as well as the transmission strategy corresponding to the target cloud servers. The transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at the storage location to the vehicle. The transmission strategy is sent to the corresponding target cloud server; Obtain multiple sub-data blocks transmitted using multiple target cloud servers in accordance with the transmission strategy; The vehicle software is updated using the acquired sub-data blocks.

2. The method according to claim 1, characterized in that, The determination of multiple target cloud servers for transmitting the multiple sub-data blocks, based on the region where the vehicle is located and the number of the multiple sub-data blocks, and the corresponding transmission strategies for the target cloud servers, includes: Identify the multiple cloud servers deployed in the region; Determine the data transmission speed of the cloud server; Based on the data transmission speed and the number of the multiple sub-data blocks, multiple target cloud servers among the multiple cloud servers are determined, as well as the transmission strategy corresponding to the target cloud servers.

3. The method according to claim 2, characterized in that, The step of determining multiple target cloud servers among multiple cloud servers, and the corresponding transmission strategy for each target cloud server, based on the data transmission speed and the number of multiple sub-data blocks, includes: Determine the network status of the vehicle; Based on the network status, the number of data channels used to transmit multiple sub-data blocks is determined, wherein the data channels are used for data communication between the vehicle and the target cloud server; Based on the number of channels, the data transmission speed, and the number of sub-data blocks, multiple target cloud servers are determined from the multiple cloud servers, and the transmission strategy corresponding to the target cloud server is determined.

4. The method according to claim 3, characterized in that, The step of determining multiple target cloud servers from multiple cloud servers based on the number of channels, the data transmission speed, and the number of multiple sub-data blocks includes: Based on the number of channels and the number of multiple sub-data blocks, the target number of the target cloud servers is determined; Based on the data transmission speed, a target number of cloud servers are selected from the multiple cloud servers to obtain multiple target cloud servers.

5. The method according to claim 3, characterized in that, Sending the transmission strategy to the corresponding target cloud server includes: Based on the transmission strategy, a data transmission instruction is generated, wherein the data transmission instruction is used to indicate the storage location of the sub-data block to be transmitted on the target cloud server, and the transmission order of at least one of the sub-data blocks; The data transmission instruction is sent to the corresponding target cloud server; The step of acquiring the sub-data block transmitted by the target cloud server according to the transmission strategy includes: controlling the target cloud server to distribute and transmit the sub-data block at the storage location to the vehicle according to the transmission order in the data transmission instruction; and acquiring the sub-data block transmitted by the target cloud server.

6. The method according to claim 1, characterized in that, The step of updating the vehicle software using the acquired multiple sub-data blocks includes: The acquired sub-data blocks are merged to obtain the updated data packet; The vehicle software is updated using the update data package.

7. The method according to claim 6, characterized in that, The step of merging the acquired sub-data blocks to obtain the updated data packet includes: In response to the transmission of the sub-data block to the vehicle, the sub-data block is verified to obtain a verification result; In response to the verification result indicating that the integrity of the sub-data block is not greater than the integrity threshold, the target cloud server is re-invoked to transmit the sub-data block; In response to the verification result indicating that the integrity level is greater than the integrity level threshold, and the fact that multiple sub-data blocks have been transmitted to the vehicle, the multiple sub-data blocks are merged to obtain the updated data packet.

8. A vehicle-mounted software update system, characterized in that, include: A vehicle, in response to the presence of at least one in-vehicle software to be updated, acquires storage information of an update data packet for updating the in-vehicle software, wherein the storage information is at least used to characterize the number of multiple sub-data blocks obtained after the update data packet is divided, and the storage location of the sub-data blocks; based on the region where the vehicle is located and the number of multiple sub-data blocks, determines multiple target cloud servers for transmitting the multiple sub-data blocks, and a transmission strategy corresponding to the target cloud servers, wherein the transmission strategy is at least used to request the target cloud servers to transmit the sub-data blocks at the storage locations to the vehicle; sends the transmission strategy to the corresponding target cloud servers; acquires the multiple sub-data blocks transmitted using the multiple target cloud servers according to the transmission strategy; and updates the in-vehicle software using the acquired multiple sub-data blocks. The target cloud server is used to distribute and transmit the sub-data blocks at the storage location to the vehicle in accordance with the transmission strategy.

9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 7.

Images