Finished vehicle OTA upgrade package streaming downloading method and device based on master control terminal, and medium

Abstract

The invention discloses a whole vehicle OTA upgrade package streaming downloading method based on a master control terminal, the method is applied to a vehicle-mounted remote information processing terminal TBOX, after the TBOX is connected with a vehicle-mounted information entertainment system IVI, upgrade package data fragments are downloaded from a cloud in a streaming mode and forwarded to the IVI to be stored in real time, and the upgrade package data fragments are stored in the IVI in a streaming mode. And determining subsequent downloading or retransmission operation according to fragment level verification feedback of the IVI to the received data. The core of the method is that the traditional role of the TBOX is changed, and the TBOX is changed from a node which must completely cache a large-volume upgrade package to a'pipeline 'which only carries out data stream relay. Through the assembly line work of downloading, forwarding and checking at the same time, the dependence on the limited storage space of the TBOX is directly eliminated, the problems of storage overflow and storage service life loss possibly caused by caching a complete packet are avoided, and meanwhile, through a real-time checking and feedback mechanism, the real-time performance of the TBOX is improved. And the success rate and the reliability of downloading the large file in an unstable vehicle-mounted network environment are obviously improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automotive electronics, in particular to a software and firmware remote updating technology for intelligent networked vehicles, and specifically to a vehicle OTA (Over-The-Air) upgrade package flow downloading method and system based on a vehicle-mounted remote information processing terminal (TBOX) as a master control. BACKGROUND

[0002] With the rapid development of intelligent networked vehicles, vehicle OTA technology has become a core means to realize function iteration, defect repair and safety enhancement. However, the size of vehicle OTA upgrade packages is becoming increasingly large, for example, the upgrade package of a video and audio entertainment domain controller can reach several GB or even larger.

[0003] Currently, the traditional OTA upgrade scheme mainly has the following problems:

[0004] 1. Low download efficiency and poor reliability of large-capacity upgrade packages: The traditional scheme usually adopts a whole package download mode, which requires downloading the complete upgrade package to a certain node (usually TBOX) inside the vehicle first and then distributing it. This way will occupy a large amount of network bandwidth for a long time, and is extremely prone to interruption due to unstable vehicle-mounted networks (such as 4G / 5G), which will lead to the entire download failure and the need to start over, resulting in poor user experience.

[0005] 2. TBOX resource bottleneck: TBOX, as a gateway for communication between the vehicle and the cloud, is mainly designed for communication functions, and the built-in embedded storage (such as eMMC) has limited capacity (usually several hundred MB to several GB) and a limited number of write cycles. Storing a complete GB-level upgrade package in it will not only cause storage overflow, but also significantly shorten its service life due to frequent write operations.

[0006] 3. Insufficient security and verification mechanism: The existing scheme mainly verifies the entire upgrade package after downloading. This way cannot timely detect data errors or malicious injections during the downloading process, and once the overall verification fails, the entire large package needs to be downloaded again, which is inefficient.

[0007] Therefore, some improved schemes have appeared in the industry, such as slice verification, P2P distribution, and cloud streaming, but none of them effectively solve the problem of efficient, reliable, and secure large-scale OTA upgrade package distribution under the premise of strict limitation of TBOX storage resources. SUMMARY

[0008] This application aims to overcome the shortcomings of the prior art and provides a method, device, and medium for streaming download of vehicle OTA upgrade packages based on a TBOX as the main controller. Its core objective is to achieve "streaming" processing of upgrade package data at the TBOX end, i.e., downloading from the cloud (i.e., the cloud server) while simultaneously forwarding it to other controllers in the vehicle (such as IVI), thereby completely avoiding caching the complete upgrade package locally on the TBOX, solving its storage capacity bottleneck and lifespan issues, and simultaneously improving the reliability, security, and efficiency of the download process. To achieve the above objectives, this application adopts the following technical solution.

[0009] In a first aspect, embodiments of this application provide a method for streaming download of a vehicle OTA upgrade package based on a master control terminal, including:

[0010] Establish a data transmission connection with IVI;

[0011] Retrieve the target OTA upgrade package information for the vehicle from the cloud server;

[0012] Based on the target OTA upgrade package information, download upgrade package data fragments from the cloud server in a streaming manner;

[0013] During the download of the upgrade package data fragments, the downloaded data content is forwarded to the IVI in real time through the data transmission connection, and stored by the IVI;

[0014] Receive verification feedback from the IVI for the forwarded data content; determine subsequent operations based on the verification feedback: if the feedback indicates successful verification, continue downloading and forwarding subsequent data fragments; if the feedback indicates failed verification, re-download the corresponding data fragments.

[0015] Furthermore, the verification feedback is the fragment-level verification result performed by the IVI; the fragment-level verification refers to the IVI performing integrity verification on data units with a preset data structure received through the data transmission connection.

[0016] Furthermore, based on the target OTA upgrade package information, upgrade package data fragments are streamed and downloaded from the cloud server, specifically including:

[0017] The size of the data fragments requested for download is dynamically adjusted based on the current network conditions.

[0018] Furthermore, establishing a data transmission connection with the IVI specifically includes:

[0019] The system performs interactive authentication with the IVI based on a dynamically generated session key. After successful authentication, the session key is used to encrypt, decrypt, or protect the integrity of data subsequently transmitted through the data transmission connection.

[0020] Furthermore, it also includes a resume function, specifically including:

[0021] When the streaming download is interrupted, the download status information at the time of the interruption is recorded;

[0022] When it is necessary to resume the download, the remaining upgrade package data that was not completed is requested from the cloud server based on the download status information.

[0023] Furthermore, the download status information refers to the amount of data that has been successfully forwarded to the IVI;

[0024] The process of requesting the download of the remaining incomplete upgrade package data based on the download status information specifically includes: obtaining the length of the upgrade package data already stored in the IVI, and determining the starting position for requesting data from the cloud server based on the length of the upgrade package data.

[0025] Furthermore, the upgrade package data fragments downloaded from the cloud server are encrypted and / or digitally signed; before or during the real-time forwarding of the downloaded data content to the IVI via the data transmission connection, the TBOX or the IVI performs corresponding security verification on the data fragments.

[0026] Furthermore, the target OTA upgrade package information obtained from the cloud server includes the fragment structure description information of the upgrade package; the fragment structure description information is used by the IVI to perform overall consistency verification of the complete upgrade package after all data fragments have been downloaded and verified successfully.

[0027] Secondly, embodiments of this application provide an electronic device, including: one or more processors;

[0028] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps of any of the preceding streaming download methods.

[0029] Thirdly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps of any of the aforementioned streaming download methods.

[0030] This application discloses a method for streaming OTA upgrade packages for a vehicle based on a master control terminal. This method is applied to a TBOX (Telematics Toll Collection Box). After establishing a connection between the TBOX and the IVI (In-vehicle Infotainment System), it performs streaming download of upgrade package data fragments from the cloud and forwards them to the IVI storage in real time. Simultaneously, it determines subsequent download or retransmission operations based on the fragment-level verification feedback of the received data from the IVI. The core of this method lies in changing the traditional role of the TBOX, transforming it from a node that must completely cache large upgrade packages into a "pipeline" that only relays data streams. Through a pipeline operation of "downloading, forwarding, and verifying simultaneously," the dependence on the TBOX's own limited storage space is directly eliminated, avoiding storage overflow and memory lifespan degradation problems that may occur due to caching complete packages. Furthermore, the real-time verification and feedback mechanism significantly improves the success rate and reliability of downloading large files in unstable in-vehicle network environments. Attached Figure Description

[0031] Figure 1 A core flowchart of a method for streaming downloading vehicle OTA upgrade packages based on a master control terminal, provided in an embodiment of this application;

[0032] Figure 2 This application provides a data flow diagram between the TBOX and IVI in an embodiment of the present application.

[0033] Figure 3 A schematic diagram illustrating the interaction between the TBOX and IVI for establishing a secure connection in an embodiment of this application;

[0034] Figure 4 A schematic diagram of a vehicle OTA upgrade package streaming download system based on a master control terminal is provided in an embodiment of this application;

[0035] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0037] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0038] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0039] The core concept of this application lies in transforming the role of the TBOX from an "upgrade package cache center" to a "secure data pipeline." The TBOX no longer stores the complete upgrade package but focuses on managing download tasks, acquiring data streams from the cloud, and securely and reliably directing the data streams in real time to an in-vehicle controller (such as an IVI) with high-capacity storage. The IVI is then responsible for receiving, verifying, storing, and ultimately assembling and verifying the upgrade package. The specific implementation methods of this application are described in detail below.

[0040] refer to Figures 1-4 One embodiment of this application proposes a method for streaming download of vehicle OTA upgrade packages based on a master control terminal, which may specifically include the following steps.

[0041] S1, TBOX and IVI establish a data transmission connection.

[0042] Specifically, after the vehicle is powered on, the TBOX automatically starts its internal Socket server, and the IVI automatically starts the corresponding Socket client, and the two parties establish a data transmission connection using a private protocol.

[0043] To protect the security of data transmission between the TBOX and IVI, a secure channel needs to be established before streaming. (Reference) Figure 3When a socket connection is established, the IVI client randomly generates a 16-byte key. Then, the IVI performs an XOR operation on each bit of the key with the corresponding bit of the preset frame header DFRD, and sends the result to the TBOX server. Upon receiving the key, the TBOX server performs a reverse XOR operation using the same DFRD to parse the original key. Next, the TBOX server also generates a 16-byte random number, Lock. It concatenates the key and Lock, performs another bitwise XOR operation with the DFRD, and sends the result back to the IVI client. After resolving the key, the IVI client first checks if the parsed key matches the one it initially sent. If they don't match, the identity is questionable, the connection is immediately closed, and a retry is attempted. If they match, the parsed original data (Key + Lock) is sent back to the TBOX server as is. The TBOX server then verifies if the received data matches the data it sent. If they match, authentication is successful. Subsequently, both parties can use the negotiated Key and / or Lock as a basis to derive a session key, which can be used to encrypt subsequent streaming data or generate message authentication codes (MACs), thereby achieving confidentiality and integrity protection of communication.

[0044] By exchanging and verifying randomly generated keys and locks, the TBOX and IVI complete mutual authentication and negotiate the encryption basis for subsequent communication when the socket connection is established. This protects the method of establishing a secure channel within the vehicle's internal network (between the TBOX and IVI). This prevents malicious data injection or eavesdropping that may occur within the in-vehicle network, thereby improving the security of the data flow from the TBOX to the IVI and forming an important part of the vehicle's OTA security system.

[0045] S2 and TBOX obtain the target OTA upgrade package information for the vehicle from the cloud server.

[0046] Specifically, when TBOX detects an OTA upgrade task to be executed from the cloud, its upgrade task management module sends a request to the cloud to obtain the metadata of the upgrade package, including but not limited to package size, version number, shard hash list or Merkle tree root node and other shard structure description information.

[0047] S3. Based on the target OTA upgrade package information, TBOX streams upgrade package data fragments from the cloud server. S4. During the download of the upgrade package data fragments, TBOX forwards the downloaded data to the IVI in real time via the data transmission connection, where the IVI stores it.

[0048] Specifically, TBOX's streaming download engine module begins operation. It requests the first data fragment from the cloud based on initial settings (e.g., 1 MB). The cloud divides the upgrade package into several data fragments with CRC checksums and digital signatures for TBOX to download. Once the streaming download engine module receives some or all of the fragmented data from the network buffer, the data forwarding module immediately encapsulates it (e.g., adding a header DFRD, a trailer DRFD, and a checksum) and sends it to IVI's socket client via the established socket connection.

[0049] TBOX's streaming download engine module incorporates an adaptive algorithm. TBOX starts downloads with a small default chunk size (e.g., 1 MB; the lower limit for chunk size can be set to 10 KB, and the upper limit to 10 MB). The streaming download engine module continuously monitors the download speed and forwarding speed to the IVI for the most recent chunks (e.g., 5). It calculates the average speed and assesses its volatility. If network conditions are stable, the algorithm gradually increases the chunk size for the next request, for example, by 1 MB each time, until the upper limit is reached, to improve throughput. If a speed drop, increased volatility, or transmission failure is detected, the requested chunk size is proportionally reduced to enhance success rate in weak network environments. This dynamic adjustment mechanism allows the download process to adapt to unstable in-vehicle network environments such as 4G / 5G, increasing throughput when the network is good and reducing the size of a single request to lower the probability of failure when the network is poor, thereby optimizing the overall stability and efficiency of the download.

[0050] On the cloud side, the upgrade package has been preprocessed before distribution: first, it is logically divided into multiple fragments; then, a CRC checksum and a digital signature based on the cloud private key are calculated for each fragment; finally, a Merkle Tree is constructed based on the hash values ​​of all fragments.

[0051] When TBOX downloads a fragment, it can choose to first verify the fragment's digital signature (using a pre-configured cloud public key) to ensure the fragment's origin is authentic and has not been tampered with, before forwarding it to IVI. Alternatively, to reduce TBOX's computational burden, it can directly forward the signed fragment, allowing IVI to perform signature verification after completing the CRC check.

[0052] Each data fragment distributed from the cloud is accompanied by a signature. The TBOX can verify this signature after downloading, or the IVI can verify it after receiving. Combined with the secure channel between the TBOX and IVI in step S1, a dual secure link is formed: "cloud to TBOX" and "TBOX to IVI". This effectively prevents OTA upgrade packages from being tampered with throughout the entire transmission chain, resists man-in-the-middle attacks, and ensures the authenticity of the upgrade package's origin and the integrity of its content.

[0053] After all streaming is complete, IVI has stored all fragments. At this point, IVI uses the Merkle root hash from the upgrade package metadata initially obtained from TBOX to recalculate all fragment hashes and construct a Merkle tree. By comparing the calculated root hash with the root hash provided by the cloud, the final verification of the overall consistency of the entire upgrade package is completed. This mechanism ensures that even if each fragment passes individual verification, there is no risk of fragment loss, out-of-order issues, or overall replacement, laying the foundation for a reliable upgrade installation.

[0054] S5. TBOX receives verification feedback from the IVI for the forwarded data content; and decides on subsequent operations based on the verification feedback: if the feedback indicates successful verification, it continues to download and forward subsequent data fragments; if the feedback indicates failed verification, it re-downloads the corresponding data fragments.

[0055] Specifically, after receiving data, the IVI client first parses the data block according to the agreed header and trailer, and immediately calculates its checksum for comparison, completing fragment-level verification. The verification result is fed back to the TBOX feedback processing module via a Socket connection. If the verification is successful, the IVI storage module saves the data fragment, and the TBOX feedback processing module notifies the streaming download engine module to continue requesting and forwarding the next data fragment. If the verification fails, the IVI discards the data, and after receiving the failure feedback, the TBOX controls the streaming download engine module to re-download the current fragment. This "download-forward-verify-response" pipeline continues to run until all fragments have been processed.

[0056] After all fragments have been transferred, IVI uses the fragment structure description information (such as Merkle root hash) obtained from TBOX to perform overall consistency verification on all stored fragments. If the verification passes, IVI notifies TBOX that the upgrade package is ready and provides the storage path, then proceeds with the subsequent installation process; if the verification fails, TBOX is notified that it needs to download the package again.

[0057] Optionally, the whole vehicle OTA upgrade package streaming download method based on the master control terminal proposed in this embodiment may also include: S6, the breakpoint resume download step.

[0058] Specifically, during the streaming download process, if the connection between TBOX and the cloud is interrupted due to network anomalies, TBOX's feedback processing module will record the data position corresponding to the last successfully received "verification successful" feedback from IVI. When the network recovers and the download needs to continue, TBOX does not directly use its recorded internal download offset, but actively queries IVI's storage module for the total length of the currently successfully stored upgrade package data. This length represents the amount of data that has been safely stored at the final storage point and is the most reliable progress indicator. Based on this length, TBOX's upgrade task management module initiates an HTTP request with an offset (Range Request) to the cloud, and the cloud only returns the data after that offset.

[0059] Resuming interrupted downloads allows TBOX to precisely download only the missing portions, eliminating the need for the cloud to maintain complex breakpoint states. This significantly improves the reliability of large file downloads in unstable network environments, avoids duplicate downloads, and saves user bandwidth and server bandwidth. This embodiment also explicitly states that TBOX uses the storage progress of the IVI as the basis for resuming downloads. This reflects the collaborative design of TBOX and IVI: the IVI, as the final storage and verification entity for data, provides the most authoritative reflection of download progress in terms of its storage status. This setup eliminates the need for TBOX to persistently store complex breakpoint information locally, thus simplifying TBOX logic and improving the reliability of the solution.

[0060] refer to Figure 4 One embodiment of this application proposes a vehicle OTA upgrade package streaming download system based on a master control terminal. This system is deployed as a software module within the processor of a TBOX. Specifically, the system includes:

[0061] Connection Management Module: Responsible for listening to the port after the vehicle is powered on, establishing and maintaining a long-term secure connection with the IVI based on Socket.

[0062] Upgrade Task Management Module: It is activated periodically or by cloud push notifications and is responsible for communicating with the cloud to query, obtain, and parse OTA upgrade task metadata.

[0063] Streaming download engine module: The core download unit, which interacts with the cloud via HTTP / HTTPS protocols according to instructions from the upgraded task management module. It has network status awareness, can dynamically adjust the request size, and supports resuming interrupted download requests with offsets.

[0064] Data forwarding module: Acts as a bridge between the download engine and the Socket connection. It reads data from the download engine's buffer, encapsulates it according to the private protocol format agreed upon with IVI (adding headers, footers, and checksums), and calls the connection management module's interface to send the data packets out.

[0065] Feedback processing module: Listens for Socket messages from the IVI and parses the verification result (success / failure) for each data segment. Based on the verification result, it issues instructions to the streaming download engine module: if the verification is successful, it notifies it to continue to the next segment; if the verification fails, it commands it to retry the current segment. Simultaneously, it is responsible for maintaining progress information for resuming interrupted downloads.

[0066] Overall, compared with the prior art, the technical solution provided in this application has the following significant advantages:

[0067] 1. Significantly optimizes TBOX resource usage: Through the "download-forward" pipeline operation, TBOX only needs to cache the single data fragment currently being processed (e.g., 1 MB) to support download tasks of GB-level or even larger upgrade packages, fundamentally solving the problems of limited embedded storage capacity and erase / write lifespan of TBOX.

[0068] 2. Significantly improved download reliability: The introduction of a segment-level real-time verification and feedback retransmission mechanism enables the immediate detection and correction of errors during transmission, preventing overall failure. Combined with intelligent breakpoint resume functionality, only the missing portion needs to be downloaded after network interruption, increasing the download success rate of large files in unstable network environments by over 90%.

[0069] 3. Enhanced security throughout the entire process: A dual security link is constructed from the cloud to TBOX (encrypted signature fragment), and then to the dynamic key security channel between TBOX and IVI, which can effectively resist man-in-the-middle attacks and data tampering, ensuring the security and trustworthiness of the OTA upgrade process.

[0070] 4. Achieve adaptive network optimization: By dynamically adjusting the request chunk size, the download process can adapt to changing network conditions, improving efficiency when the network speed is stable and ensuring stability when the network speed fluctuates, thereby optimizing the user experience.

[0071] The embodiments of the whole vehicle OTA upgrade package streaming download method based on the master control terminal and the embodiments of the whole vehicle OTA upgrade package streaming download system based on the master control terminal are the same or related in technical concept. They can refer to each other in terms of technical details and technical effects, and will not be repeated here.

[0072] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 5As shown in the embodiments of this application, an electronic device includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the streaming download methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0073] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0074] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0075] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0076] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the streaming download methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0077] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described streaming download method.

[0078] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0079] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0080] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0081] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0082] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0083] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0084] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0085] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0087] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for streaming download of vehicle OTA upgrade packages based on a master control terminal, characterized in that, include: Establish a data transmission connection with IVI; Retrieve the target OTA upgrade package information for the vehicle from the cloud server; Based on the target OTA upgrade package information, download upgrade package data fragments from the cloud server in a streaming manner; During the download of the upgrade package data fragments, the downloaded data content is forwarded to the IVI in real time through the data transmission connection, and stored by the IVI; Receive verification feedback from the IVI for the forwarded data content; determine subsequent operations based on the verification feedback: if the feedback indicates successful verification, continue downloading and forwarding subsequent data fragments; if the feedback indicates failed verification, re-download the corresponding data fragments.

2. The streaming download method according to claim 1, characterized in that, The verification feedback is the fragment-level verification result performed by the IVI; the fragment-level verification refers to the IVI performing integrity verification on data units with a preset data structure received through the data transmission connection.

3. The streaming download method according to claim 1 or 2, characterized in that, Based on the target OTA upgrade package information, upgrade package data fragments are streamed and downloaded from the cloud server, specifically including: The size of the data fragments requested for download is dynamically adjusted based on the current network conditions.

4. The streaming download method according to claim 1, characterized in that, Establishing a data transmission connection with the IVI specifically includes: The system performs interactive authentication with the IVI based on a dynamically generated session key. After successful authentication, the session key is used to encrypt, decrypt, or protect the integrity of data subsequently transmitted through the data transmission connection.

5. The streaming download method according to claim 1, characterized in that, It also includes the step of resuming interrupted downloads, specifically including: When the streaming download is interrupted, the download status information at the time of the interruption is recorded; When it is necessary to resume the download, the remaining upgrade package data that was not completed is requested from the cloud server based on the download status information.

6. The streaming download method according to claim 5, characterized in that, The download status information is the amount of data that has been successfully forwarded to the IVI; The process of requesting the download of the remaining incomplete upgrade package data based on the download status information specifically includes: obtaining the length of the upgrade package data already stored in the IVI, and determining the starting position for requesting data from the cloud server based on the length of the upgrade package data.

7. The streaming download method according to claim 1, characterized in that, The upgrade package data fragments downloaded from the cloud server are encrypted and / or digitally signed; before or during the real-time forwarding of the downloaded data content to the IVI via the data transmission connection, the TBOX or the IVI performs corresponding security verification on the data fragments.

8. The streaming download method according to claim 1, characterized in that, The target OTA upgrade package information obtained from the cloud server includes the fragment structure description information of the upgrade package; the fragment structure description information is used by the IVI to perform overall consistency verification of the complete upgrade package after all data fragments have been downloaded and verified successfully.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors are enabled to perform the steps in the streaming download method as described in any one of claims 1 to 8.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it can perform the steps of the streaming download method as described in any one of claims 1 to 8.

Images