Vehicle remote upgrading method, vehicle, cloud server and medium

Abstract

The application relates to the technical field of intelligent networked vehicle remote software upgrading, in particular to a vehicle remote upgrading method, a vehicle, a cloud server and a medium. In view of the problems of insufficient instruction legality, non-uniform upgrade object identification and poor link reliability of software package acquisition and execution in the existing remote upgrading, a unified upgrading processing scheme is provided: a vehicle receives a remote upgrading instruction containing a software package acquisition address, an upgrade object type and verification information, first carries out legality verification on the remote upgrading instruction based on the verification information, acquires a corresponding software upgrade package from an object storage service according to the software package acquisition address after the verification passes, and schedules an upgrade execution end indicated by the upgrade object type to complete the upgrading. The scheme can simultaneously support unified management of vehicle-mounted communication terminal self-upgrading and vehicle-mounted electronic control unit upgrading, and enhance the reliability and controllability of remote upgrading.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and in particular to a method for remotely upgrading a vehicle, a vehicle, a cloud server, and a medium. Background Technology

[0002] Remote vehicle upgrade technology falls under the fields of vehicle networking and vehicle electronic software management. As vehicles become increasingly intelligent, the software iteration frequency of onboard electronic control units and onboard communication terminals increases significantly. Remote upgrade technology has become a key means of ensuring continuous vehicle software updates and reducing maintenance costs.

[0003] Existing remote vehicle upgrade solutions typically involve a cloud management platform sending upgrade commands to the in-vehicle communication terminal. Upon receiving the command, the in-vehicle communication terminal downloads the software package and completes the flashing of its own or the vehicle's electronic control unit. In some solutions, the cloud is responsible for storing the software package and scheduling tasks, while the vehicle executes the upgrade and reports its status via a message middleware.

[0004] However, existing technologies have the following shortcomings: the lack of a unified two-way real-time interaction mechanism between the cloud and the vehicle leads to a lag in the synchronization of upgrade progress; insufficient security verification of upgrade commands; and the absence of a complete process from task release, command verification, software download, hierarchical upgrade to task closed-loop aggregation, making it difficult to simultaneously support unified management of the upgrade of the vehicle communication terminal itself and the upgrade of the vehicle electronic control unit, resulting in insufficient monitorability and execution reliability of batch upgrade tasks. Summary of the Invention

[0005] This application provides a method for remote vehicle upgrades, a vehicle, a cloud server, and a medium, which can simultaneously support unified management of upgrades to both the vehicle communication terminal itself and the vehicle electronic control unit, thereby enhancing the reliability and controllability of remote upgrades.

[0006] In a first aspect, embodiments of this application provide a method for remotely upgrading vehicles, the method comprising:

[0007] Receive remote upgrade instructions, which include the package acquisition address, upgrade object type, and verification information;

[0008] Based on the verification information, the legality of remote upgrade commands is verified.

[0009] If the verification passes, download the software upgrade package corresponding to the package acquisition address from the object storage service;

[0010] The upgrade execution end controls the upgrade object type indication and performs upgrade operations based on the software upgrade package.

[0011] In one possible implementation, when the upgrade execution end indicated by the upgrade object type is an in-vehicle communication terminal, the upgrade operation is performed based on the software upgrade package, including:

[0012] Delete historical software packages from local storage;

[0013] Unzip the software upgrade package and deploy the extracted software data to the local system's runtime directory;

[0014] Record upgrade information and initiate a restart of the vehicle communication terminal;

[0015] After restarting, if upgrade information is detected, an upgrade success message is sent to the cloud server.

[0016] In one possible implementation, when the upgrade execution end indicated by the upgrade object type is an electronic control unit, the upgrade operation is performed based on the software upgrade package, including:

[0017] Send an upgrade preparation command to the electronic control unit and erase historical software packages from the electronic control unit;

[0018] Transmit the software upgrade package to the electronic control unit;

[0019] After the transmission is complete, a reset command is sent to the electronic control unit to restart the electronic control unit and run the software data of the software upgrade package;

[0020] Send an upgrade success message to the cloud server.

[0021] Secondly, embodiments of this application provide a method for remotely upgrading a vehicle, the method comprising:

[0022] Obtain upgrade task configuration information, which includes the target vehicle's vehicle identifier and the corresponding software upgrade package information;

[0023] A remote upgrade command is generated based on the upgrade task configuration information. The remote upgrade command includes the software package acquisition address, vehicle identifier, upgrade object type, and verification information. This enables the target vehicle to verify the legality of the remote upgrade command based on the verification information. If the legality verification is successful, the vehicle downloads the software upgrade package corresponding to the software package acquisition address from the object storage service. The upgrade execution terminal controls the upgrade object type indication and performs the upgrade operation based on the software upgrade package.

[0024] Send the remote upgrade command to the communication topic corresponding to the target vehicle identifier;

[0025] Update the download status of the target vehicle based on the download status message reported by the target vehicle;

[0026] Update the upgrade task status of the target vehicle based on the upgrade result message reported by the target vehicle.

[0027] In one possible implementation, after updating the upgrade task status of the corresponding vehicle based on the upgrade result message, the method further includes:

[0028] When the upgrade task status of all target vehicles is "vehicle upgrade successful", the execution status of the upgrade task corresponding to the upgrade task configuration information is determined to be "all successful".

[0029] If the upgrade task status of any of the target vehicles is "vehicle upgrade failed", the execution status of the upgrade task is determined to be "partially successful".

[0030] In one possible implementation, before obtaining the upgrade task configuration information, the method further includes:

[0031] Obtain the software upgrade package;

[0032] Store the software upgrade package in an object storage service.

[0033] In one possible implementation, the method also includes:

[0034] If there are still vehicles that have not reported upgrade results after the preset time period, the execution status of the upgrade task will be determined based on the received upgrade results messages.

[0035] Thirdly, embodiments of this application provide a vehicle, including: a memory and a processor;

[0036] The memory stores the instructions that the computer executes;

[0037] The processor executes computer execution instructions stored in memory, causing the processor to perform a method as described in any of the first aspects of the embodiments of this application.

[0038] Fourthly, embodiments of this application provide a cloud server, including: a memory and a processor;

[0039] The memory stores the instructions that the computer executes;

[0040] The processor executes computer execution instructions stored in memory, causing the processor to perform a method as described in any of the second aspects of the embodiments of this application.

[0041] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect, and the second aspect and / or various possible implementations of the second aspect.

[0042] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect, and the second aspect and / or various possible implementations of the second aspect.

[0043] In this embodiment, a remote upgrade command is received, including a software package acquisition address, an upgrade object type, and verification information. Based on the verification information, the remote upgrade command is validated for legality. If the validation passes, a software upgrade package corresponding to the software package acquisition address is downloaded from the object storage service. The upgrade execution terminal, indicating the upgrade object type, is controlled to perform the upgrade operation based on the software upgrade package. This enables unified management of both the upgrade of the vehicle communication terminal itself and the upgrade of the vehicle electronic control unit, enhancing the reliability and controllability of remote upgrades. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] Figure 1 A flowchart illustrating the vehicle remote upgrade method provided in this application embodiment;

[0046] Figure 2 A flowchart illustrating the vehicle remote upgrade method provided in this application embodiment;

[0047] Figure 3 This is a schematic diagram of the vehicle remote upgrade device provided in the embodiments of this application;

[0048] Figure 4 This is a schematic diagram of the vehicle remote upgrade device provided in the embodiments of this application;

[0049] Figure 5 This is a schematic diagram of the vehicle structure provided in an embodiment of this application;

[0050] Figure 6 This is a schematic diagram of the structure of a cloud server provided in an embodiment of this application. Detailed Implementation

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

[0052] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0053] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0054] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0055] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0056] Remote vehicle software update technology falls under the cross-disciplinary field of intelligent connected vehicles, in-vehicle communication, and electronic control collaborative management. It is primarily applied to software maintenance, function iteration, and fault repair scenarios during the vehicle's service life. In these scenarios, vehicles typically do not undergo software updates by returning to the factory or a shop. Instead, they rely on the collaboration between a cloud service platform, in-vehicle communication terminals, and in-vehicle upgrade execution devices to remotely trigger upgrade tasks, acquire software packages, and execute upgrades.

[0057] In a typical system architecture, the cloud platform is used to generate and issue remote upgrade commands, and also provides the software package acquisition address; the vehicle side is equipped with an in-vehicle communication terminal, which is used to receive remote upgrade commands from the cloud server and obtain the corresponding software resources according to the content of the remote upgrade commands; the vehicle is also equipped with an execution terminal that specifically undertakes the upgrade action, which can be the in-vehicle communication terminal itself or the target control unit in the vehicle.

[0058] In a mass production and operation environment for vehicles, remote upgrades are often carried out simultaneously on multiple vehicle models and batches, with vehicles operating under different network conditions, operating states, and software versions. Therefore, the upgrade process involves not only the accurate acquisition of software package addresses but also the reliability of the command source, the accuracy of the upgrade target identification, and the correct triggering of the upgrade action. Especially when the upgrade target may be the communication terminal itself or different types of in-vehicle control units, ensuring legitimate command reception, software package download, and upgrade execution within a unified remote upgrade process has become a fundamental requirement in intelligent vehicle software maintenance scenarios.

[0059] Meanwhile, existing technologies often handle upgrade targets in a fragmented manner. Upgrades to the in-vehicle communication terminal itself and upgrades to other control units frequently employ different processes or even different toolchains, resulting in insufficient unified management capabilities. When a vehicle faces a situation where multiple types of control units coexist, the upgrade control logic can easily become complex due to the differences in the targets, leading to problems such as unclear identification and inconsistent execution paths.

[0060] Furthermore, the lack of upgrade support for in-vehicle communication terminals is particularly prominent in the existing system. Since the communication terminal both receives messages and may be the target of upgrades, the absence of a unified object type indication and execution control mechanism easily leads to reliance on offline maintenance for version updates. Therefore, while existing technologies have established a basic framework for remote vehicle upgrades, they still have significant shortcomings in ensuring command legitimacy, standardizing software package acquisition, uniformly identifying upgrade targets, and ensuring consistent upgrade execution. These deficiencies make it difficult to meet the reliability, compatibility, and controllability requirements of complex in-vehicle environments.

[0061] In view of this, how to build a clearer and more reliable upgrade processing path in the scenario of remote vehicle upgrade, so that remote commands can be verified after entering the vehicle, then used to obtain the correct software upgrade package, and finally implemented by the upgrade execution terminal corresponding to the upgrade object type, has become an urgent technical problem to be solved.

[0062] To address the aforementioned needs, this application proposes a method for remote vehicle upgrades. Upon receiving a remote upgrade command, the method uses the software package acquisition address, upgrade object type, and verification information carried in the remote upgrade command as key inputs. First, it verifies the legality of the remote upgrade command based on the verification information. If the command is confirmed to be trustworthy and executable, it downloads the software upgrade package corresponding to the software package acquisition address from the object storage service. Then, it controls the upgrade execution terminal indicated by the upgrade object type to perform the upgrade operation based on the downloaded software upgrade package.

[0063] This technical approach remains applicable to remote upgrade architectures that coordinate cloud service systems, in-vehicle communication terminals, and vehicle upgrade execution ends. However, its focus is not on adding complex additional functions, but on establishing a unified processing logic around "legitimate command—correct package—corresponding execution end," enabling different upgrade objects to be scheduled in an orderly manner within the same methodological framework. By performing pre-validation of remote upgrade commands and incorporating the package acquisition address and upgrade object type into the same process control, the credibility of commands, the accuracy of object matching, and the reliability of upgrade execution during the remote upgrade process can be improved, thus providing a clear technical foundation for the subsequent design of upgrade processes in specific implementation methods.

[0064] The vehicle remote upgrade method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0065] Figure 1 This is a flowchart illustrating a vehicle remote upgrade method according to an embodiment of this application. Figure 1 As shown, the executing entity of the vehicle remote upgrade method in this embodiment can be the vehicle-mounted communication terminal, the upgrade management module integrated with the vehicle-mounted communication terminal, or the vehicle computing unit with the ability to receive and schedule remote upgrade tasks.

[0066] Specifically, the vehicle remote upgrade method of this embodiment may include the following steps S101 to S104:

[0067] S101: Receive remote upgrade instructions, which include the package acquisition address, upgrade object type, and verification information.

[0068] Among them, remote upgrade instructions refer to control instructions generated and issued by cloud service platforms, background task scheduling systems, operation management pages, or other server-side modules with task creation capabilities, which are used to instruct vehicles to perform specified software upgrade tasks.

[0069] The software package acquisition address represents the access location of the software upgrade package on the remote storage side. It can be a Uniform Resource Locator (URL), an object storage download link, a temporary access address with authentication parameters, or a resource identifier after mapping and conversion.

[0070] The upgrade object type is used to identify the actual object to be upgraded. It can be the vehicle communication terminal itself, or the electronic control unit inside the vehicle. It can also be further refined into a specific controller category, protocol category, hardware platform category, or upgrade mode category.

[0071] Verification information is used to support the verification of the source of remote upgrade instructions, the integrity of the content, and the fact that the transmission process has not been tampered with. It can be represented by one or more of the following: signature information, message digest, digital certificate, message authentication code, timestamp combination field, random number identifier, or anti-replay identifier.

[0072] In practice, after creating an upgrade task, the cloud server can encapsulate the target vehicle identifier, software package version identifier, software package acquisition address, upgrade object type, and signature verification field (i.e., verification information) into a remote upgrade command, and send it to the vehicle via a message middleware. The message middleware can be a service component that supports high-concurrency message forwarding, and the communication link can use the MQTT protocol, or HTTP (HyperText Transfer Protocol) long connections, HTTPS (HyperText Transfer Protocol Secure) push, WebSocket, or other message delivery methods suitable for the vehicle-to-everything (V2X) environment.

[0073] In one possible embodiment, the cloud-based OTA (Over-The-Air) service first writes the upgrade task into a task queue, and then the task scheduler executes the queuing and push according to the vehicle online status, network status, vehicle batch information or task priority, thereby making the message receiving process in the scenario of multiple vehicles upgrading concurrently more orderly.

[0074] On the vehicle side, while maintaining a connection with the cloud message link, the vehicle communication terminal subscribes to topic messages corresponding to the vehicle's VIN, device serial number, or terminal identity. When it detects a remote upgrade command that matches its own terminal, it parses the remote upgrade command, extracts the software package acquisition address, upgrade object type, and verification information, and can simultaneously extract auxiliary fields such as version number, target vehicle model identifier, ECU type, release timestamp, task number, and retry control parameters.

[0075] When the receiving action is completed, in order to avoid misreceiving, misparsing, or repeated upgrades due to duplicate message delivery, the vehicle can first perform a matching judgment on the target range of the remote upgrade command based on the vehicle's identity information, such as verifying whether the VIN, terminal ID (Identifier), device certificate identifier, and local registration information are consistent; after identifying the task corresponding to the target vehicle, the remote upgrade command is then written to the local upgrade task cache or persistent task table, and an internal task index, receiving timestamp, and current status flag are assigned to the task.

[0076] In practical applications, for scenarios where users are momentarily offline and then return to online, this embodiment can also support the re-fetching or repeated notification identification of historical incomplete upgrade tasks. It can determine whether a task has been executed by combining the task number and version number, thereby avoiding duplicate flashing.

[0077] Based on the above processing, receiving remote upgrade instructions is no longer simply receiving an upgrade message, but rather forming a complete pre-processing chain consisting of cloud task generation, message middleware forwarding, vehicle identity matching, field extraction, and task registration. This gives the upgrade action a unified entry point and a clear data foundation, providing accurate input for subsequent legality verification and software package acquisition.

[0078] S102: Verify the validity of remote upgrade commands based on verification information.

[0079] In this step, the legitimacy verification is used to confirm whether the remote upgrade command comes from a trusted source, whether the command content has been tampered with during transmission, and whether the current upgrade task is executable. Since the remote upgrade link typically spans multiple nodes, including cloud platforms, message middleware, public networks, and vehicle equipment, abnormal forwarding, forged messages, or duplicate transmissions at any node can lead to erroneous upgrades. Therefore, legitimacy verification needs to be a critical prerequisite step before the upgrade execution.

[0080] The interpretation of verification information is related to its encoding mechanism. For example, when the verification information is a signature value, the vehicle can concatenate the key fields in the remote upgrade command in an agreed order, generate a digest using a hash algorithm, and then use a pre-set public key, certificate, or shared key to complete the signature verification. When the verification information is a message authentication code, the vehicle can recalculate the authentication value based on the key and message content and compare it. When the verification information includes a timestamp, random number, and task sequence number, further timeliness verification and anti-replay judgment can be performed.

[0081] In practice, after parsing the remote upgrade command, the vehicle-mounted communication terminal can standardize and encode the package acquisition address, upgrade object type, target vehicle identifier, software version number, task number and other key fields according to the specifications agreed upon in advance between the cloud and the vehicle. Then, it calls the local security module, cryptographic operation library or signature verification component in the trusted execution environment to verify the verification information.

[0082] In one example, if a digital signature mechanism is used, the vehicle can read the cloud service certificate chain from the local certificate repository, first verifying whether the certificate chain was issued by a trusted root certificate, whether it is within its validity period, and whether it has been revoked, and then verifying the signature value based on the certificate public key; if the verification result is consistent with the local recalculated digest, it can be determined that the remote upgrade instruction is trustworthy and complete.

[0083] In another example, if a message authentication code is used, the vehicle and the cloud can share a task key or a device-level key. The vehicle recalculates the authentication value of the message based on the key and checks whether it matches the verification information. For scenarios involving timestamps, the vehicle can also compare the difference between the current system time and the instruction generation time to see if it is within an allowed window, such as a few minutes to tens of minutes, to reduce the risk of expired instructions being executed. For scenarios involving random numbers or one-time tokens, the vehicle can query the local used identifier table. If it finds that the same random identifier has been processed, it determines that the instruction has a replay risk and refuses to execute it.

[0084] In addition to verifying the verification information itself, this embodiment can also incorporate the business consistency of the upgrade task into the legality verification process. For example, the vehicle determines whether the upgrade object type matches the list of upgrade objects supported by the vehicle, whether the current software version is indeed lower than the target version specified in the instruction, whether the domain name or bucket identifier of the package acquisition address belongs to the trusted object storage service whitelist, and whether the current state of the vehicle meets the upgrade prerequisites, such as being parked, having a stable power supply, having a network available, or being able to establish a diagnostic session.

[0085] For upgrades to the vehicle communication terminal itself, the dual-partition status, remaining storage space, and availability of the rollback image can be checked before the upgrade. For ECU upgrades, the bus connection status with the target ECU, session activation status, and protocol version compatibility can be pre-checked. If any of the above conditions are not met, the vehicle can mark the verification result as a failure and generate a result record containing the failure reason code, task number, and time information, which will be reported to the cloud, thereby blocking subsequent download and upgrade operations.

[0086] As can be seen, in this embodiment, the legitimacy verification plays the role of security gating in the upgrade link. It not only verifies the authenticity and integrity of the remote upgrade command, but also, by combining timeliness verification, replay verification, target matching verification, and business condition verification, further transforms the "command that can reach the vehicle" into a "trustworthy and executable command." This effectively reduces the risk of command tampering, mis-issuance, duplicate execution, and erroneous upgrade triggering, thereby improving the security and stability of remote vehicle upgrade scenarios and establishing a trusted foundation for subsequently obtaining the correct software package from the object storage service.

[0087] S103: If the verification passes, download the software upgrade package corresponding to the package acquisition address from the object storage service.

[0088] Among them, object storage services refer to remote storage platforms that have the ability to store files as objects, access them by address, and control access permissions. They can provide cloud-based OSS (Object Storage Service) services or other object storage systems that support the distribution of large files.

[0089] A software upgrade package is a collection of files used to update a target software version. It can be a single binary image, a compressed file, a differential package, a segmented package, or a combination of files containing a manifest file, a signature file, and an upgrade script. The software download action is triggered only after S102 confirms the legitimacy of the remote upgrade command, thereby ensuring that the vehicle does not access resources from untrusted sources or with incomplete content, and preventing the download of erroneous packages.

[0090] In the specific implementation process, the vehicle first generates a download request based on the package retrieval address. If the package retrieval address is in the form of a URL (Uniform Resource Locator), the vehicle can directly initiate a GET (HyperText Transfer Protocol GET) request to the object storage service based on the HTTP or HTTPS protocol; if the package retrieval address contains temporary signature parameters, access tokens, or session credentials, the vehicle will include the corresponding authentication information when initiating the request; if the package retrieval address is an internal resource identifier, the vehicle can first access the address mapping service or resource resolution module to convert the resource identifier into an accessible download link before initiating the download.

[0091] Furthermore, to improve adaptability in complex network environments, vehicles can send a HEAD (HyperText Transfer Protocol HEAD) request or metadata query request before the formal download to obtain metadata such as file length, file digest, version tag, fragment information, and validity period, and verify whether the software upgrade package is consistent with the current task number, target version, and upgrade object type. If an invalid address, access denied, version mismatch, or object non-existent is found, the download can be aborted and a failure message can be reported.

[0092] During the download execution phase, the vehicle can use either a full package download or a segmented download method. For smaller communication terminal firmware packages, the entire package can be directly pulled and written to the local cache partition. For larger controller program packages, the software upgrade package can be divided into multiple data blocks, downloaded sequentially, and written to disk block by block. If necessary, the offset of the currently completed download can be recorded to support resuming interrupted downloads. In scenarios with frequent network fluctuations, the vehicle can perform retry control and integrity verification for each segment separately, and roll back the task state after reaching the retry limit.

[0093] During the download process, the vehicle can also monitor the transmission rate, download timeout, remaining storage space, and network switching status in real time. When a temporary interruption of the cellular network or an abnormal response of the object storage service is detected, the current session can be paused and the download can continue after the network is restored, avoiding the overall termination of the task due to a one-time failure.

[0094] After the software download is complete, the vehicle can perform another integrity check on the local download results based on the digest value, manifest file, or independent signature file included with the software upgrade package to confirm that the downloaded content is consistent with the remote resource.

[0095] For local management of software upgrade packages, this application embodiment can write the downloaded files to an isolated upgrade cache area instead of directly overwriting the currently running partition, thereby providing a safe buffer for subsequent parsing, verification and flashing.

[0096] For example, if the software upgrade package is in compressed format, the vehicle can decompress it after verification and verify whether the directory structure, image size, compatible hardware identifier, and flashing script of the decompressed files conform to preset rules. If the software upgrade package is a differential package, the current base version can be read locally first and the differential package compatibility can be verified. The subsequent upgrade process will only continue if the base version matches.

[0097] Thus, through the above-described method of downloading the corresponding software upgrade package from the object storage service, the package acquisition address is transformed into a standardized, verifiable, and recoverable download link. This eliminates the reliance on vague manual configuration or temporary forwarding in the software resource acquisition process, instead providing clear address resolution, permission checks, transmission control, and local verification mechanisms. This improves the stability and accuracy of remote upgrades in complex vehicle networking environments.

[0098] S104: The upgrade execution terminal that controls the upgrade object type indication, and performs upgrade operations based on the software upgrade package.

[0099] Specifically, the upgrade execution end refers to the entity that actually undertakes tasks such as software writing, program refreshing, image switching, firmware loading, or diagnostic downloading. It can be the in-vehicle communication terminal itself, the target ECU inside the vehicle, or an upgrade agent module or protocol conversion module deployed in the in-vehicle communication terminal. The upgrade object type plays a routing and scheduling role in this step; that is, the vehicle delivers the downloaded software upgrade package to the corresponding upgrade execution path based on the upgrade object type, thereby ensuring compatibility with both the communication terminal's own upgrades and upgrades of other control units within a unified process.

[0100] When the upgrade execution end indicated by the upgrade object type is the vehicle communication terminal itself, the vehicle can use the local upgrade management program to call the local flashing component to process the software upgrade package, that is, delete the historical software package stored locally; decompress the software upgrade package and deploy the decompressed software data to the local system running directory; record the upgrade information and initiate the restart of the vehicle communication terminal; after restarting, if the upgrade information is detected, send an upgrade success message to the cloud server.

[0101] The locally stored historical software packages include downloaded but not cleaned-up old version compressed packages, temporary installation packages, and expired packages corresponding to the current upgrade task. Deleting these files can free up storage space and prevent old packages from being mixed with new packages. The local system runtime directory is a persistent directory for the upgraded program to load and execute. The decompressed software data can be written to the executable file area, configuration file area, or resource file area in this directory, so that the new version can be directly loaded by the system after restarting.

[0102] In actual deployment, after receiving the download completion marker, the vehicle-mounted communication terminal first locates the historical software packages that need to be cleaned up based on the package identifier or version number, and performs the deletion operation through the file system interface. Subsequently, the software upgrade package is decompressed. The decompression process can be completed by the built-in decompression component. The decompressed software data is written to a temporary directory or directly to the production directory after integrity verification to ensure that the deployed content is consistent with the upgrade package content. After the software data is written, the vehicle-mounted communication terminal writes the upgrade version number, task identifier, completion status, and restart instruction to persistent storage, forming upgrade information that can be recovered and read after power failure or reset, and triggers the terminal restart, so that the new version program is loaded during the startup phase.

[0103] After the terminal restarts, the startup program reads the upgrade information from persistent storage. If the upgrade identifier still exists and matches the current version status, the local upgrade is considered successful, and an upgrade success message is sent to the cloud server via the vehicle communication link. Upon receiving the message, the cloud server updates the remote task status and records the upgrade task status of the vehicle communication terminal.

[0104] In this way, the vehicle-mounted communication terminal can form a closed loop between deleting historical packets, decompressing and deploying, recording status, restarting confirmation and reporting results, reducing storage usage and improving upgrade consistency and traceability, thereby improving the stability and success rate of remote software updates for vehicles.

[0105] When the upgrade execution end indicated by the upgrade object type is a target ECU, the vehicle communication terminal can act as the upgrade master node, encapsulate the software download results according to the diagnostic or flashing protocol supported by the target control unit and forward them. That is, it sends an upgrade preparation command to the electronic control unit and erases the historical software packages in the electronic control unit; it transmits the software upgrade package to the electronic control unit; after the transmission is completed, it sends a reset command to the electronic control unit to make the electronic control unit restart and run the software data of the software upgrade package; and it sends an upgrade success message to the cloud server.

[0106] The electronic control unit (ECU) is used to control target functions in the vehicle in real time. It typically has a non-volatile memory area to store historical software packages and operating parameters. The upgrade preparation command enables the ECU to enter a programming state that allows receiving upgrade data and triggers it to clear historical software packages to make room for the new package, while also preventing conflicts between old and new software data. In practical applications, the upgrade preparation command can be sent to the ECU via the onboard communication terminal according to the diagnostic communication protocol; this embodiment does not limit this approach.

[0107] After preparation is complete, the software upgrade package is sent from the vehicle side to the electronic control unit (ECU) according to a preset transmission protocol. The transmission process can employ a segmented writing method, allowing the ECU to verify and cache the received software data segment by segment. During the receiving process, the ECU can return a response message, which the vehicle communication terminal uses to confirm whether the current data block has successfully arrived and, if necessary, retransmit, thereby improving write reliability. After the software upgrade package is transmitted, the vehicle communication terminal sends a reset command to the ECU, causing the ECU to exit the programming state and re-initialize. It then calls the written software data to complete the startup and operation, thus making the new version of the software package effective. The reset command can be implemented via a soft reset or a controlled power-off and power-on method. In practical applications, other models or protocols can also be selected for this reset method, which is not limited in this embodiment.

[0108] Once the electronic control unit (ECU) has restarted and its status has been confirmed, the vehicle communication terminal will report a successful upgrade message to the cloud server. This message may include a task identifier, ECU identifier, version information, and completion time, allowing the cloud server to update the vehicle software version record and terminate the upgrade task. Through this process, the old version data of the ECU is cleared, the new version software package is reliably written and successfully launched, and the cloud can promptly receive the upgrade results.

[0109] This implementation method performs preparation and erasure before the upgrade, completes stable transmission during the upgrade, performs reset and activation after the upgrade, and simultaneously feeds back the results to the cloud. This enables the remote upgrade process of the electronic control unit to have clear state switching and result closed loop, which can reduce the risks of old package residue, write failure and version switching anomalies.

[0110] By adopting this implementation method, the electronic control unit can be kept under control before and after the upgrade, reducing the interference of historical software packages on the operation of the new version, improving the success rate of software package writing and the upgrade completion rate, and enabling the cloud server to keep abreast of the vehicle-side upgrade progress, thereby improving the reliability, traceability and consistency of remote upgrades.

[0111] In one example, if the target ECU supports the UDS (Unified Diagnostic Services) protocol, the in-vehicle communication terminal can first establish a diagnostic session with the target ECU via the vehicle bus, and then perform steps such as secure access, erasing the memory area, requesting download, transmitting data, and exiting the transmission. Specifically,

[0112] The vehicle-mounted communication terminal can divide the software upgrade package into multiple data segments, send them segment by segment according to the data block size acceptable to the target ECU, and wait for a positive response or status feedback after each segment is sent; when a transient error occurs, it can resend, retry after a delay, or resume the session according to the protocol.

[0113] After all data segments have been transmitted, the vehicle communication terminal can instruct the target ECU to perform verification, write to take effect, and restart operations. After restarting, it can reread the version number, software fingerprint, or status word to confirm the upgrade result. If the upgrade target type represents different categories of ECUs, this embodiment can also switch different protocol stacks, message mapping rules, timeout parameters, segment sizes, and error recovery strategies according to the ECU type, thereby improving compatibility with multiple types of control units.

[0114] Furthermore, this embodiment can also set up a full-process status monitoring mechanism while performing the upgrade operation. The vehicle can maintain a state machine for each upgrade task, with states including at least received, verified, downloading, download completed, upgrading, upgrade successful, and upgrade failed, and record the timestamp and reason code corresponding to each state transition. When package verification failure, write failure, communication interruption, ECU unresponsiveness, or restart anomaly occurs during the upgrade process, the vehicle can trigger an exception branch handling, such as stopping the task, rolling back the configuration, releasing the diagnostic session, cleaning up temporary files, and reporting the error log to the cloud.

[0115] For scenarios that support batch upgrades or sequential upgrades of multiple modules, the upgrade object type can also be associated with the module list. Vehicles can schedule multiple upgrade execution terminals to perform upgrades in a predefined order, ensuring that the dependencies are clear and the upgrade process of each module is traceable.

[0116] As can be seen, this embodiment, through the control mechanism of "upgrade object type - execution terminal mapping - corresponding upgrade path execution," unifies the previously scattered upgrades of communication terminals and ECUs into a single remote upgrade framework. This not only makes the upgrade task scheduling logic clearer but also enables the automatic selection of appropriate execution strategies, transmission protocols, and recovery methods based on different target objects. This ensures that different upgrade objects are accurately triggered and reliably executed under the premise of unified reception, unified verification, and unified download, thereby improving the accuracy of object identification and the consistency of upgrade execution.

[0117] According to the vehicle remote upgrade method provided in this embodiment, a remote upgrade command containing a software package acquisition address, upgrade object type, and verification information is received. The legality of the remote upgrade command is verified based on the verification information. If the verification passes, a software upgrade package corresponding to the software package acquisition address is downloaded from the object storage service. The upgrade execution terminal, indicated by the upgrade object type, is then controlled to perform the upgrade operation based on the software upgrade package. Thus, the remote upgrade processing chain is constructed as a continuous closed loop of "legal command verification, standardized software package acquisition, and object-type-oriented execution terminal scheduling." This ensures that remote upgrades are no longer limited to direct downloading and flashing after message arrival, but instead establish a credibility judgment before upgrade, a correct resource acquisition mechanism during upgrade, and a consistent matching relationship between the object and the execution path during the upgrade execution phase. This effectively solves the problems of insufficient command credibility, non-standardized software package address processing, scattered upgrade object identification, and inconsistent execution paths in existing technologies. It improves the security, stability, compatibility, and controllability of the vehicle remote upgrade process, and enables vehicles to complete software updates of the communication terminal itself and different in-vehicle control units within a relatively unified technical framework during service. It should be understood that the above examples are merely illustrative and not limiting. In one possible embodiment, the protocol for carrying the remote upgrade command, the specific form of the verification information, the deployment method of the object storage service, and the flashing protocol used by the upgrade execution terminal can all be adjusted according to the actual vehicle architecture and cloud system configuration. However, as long as the processing ideas of pre-validation, obtaining the correct software package by address, and controlling the corresponding execution terminal to complete the upgrade according to the upgrade object type are followed, they can all fall within the technical scope of the embodiments of this application.

[0118] Figure 2 This is a flowchart illustrating a vehicle remote upgrade method according to an embodiment of this application. Figure 2 As shown, the vehicle remote upgrade method of this embodiment can be executed by a cloud server. Specifically, the vehicle remote upgrade method of this embodiment may include S201 to S205:

[0119] S201: Obtain upgrade task configuration information, which includes the target vehicle's vehicle identifier and the corresponding software upgrade package information.

[0120] In this embodiment, the upgrade task configuration information can be understood as a set of data pre-organized by the cloud server for executing a remote software upgrade task, used to describe "which vehicle, which software package, and which type of upgrade task". The vehicle identifier is used to uniquely identify the target vehicle in the vehicle set, and can specifically be the chassis number, T-Box (Telematics Box) terminal number, SIM (Subscriber Identity Module) card associated device number, vehicle communication address, or a unique vehicle identification code uniformly assigned internally by the platform.

[0121] Software upgrade package information is used to identify the software resources to be distributed and their associated attributes. Specifically, this may include the upgrade package name, package version number, target version number, package storage location, file size, file digest value, compatible vehicle models, compatible controller identifier, release date, validity period, and compatibility constraints. The aforementioned "obtaining" can be done by reading from the manual configuration page, or by loading from the task database, scheduling service, interface requests, or batch import files.

[0122] In one possible implementation, when operators enter upgrade tasks through the management console, they first select a list of target vehicles, then select the corresponding software upgrade package. The platform then generates one or more task records accordingly. After reading the task records from a relational database or distributed configuration library, the task management service extracts the vehicle identifier and software upgrade package information to form an upgrade task configuration information object.

[0123] When initiating upgrades for a fleet or batch of vehicles, the platform can first filter vehicles based on criteria such as vehicle model, region, production batch, and current software version. Then, it establishes a mapping relationship between each target vehicle in the filter results and the same upgrade package information, so that remote upgrade instructions can be generated for each vehicle in the future. After this processing, the upgrade task is no longer limited to a coarse-grained "batch distribution" level, but is broken down into traceable, auditable, and retryable single-vehicle task units.

[0124] In another possible implementation, the upgrade task configuration information is not entirely created manually, but is automatically generated by the background task orchestration system. For example, when the platform detects a defect in the software version of a batch of vehicles, or when a new version of a functional module is released, the strategy engine can automatically scan for vehicles that meet the conditions according to preset rules, call the software repository service to obtain the matching software upgrade package information, and generate the correspondence between the target vehicles and the upgrade packages. The software repository service can return the resource identifier, digital signature digest, fragment download parameters, and adaptation instructions of the package body in the object storage service, thus providing a complete data foundation for subsequent instruction generation.

[0125] To ensure the task configuration is executable, after obtaining the upgrade task configuration information, the cloud server can also preprocess and perform consistency checks on the data in the upgrade task configuration information. Specifically, this includes verifying whether the vehicle identifier exists in the vehicle registry, verifying whether the target vehicle's current online status meets the conditions for real-time delivery, verifying whether the software upgrade package has been released and approved, verifying whether the software package's compatibility scope includes the target vehicle's corresponding model and hardware configuration, and verifying whether the current upgrade task conflicts with other incomplete tasks.

[0126] For example, only one task is allowed to be downloading or upgrading for the same target vehicle at a time. If a conflicting task is found, the new task is either queued or returned to the operations team for processing. This filters out invalid configurations, incorrect mappings, or version incompatibility, improving the success rate of subsequent upgrade processes from the source.

[0127] It should be noted that the "correspondence" relationship in the software upgrade package information is not limited to one vehicle corresponding to one package; it can also be one vehicle corresponding to multiple sub-packages, such as corresponding to the vehicle communication terminal program, the diagnostic adapter program, and the firmware package of a specific ECU. In this case, the upgrade task configuration information can include a package list, package order, and dependency fields to support serial upgrades or phased upgrades.

[0128] In this step, by establishing a complete and accurate task configuration foundation, the cloud server can have clear data input when generating remote upgrade commands in the future, avoiding problems such as incorrect distribution, incorrect download, or incorrect upgrade due to inaccurate vehicle identification or incomplete package information.

[0129] It should be noted that before this step, you can first obtain the software upgrade package and store it in an object storage service. The object storage service can be deployed in a cloud server cluster and associated with the software upgrade package through a unified resource address, temporary signature access address, or download identifier, thus facilitating subsequent remote command referencing.

[0130] In this embodiment, the software upgrade package can be uploaded by the operating platform or automatically retrieved from a preset software repository by the background orchestration service. After retrieval, the software upgrade package undergoes integrity verification and version identification before being written to a designated bucket or storage space in the object storage service. During the writing process, metadata such as filename, version number, verification summary, compatible vehicle model identifier, and validity period can be generated simultaneously. This ensures that when generating upgrade task configuration information, the corresponding software upgrade package can be accurately matched based on the target vehicle identifier and software version information.

[0131] It is understood that when a software upgrade package contains multiple sub-files, compression, fragmentation, or signing can be performed before storage to improve transmission efficiency and verification reliability. In practical applications, other implementations of this storage and processing method can also be selected, and this application embodiment does not limit this.

[0132] S202: Generate remote upgrade instructions based on upgrade task configuration information. The remote upgrade instructions include the package acquisition address, vehicle identifier, upgrade object type, and verification information.

[0133] In this embodiment, the remote upgrade command can be understood as a structured control message generated by the cloud server for the vehicle. It carries the core execution parameters of the remote upgrade task and drives the vehicle to acquire the upgrade package and select the upgrade execution terminal. The package acquisition address indicates where the vehicle obtains the software resources to be upgraded, which can be a download link in the object storage service, a pre-signed URL, a resource path identifier, or a temporary access address converted through an access gateway. The upgrade object type identifies the actual object to be upgraded, which can be the vehicle communication terminal, engine control unit, battery management system, body controller, cockpit domain controller, or other electronic control units.

[0134] Verification information is used to support vehicles in verifying the source, content integrity, and untampered transmission process of remote upgrade commands. It can be represented by one or more of the following: signature information, message digest, digital certificate, message authentication code, timestamp combination field, random number identifier, or anti-replay identifier.

[0135] In practice, the cloud server first uses the storage location or resource number in the software upgrade package information to call the object storage service or resource management service to obtain the package access address accessible to the vehicle. If the storage system uses a temporary authorization access mechanism, the platform can generate a temporary address with an expiration time and access signature based on the key, task validity period, vehicle identifier, and download permissions before generating the instruction. This ensures that the address is only available within a set time limit, reducing the risk of long-term abuse after the upgrade package link is intercepted.

[0136] Subsequently, the cloud server determines the upgrade object type based on the package type or target controller information specified in the task. For example, when the software upgrade package information indicates that the object to be upgraded is the vehicle communication terminal's own application, the upgrade object type can be encoded as the vehicle communication terminal; when the adapter ECU field in the package information points to a specific controller, the upgrade object type can be encoded as the corresponding electronic control unit category or address identifier.

[0137] When generating verification information, the cloud server can concatenate the package acquisition address, vehicle identifier, upgrade object type, timestamp, and task number in a predetermined order, perform a signature operation using the platform's private key, generate an instruction signature field, and write the signature result as verification information into the remote upgrade instruction. After receiving the instruction, the vehicle can use a preset public key to verify the signature, thereby confirming that the instruction was indeed generated by a trusted cloud server and that its content has not been tampered with during transmission.

[0138] Alternatively, verification information can be generated using a message authentication code (MAC) method. This involves the cloud server and vehicle sharing a symmetric key, calculating the MAC for key fields, and the vehicle using the same key for comparison. If the vehicle's communication architecture is sensitive to message length, only the digest of the core fields can be signed to balance security and transmission efficiency.

[0139] In addition to the core fields mentioned above, remote upgrade commands may also include extended content such as task number, generation time, timeout duration, download retries, upgrade trigger conditions, breakpoint resume flag, task priority, and return channel identifier. The task number facilitates the cloud server and vehicle's tracking of the same upgrade task; the generation time and timeout duration allow the vehicle to identify expired commands; the download retries limit the retry limit under network fluctuations; and the upgrade trigger conditions instruct the vehicle to perform subsequent upgrade actions only when parked, when the battery power meets a threshold, or when the critical bus is idle. Although these extended fields are not the minimum components of this step, their inclusion enhances the executability and controllability of the commands.

[0140] This step is a crucial component of the entire solution. Its role extends beyond simply "assembling a message"; it involves transforming the task configuration on the cloud server into a unified upgrade control mechanism that the vehicle can directly understand and execute. By simultaneously including the package acquisition address, vehicle identifier, upgrade object type, and verification information within a single remote upgrade command, the vehicle no longer needs to query multiple services for package addresses, upgrade targets, and authentication information. This reduces message interaction layers, compresses the processing path, and allows the vehicle to immediately begin subsequent processing based on trusted verification, correct download, and object matching upon receiving the command. This effectively mitigates risks such as command tampering, unclear upgrade object identification, and package / target mismatch.

[0141] S203: Send the remote upgrade command to the communication topic corresponding to the target vehicle identifier.

[0142] The communication topic can be understood as a logical channel for targeted message delivery between the cloud server's message system and the vehicle terminal. Its essence is a message routing identifier established for a specific subscription relationship.

[0143] A mapping relationship exists between the target vehicle's vehicle identifier and the communication topic. Based on this mapping relationship, the cloud server delivers remote upgrade instructions belonging only to a specific target vehicle to the message channel that the vehicle can subscribe to and receive. The communication topic can be a topic name based on the MQTT protocol, or a queue name, routing key, session channel identifier, or device message topic from other message middleware.

[0144] In one possible implementation, the platform maintains a mapping table between vehicle identifiers and communication topics. For example, during vehicle registration, the access service assigns a unique topic to each vehicle. The topic name includes the vehicle's unique identification code, terminal number, or platform tenant identifier. After generating the remote upgrade command, the cloud server calls the message distribution service to query the corresponding topic based on the vehicle identifier and publishes the command to that topic via the MQTT Broker. The in-vehicle communication terminal on the target vehicle has pre-subscribed to the same topic and can receive the command in real time when the vehicle is online. To prevent misdelivery, the message distribution service can also compare the vehicle identifier, terminal session information, and the binding relationship of the subscribed topic again before sending; publication is only performed if all three match.

[0145] In another possible implementation, the messaging system supports an offline caching mechanism. When the target vehicle is temporarily offline, the remote upgrade command can be stored in the message middleware or business cache, with a timeout period marked. When the vehicle reconnects and resumes its subscription, the platform redelivers the cached command. If the cache time exceeds the allowed validity period of the task, the platform can abandon the push and adjust the task status to pending resend or expired to prevent vehicles from executing expired software upgrade tasks too late. For large-scale concurrent vehicle upgrade scenarios, the platform can also adopt a partitioned topic or hierarchical routing mechanism, such as first routing messages according to vehicle type, region, or fleet, and then redirecting them according to vehicle identifiers within the routing domain to improve the message system's throughput.

[0146] Considering that the communication link in the vehicle-to-everything (V2X) environment may go through multiple links such as the public network, operator network, access gateway and vehicle communication module, a sending confirmation and message tracking mechanism can also be introduced in this step.

[0147] Specifically, after publishing the remote upgrade command to the communication topic, the message distribution service can record the message ID, publication time, delivery status, and associated task number, and wait for the message middleware to return a successful delivery response. If no delivery confirmation is received within a preset time, the system can resend, switch to a backup broker, or log the exception. For scenarios requiring high-reliability transmission, message quality level parameters can be set to allow the message system to retain a copy of the message before the vehicle confirms receipt, thereby improving the upgrade command delivery rate.

[0148] From a technical perspective, sending remote upgrade commands to the communication topic corresponding to the target vehicle identifier transforms upgrade control from traditional broadcast, manual forwarding, or vaguely targeted push methods to a device-level targeted delivery method. This approach reduces the probability of non-target vehicles mistakenly receiving upgrade commands, ensures a one-to-one correspondence between tasks and vehicles, and allows for accurate tracking of subsequent download status and upgrade results for the same vehicle and task. Particularly in scenarios involving mass vehicle operations, the binding relationship between communication topics and vehicle identifiers enables cloud servers to precisely manage massive numbers of upgrade tasks, improving message routing clarity and execution consistency.

[0149] S204: Update the download status of the target vehicle based on the download status message reported by the target vehicle.

[0150] Download status messages refer to the procedural status data that the target vehicle sends back to the cloud server during the software upgrade package download process after receiving a remote upgrade command. These messages reflect the current stage of the download task and whether any anomalies have occurred. Download status can be represented by status codes, text identifiers, or structured fields, and may include statuses such as pending download, download started, download in progress, download completed, download failed, download timed out, download interrupted, verification failed, and canceled. In addition to status fields, download status messages may also include task number, vehicle identifier, message time, current download progress, number of bytes downloaded, total number of bytes, download rate, error code, and reason for the anomaly.

[0151] For example, after receiving and verifying the remote upgrade command, the vehicle-mounted communication terminal connects to the object storage service based on the software package address to begin downloading the software upgrade package. During the download process, the vehicle sends back download status messages according to preset events or time periods. For example, it reports "Download started" at the start of the download, reports "Downloading" at regular intervals or when a certain percentage of progress has been added, along with the progress percentage and the amount of data downloaded, reports "Download completed" upon completion, and reports "Download failed" along with the corresponding error code when the download is interrupted due to network disconnection, connection failure, insufficient disk space, or package verification failure.

[0152] After receiving the above message, the cloud server status management service first finds the corresponding task instance based on the vehicle identifier and task number, and then updates the download status field in the database to the current status represented by the message.

[0153] To prevent older messages from overwriting newer ones, cloud servers can incorporate timestamp comparison, status priority determination, or sequence number checking mechanisms. For example, if a task's download status is already recorded as "download complete," and a subsequent "downloading" message arrives late due to network delays, the system can refuse to roll back the update based on message time and status priority, thus maintaining consistency in status records. Furthermore, if the system receives multiple consecutive "downloading" statuses but the progress remains unchanged for an extended period, the platform can mark the task as "download abnormal" based on timeout rules and trigger alarms, manual intervention, or automatic retry logic.

[0154] In this application, download status updates go beyond simply writing the current status; they synchronously maintain the task's execution trajectory. The cloud server can record the last reported time, the most recent valid progress, the cumulative number of retries, historical anomaly causes, and download source node information in the status table. This allows operations personnel to trace the cause of task failures—whether it's due to expired object storage address, vehicle network jitter, insufficient terminal storage space, or a mismatch in the download packet digest. If the target vehicle supports resumeable downloads, the cloud server can also mark the status as ready for resumption, allowing the download to continue after re-deployment or when the vehicle regains network connectivity.

[0155] As can be seen, the download status update enables the cloud server to monitor the vehicle package acquisition status in real time in real-world environments with complex vehicle network conditions and diverse upgrade targets, thereby improving the monitorability and stability of the remote upgrade link.

[0156] S205: Update the upgrade task status of the target vehicle based on the upgrade result message reported by the target vehicle.

[0157] The upgrade result message refers to the result message sent back to the cloud server by the target vehicle after the upgrade is completed, which is used to characterize the final execution conclusion of this upgrade task. The upgrade task status is a comprehensive status definition made by the cloud server for the entire life cycle of the upgrade task. It is usually higher than the simple download status and can reflect whether the task is completed, whether it is successful, and whether there are failures, rollbacks, or partial completions.

[0158] For example, the upgrade result message may include fields such as upgrade successful, upgrade failed, partial success, rollback successful, rollback failed, upgrade canceled, upgraded version number, self-test result, flash verification result, reason for failure, and end time.

[0159] In practical applications, upgrade result messages can also drive version log updates and subsequent operational actions. When the message contains the upgraded version number and the result is successful, the cloud server can synchronously update the vehicle's software version file, serving as the basis for subsequent differential upgrades, recall analysis, and maintenance audits. When the result is a failure and the error code points to a fixed defect, the cloud server can automatically trigger a rollback task, suspend upgrades for vehicles in the same batch, or notify manual maintenance personnel for further processing. Therefore, the upgrade task status update is not merely a database field modification, but truly incorporates vehicle execution feedback into closed-loop management.

[0160] This allows cloud servers to extend their capabilities beyond task configuration, command issuance, and download process tracking to result convergence and archiving management, ultimately determining whether each vehicle has completed the planned software changes. This avoids situations where the task appears to be completed but the actual upgrade fails, improving the reliability and traceability of remote software maintenance.

[0161] Furthermore, in this embodiment, after updating the upgrade task status of the corresponding vehicle based on the upgrade result message, it may further include: when the upgrade task status of all target vehicles is "vehicle upgrade successful", determining the execution status of the upgrade task corresponding to the upgrade task configuration information as "fully successful"; when the upgrade task status of any of the target vehicles is "vehicle upgrade failed", determining the execution status of the upgrade task as "partially successful".

[0162] In this way, after receiving the upgrade result message, the cloud server updates the upgrade task status of the corresponding vehicle to "vehicle upgrade successful" or "vehicle upgrade failed," and associates this status with the task number to facilitate aggregated judgment for multiple target vehicles under the same upgrade task. To avoid errors in status statistics, the cloud server can maintain a target vehicle status table in the storage layer. The status table records the current upgrade task status of each target vehicle according to its vehicle identifier, and updates the corresponding record when a new upgrade result message is received.

[0163] When the upgrade task status of all target vehicles is updated to "Vehicle Upgrade Successful," the cloud server determines the upgrade task execution status corresponding to the upgrade task configuration information as "All Successful." This indicates that the upgrade task has completed closed-loop execution on all target vehicles. If, during the status statistics of all target vehicles, the upgrade task status of any vehicle is "Vehicle Upgrade Failed," the cloud server determines the execution status of that upgrade task as "Partially Successful," indicating that the task has been successfully completed on some target vehicles, while at least one target vehicle has not yet completed the upgrade. This execution status can be written to the task result database and synchronized to the operation and maintenance monitoring interface, log system, or alarm module for subsequent querying and processing.

[0164] In its implementation, the cloud server can read the status records of all target vehicles in a batch based on the task number and perform consistency checks on the status values. If all status values ​​in the records meet the success conditions, a full success flag is output; if there are failure conditions in the records, a partial success flag is output. The partial success flag can also serve as a trigger for subsequent compensation upgrades, re-distributing upgrade packages, or manual intervention. Through this process, the cloud server can map the upgrade result of a single vehicle to the overall result of the upgrade task, thereby achieving unified management of remote upgrade tasks for multiple vehicles.

[0165] This approach ensures that the final state of the upgrade task directly depends on the actual upgrade results of each target vehicle, accurately reflecting the completion status of the batch upgrade task. By distinguishing and recording complete successes from partial successes, it facilitates quick confirmation of whether the entire batch of vehicles has been upgraded, and also helps to promptly locate the anomaly range when there are failed vehicles, improving the traceability, manageability, and subsequent handling efficiency of remote upgrade tasks.

[0166] It should be noted that in practical applications, if there are still vehicles that have not reported upgrade result messages after the preset time period, the execution status of the upgrade task will be determined based on the upgrade result messages that have been received.

[0167] In this embodiment, a vehicle that has not reported an upgrade result message refers to a target vehicle that has not returned an upgrade success message or an upgrade failure message to the cloud server within a preset statistical time period. The preset time period can be set by the backend based on the upgrade task type, the number of target vehicles, the network environment, and the response characteristics of the vehicle terminal.

[0168] The received upgrade result messages can be single vehicle reports or summaries of results from multiple target vehicles. The cloud server can statistically categorize these messages to form a set of vehicles that have completed feedback.

[0169] In actual processing, after the preset time has elapsed, the cloud server first checks if there are still vehicles that have not yet reported results. If such vehicles exist, the cloud server no longer waits for all vehicles to report, but instead determines the status distribution of the vehicles that have reported results based on the received upgrade result messages. If all received results indicate a successful upgrade, the execution status of the upgrade task can be determined as fully successful; if some received results indicate upgrade failure, the execution status of the upgrade task can be determined as partially successful. For vehicles that have not reported upgrade result messages, the cloud server can synchronously mark them as timed out and retain their vehicle identifier, task number, and last communication time for subsequent verification, alarm notification, or manual review.

[0170] Through the above processing, a usable final task state can still be formed even when some vehicles fail to return results on time, avoiding the upgrade task remaining in an incomplete state for a long time. This method makes task aggregation no longer dependent on all vehicles completing feedback simultaneously, thereby improving the timeliness and stability of upgrade task status determination and reducing the risk of task suspension due to communication abnormalities, disconnections, or terminal overload of individual vehicles. For remote upgrade scenarios involving a large number of vehicles, this method can also improve the scheduling efficiency of cloud servers, facilitating subsequent compensation processing for vehicles that have not responded.

[0171] According to the vehicle remote upgrade method provided in this embodiment, upgrade task configuration information is obtained, including the target vehicle's vehicle identifier and corresponding software upgrade package information. A remote upgrade command is generated based on the upgrade task configuration information, including the software package acquisition address, vehicle identifier, upgrade object type, and verification information. The remote upgrade command is sent to the communication topic corresponding to the target vehicle identifier. The download status of the target vehicle is updated based on the download status message reported by the target vehicle. The upgrade task status of the target vehicle is updated based on the upgrade result message reported by the target vehicle. This enables the cloud server to establish a task mapping around the target vehicle and the software upgrade package, further converting this mapping into a structured remote upgrade command containing the software package acquisition address, upgrade object type, and verification information, and completing targeted distribution through the communication topic bound to the vehicle identifier. The method also receives download status messages and upgrade result messages continuously transmitted back by the vehicle during the download and upgrade execution process, completing status updates, anomaly identification, and task closed-loop management. Therefore, it ensures the matching relationship between the upgrade object and the software package, and enhances the traceability of the upgrade process and the confirmability of the final status.

[0172] The following example illustrates the vehicle remote upgrade method provided in this embodiment.

[0173] First, operators upload vehicle software upgrade package information via the OTA page. Upon receiving this information, the cloud server's OTA service uploads it to the Object Storage Service (OSS). Operators then select the list of vehicles to be upgraded and the OTA package information via the OTA page, and issue the upgrade command. The cloud server's OTA service receives the OTA release command and, through middleware, sends the vehicle upgrade command to the appropriate vehicle groups.

[0174] The vehicle upgrade command includes: the URL address of the vehicle software OTA package, the vehicle identification number (VIN), the upgrade type (Telematics Box (Tbox) / Electronic Control Unit (ECU)), the ECU type, and signature information. The corresponding vehicle-side Tbox receives the OTA upgrade command from the cloud server. The Tbox checks the upgrade command and verifies the parameters using the signature information. If the verification passes, the Tbox begins preparing for the upgrade.

[0175] After Tbox verification is successful, Tbox downloads the software upgrade package from the OSS service using the vehicle software OTA package URL. When the package download begins, Tbox uploads the download progress information to the vehicle via the service. Upon receiving this information, the cloud server OTA service updates the vehicle-specific task to "downloading." Tbox uploads the download progress information every 10 seconds. The cloud server OTA service updates the download progress until it reaches 100%, at which point it uploads a successful download message to the cloud server OTA service. Upon receiving the successful download message from the vehicle, the cloud server immediately issues a command to start the vehicle upgrade process.

[0176] After receiving the start upgrade command, Tbox determines whether to upgrade Tbox or ECU.

[0177] When Tbox determines it needs an upgrade, it begins deleting historical software packages and decompressing the latest package information. After successful decompression and recording the current upgrade information, Tbox initiates a restart. After restarting, the vehicle checks for upgrade information. If an upgrade is needed, Tbox uploads the successful upgrade command to the cloud server's OTA service and deletes the local upgrade information.

[0178] When the Tbox determines that it needs to upgrade ECU information, it transmits the software package information in segments via the UDS protocol. First, an OTA upgrade command is sent to the ECU. Upon receiving the command, the ECU begins preparation for the upgrade. The Tbox then sends information to erase the historical ECU software package and transmits the package information in segments again. During the transmission, the upgrade progress is reported in real-time to the cloud server's OTA service, which updates the real-time progress. After the Tbox completes the software package transmission via the UDS protocol, it sends a reset command to the ECU, causing the ECU to restart. The Tbox then uploads a successful upgrade notification to the cloud server's OTA service. If the transmission is interrupted during the software package transfer, the Tbox considers the upgrade to have failed and also uploads the failure notification to the cloud server's OTA service. The cloud server then receives the upgrade completion command.

[0179] After the cloud server OTA receives the upgrade success command, it updates the current vehicle OTA support successfully and determines whether all current tasks have been completed. If all tasks have been completed, it checks whether the current task has been updated successfully. If some vehicles have failed to update, the vehicle OTA task is considered partially successful. If some vehicles are still in OTA, the main task is not updated until all tasks have been completed, or after more than 30 minutes, the main task information is updated.

[0180] It should be understood that the above examples are merely illustrative and not limiting. Without departing from the core concept of the embodiments of this application, the source of the upgrade task configuration information, the organization of the communication topic, the reporting frequency of the download status message, and the field composition of the upgrade result message can all be adjusted accordingly.

[0181] Figure 3 A schematic diagram of the vehicle remote upgrade device provided in the application embodiment. Figure 3 As shown, the vehicle remote upgrade device 30 in this embodiment may include:

[0182] The receiving module 301 is used to receive remote upgrade instructions, which include the package acquisition address, the type of upgrade object, and verification information.

[0183] The verification module 302 is used to verify the legitimacy of remote upgrade commands based on verification information.

[0184] Download module 303 is used to download the software upgrade package corresponding to the package acquisition address from the object storage service when the verification module 302 passes the verification.

[0185] Upgrade module 304 is used to control the upgrade execution end of the upgrade object type indication and to perform upgrade operations based on the software upgrade package.

[0186] In one feasible implementation, when the upgrade execution end indicated by the upgrade object type is an in-vehicle communication terminal, the upgrade module 304 can be specifically used to: delete the historical software package stored locally; decompress the software upgrade package and deploy the decompressed software data to the local system running directory; record the upgrade information and initiate a restart of the in-vehicle communication terminal; and after restarting, if the upgrade information is detected, send an upgrade success message to the cloud server.

[0187] In one feasible implementation, when the upgrade execution end indicated by the upgrade object type is an electronic control unit, the upgrade module 304 can be specifically used to: send an upgrade preparation command to the electronic control unit and erase the historical software packages in the electronic control unit; transmit the software upgrade package to the electronic control unit; after the transmission is completed, send a reset command to the electronic control unit to make the electronic control unit restart and run the software data of the software upgrade package; and send an upgrade success message to the cloud server.

[0188] The vehicle remote upgrade device in this embodiment can be used to perform... Figure 1 The technical solutions of the method embodiments shown are similar in implementation principle and technical effect, and will not be described again here.

[0189] Figure 4 This is a schematic diagram of the vehicle remote upgrade device provided in an embodiment of this application. Figure 4 As shown, the vehicle remote upgrade device 40 in this embodiment may include:

[0190] The acquisition module 401 is used to acquire upgrade task configuration information, which includes the vehicle identifier of the target vehicle and the corresponding software upgrade package information.

[0191] The generation module 402 is used to generate a remote upgrade instruction based on the upgrade task configuration information. The remote upgrade instruction includes a software package acquisition address, a vehicle identifier, an upgrade object type, and verification information. This enables the target vehicle to verify the legality of the remote upgrade instruction based on the verification information, and to download the software upgrade package corresponding to the software package acquisition address from the object storage service when the legality verification is successful. The module also controls the upgrade execution terminal that indicates the upgrade object type and performs the upgrade operation based on the software upgrade package.

[0192] The sending module 403 is used to send remote upgrade instructions to the communication topic corresponding to the vehicle identifier.

[0193] The update module 404 is used to update the download status of the target vehicle based on the download status message reported by the target vehicle; and to update the upgrade task status of the target vehicle based on the upgrade result message reported by the target vehicle.

[0194] In one feasible implementation, the device may further include a determining module, configured to determine that the execution status of the upgrade task corresponding to the upgrade task configuration information is "fully successful" when the upgrade task status of all target vehicles is "vehicle upgrade successful"; and to determine that the execution status of the upgrade task is "partially successful" when the upgrade task status of any of the target vehicles is "vehicle upgrade failed".

[0195] In one feasible implementation, the acquisition module 401 can also be used to acquire the software upgrade package and store the software upgrade package in the object storage service.

[0196] In one feasible implementation, the determination module can also be used to: if there are still vehicles that have not reported upgrade result messages after a preset time period, determine the execution status of the upgrade task based on the received upgrade result messages.

[0197] The vehicle remote upgrade device in this embodiment can be used to perform... Figure 2 The technical solutions of the method embodiments shown are similar in implementation principle and technical effect, and will not be described again here.

[0198] Figure 5 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Figure 5 As shown, the vehicle provided in this embodiment may include: a memory 502 and a processor 501.

[0199] The memory 502 stores computer-executed instructions; the processor 502 executes the computer-executed instructions stored in the memory 501, causing the processor 501 to execute the method provided above.

[0200] Optionally, the vehicle 50 also includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0201] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0202] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0203] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0204] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0205] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0206] By incorporating a memory and processor within the vehicle, and storing computer execution instructions for remote upgrade processing in the memory, the vehicle gains the ability to locally deploy and automatically execute remote upgrade methods. When executing these methods, the processor can correlate verification information, software package acquisition addresses, and upgrade target types within the remote upgrade instructions. This ensures instruction validity before downloading the corresponding software upgrade package and controlling the upgrade execution terminal matching the upgrade target type to perform the upgrade. This integrates the upgrade of the in-vehicle communication terminal and the upgrade of the in-vehicle target control unit into a unified processing framework, thereby improving the accuracy of upgrade target identification, the correctness of software package acquisition, and the consistency of upgrade execution. Therefore, it enhances the security, reliability, and applicability of the vehicle's remote upgrade process. The vehicle can be an unmanned vehicle, such as an unmanned logistics vehicle, an unmanned cleaning vehicle, or an unmanned patrol vehicle.

[0207] Figure 6 This is a schematic diagram of the structure of a cloud server provided in an embodiment of this application. Figure 6 As shown, the cloud server provided in this embodiment may include at least one processor 601 and a memory 602. Optionally, the device 60 may also include a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0208] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0209] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0210] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0211] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0212] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0213] The cloud server stores computer execution instructions for remote upgrade task management, instruction generation, verification data processing, and software package address association control in its storage. After the processor executes the instructions, the cloud server can support the operation of the aforementioned remote vehicle upgrade method. Through this structure, the cloud server can collaboratively process the verification information, software package acquisition address, and upgrade object type in the remote upgrade instructions, thereby providing the vehicle with reliable upgrade task data. This allows the vehicle to first complete the legality verification after receiving the instruction, then obtain the corresponding software upgrade package, and trigger the corresponding upgrade execution terminal to implement the upgrade according to the upgrade object type. This improves the reliability of instructions, the accuracy of object identification, and the consistency of upgrade execution during the remote upgrade process, thus enhancing the reliability and controllability of remote software maintenance in complex vehicle-to-everything (V2X) environments.

[0214] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0215] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0216] By pre-storing the computer execution instructions used to implement the remote vehicle upgrade method in a computer-readable storage medium, the processor can directly call and execute the corresponding program logic on the in-vehicle communication terminal, upgrade control module, or other in-vehicle electronic devices. This allows for the stable implementation of remote upgrade instruction validity verification, software package address resolution, object storage service download, and upgrade execution control based on upgrade object type in software. This eliminates the need for additional changes to the existing hardware architecture, enabling reuse of the upgrade process. This facilitates unified deployment across multiple vehicle models and batches, and makes the method portable, repeatable, and easy to maintain. Consequently, it improves the implementation efficiency, compatibility, and reliability of the remote upgrade solution, thus helping to ensure the security and consistency of software updates in complex network and multi-object upgrade scenarios.

[0217] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0218] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0219] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0220] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0221] In addition, the functional units in the various embodiments of the present invention 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.

[0222] If a function 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 invention, or the part that contributes to the prior art, or a 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 invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0223] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0224] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for remotely upgrading a vehicle, characterized in that, The method includes: Receive a remote upgrade instruction, the remote upgrade instruction including the software package acquisition address, the upgrade object type, and verification information; Based on the verification information, the legality of the remote upgrade command is verified; If the verification passes, download the software upgrade package corresponding to the software package acquisition address from the object storage service; The upgrade execution terminal, which controls the upgrade object type indication, performs the upgrade operation based on the software upgrade package.

2. The method according to claim 1, characterized in that, When the upgrade execution terminal indicated by the upgrade object type is a vehicle communication terminal, the upgrade operation based on the software upgrade package includes: Delete historical software packages from local storage; Unzip the software upgrade package and deploy the unzipped software data to the local system runtime directory; Record upgrade information and initiate a restart of the vehicle communication terminal; After restarting, if the upgrade information is detected, an upgrade success message is sent to the cloud server.

3. The method according to claim 1, characterized in that, When the upgrade execution terminal indicated by the upgrade object type is an electronic control unit, the upgrade operation based on the software upgrade package includes: Send an upgrade preparation command to the electronic control unit and erase the historical software packages in the electronic control unit; The software upgrade package is transmitted to the electronic control unit; After the transmission is completed, a reset command is sent to the electronic control unit to restart the electronic control unit and run the software data of the software upgrade package; Send an upgrade success message to the cloud server.

4. A method for remotely upgrading a vehicle, characterized in that, The method includes: Obtain upgrade task configuration information, which includes the vehicle identifier of the target vehicle and the corresponding software upgrade package information; A remote upgrade instruction is generated based on the upgrade task configuration information. The remote upgrade instruction includes a software package acquisition address, the vehicle identifier, the upgrade object type, and verification information. This enables the target vehicle to verify the legality of the remote upgrade instruction based on the verification information, and to download the software upgrade package corresponding to the software package acquisition address from the object storage service when the legality verification is successful. It also controls the upgrade execution terminal indicated by the upgrade object type to perform the upgrade operation based on the software upgrade package. Send the remote upgrade command to the communication topic corresponding to the vehicle identifier; Update the download status of the target vehicle based on the download status message reported by the target vehicle; Based on the upgrade result message reported by the target vehicle, update the upgrade task status of the target vehicle.

5. The method according to claim 4, characterized in that, After updating the upgrade task status of the corresponding vehicle based on the upgrade result message, the method further includes: When the upgrade task status of all target vehicles is "vehicle upgrade successful", the execution status of the upgrade task corresponding to the upgrade task configuration information is determined to be "all successful". When the upgrade task status of any of the target vehicles is "vehicle upgrade failed", the execution status of the upgrade task is determined to be "partially successful".

6. The method according to claim 4, characterized in that, Before obtaining the upgrade task configuration information, the method further includes: Obtain the software upgrade package; The software upgrade package is stored in an object storage service.

7. The method according to claim 5, characterized in that, The method further includes: If there are still vehicles that have not reported the upgrade result message after the preset time period, the execution status of the upgrade task is determined based on the received upgrade result messages.

8. A vehicle, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-3.

9. A cloud server, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 4-7.

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

Images