Method and device for controlling vehicle upgrading, vehicle and storage medium

Abstract

The invention provides a method and device for controlling vehicle upgrading, a vehicle and a storage medium, the method is applied to the technical field of vehicle system upgrading control, and the method comprises the following steps: under the condition that system upgrading of the vehicle is completed, obtaining a local configuration state of the vehicle for a virus detection function and a configuration instruction of a cloud for the virus detection function, the vehicle completing the system upgrading comprises a running code of a virus detection function, and the cloud is in communication connection with the vehicle; determining a target running state of the virus detection function according to the local configuration state or the local configuration state and the configuration instruction; and controlling the virus detection function to operate according to the target operation state. According to the method, the state of the virus detection function can be flexibly configured through combination of local configuration and cloud instructions, so that the state of the virus detection function can be differentially adapted among different vehicles, and flexible scheduling of the virus detection function is realized.

Description

Technical Field

[0001] This application relates to the field of vehicle system upgrade control technology, and more specifically, to a method, apparatus, vehicle, and storage medium for controlling vehicle upgrades within the field of vehicle system upgrade control technology. Background Technology

[0002] In the automotive field, with the development of vehicle intelligence, vehicles need to undergo comprehensive system upgrades every so often.

[0003] Currently, the purpose of vehicle system upgrades is to fix discovered system vulnerabilities, optimize the overall performance of the vehicle's infotainment system, and add new basic operating modules. It is not possible to make targeted upgrades and adjustments for different vehicle models.

[0004] For example, older vehicles with weaker hardware may experience system lag if security features like virus detection are enabled; while newer or newer vehicles with stronger hardware and more connectivity features require real-time virus detection for security protection.

[0005] Therefore, how to provide an on-demand vehicle upgrade solution has become an urgent problem to be solved. Summary of the Invention

[0006] This application provides a method, apparatus, vehicle, and storage medium for controlling vehicle upgrades. The method can flexibly configure the status of the virus detection function by combining local configuration and cloud commands, so that the status of the virus detection function can be adapted differently between different vehicles, and the virus detection function can be flexibly scheduled.

[0007] In a first aspect, a method for controlling vehicle upgrades is provided, the method comprising: when a vehicle has completed a system upgrade, obtaining the local configuration status of the virus detection function of the vehicle and the configuration instructions of the virus detection function in the cloud, wherein the upgraded vehicle contains the running code of the virus detection function, and the cloud and the vehicle are connected in communication; determining the target running state of the virus detection function based on the local configuration status, or the local configuration status and the configuration instructions; and controlling the operation of the virus detection function based on the target running state.

[0008] In the above technical solution, this application proposes a method for controlling vehicle upgrades. During implementation, after the vehicle completes a system upgrade, the vehicle obtains the local configuration status of the virus detection function and the cloud-based configuration instructions for the virus detection function. Based on the local configuration status and the configuration instructions, the target operating state of the virus detection function is determined. Finally, the virus detection function is controlled to operate based on the target operating state. This method, combining local configuration and cloud instructions, flexibly configures the state of the virus detection function, allowing for differentiated adaptation between different vehicles. This enables personalized control of the virus detection function across different vehicles and achieves flexible scheduling of the virus detection function.

[0009] In conjunction with the first aspect, in some possible implementations, determining the target operating state of the virus detection function based on the local configuration state, or the local configuration state and the configuration instruction, includes: determining the target operating state based on the configuration instruction when the local configuration state is enabled; and determining the target operating state as disabled when the local configuration state is disabled.

[0010] In the above technical solution, when the local configuration is off, the vehicle directly determines the target operating state of the virus detection function as off, avoiding forced intervention from cloud commands and the resource consumption associated with processing cloud commands. When the local configuration is on, the vehicle uses cloud configuration commands for scheduling, which takes into account temporary adjustments to the operating state of the virus detection function for certain vehicle models by the cloud. This ensures that enabling the virus detection function meets user needs while remaining within the authorized scope of the cloud, making the determination of the virus detection function's operating state more accurate.

[0011] In combination with the first aspect and the above implementation methods, in some possible implementation methods, when the local configuration state is enabled, the target running state is determined according to the configuration instruction, including: if the configuration instruction is an enable instruction, the target running state is determined to be enabled; if the configuration instruction is a disable instruction, the target running state is determined to be disabled.

[0012] In the above technical solution, when the local configuration status is enabled, the vehicle can make up for the deficiency that the local configuration cannot be remotely adjusted in batches by further determining the configuration instructions in the cloud, and reduce the risk of system failure caused by the conflicting operation status of the virus detection function when the vehicle's local permissions and cloud permissions are inconsistent.

[0013] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: when the local configuration state is enabled, preloading the running code of the virus detection function into memory so that the virus detection function is in a waiting-to-be-enabled state.

[0014] In the above technical solution, when the vehicle determines that the local configuration is enabled, the virus detection function's runtime code is pre-loaded into memory, putting the virus detection function in a state of waiting to be enabled. This eliminates the need to read and load the code from memory after receiving the cloud-based startup command, thus shortening the loading latency of the virus detection function. Furthermore, this pre-loading of runtime code can detect runtime code reading failures in advance, preventing loading failures after receiving the cloud-based activation command and improving the reliability of the virus detection function.

[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, controlling the operation of the virus detection function according to the target running state includes: when the target running state is enabled, controlling the running code of the virus detection function to start running to start the virus detection function; when the target running state is disabled, if the running code of the virus detection function has not been loaded into memory, controlling the virus detection function to remain disabled; when the target running state is disabled, if the running code of the virus detection function has been loaded into memory, clearing the running code of the virus detection function in memory to disable the virus detection function.

[0016] In the above technical solution, when the target operating state is "on," the vehicle directly triggers the pre-loaded virus detection function's execution code, eliminating the need for repeated loading processes while maintaining the virus detection function's response speed. When the target operating state is "off" and the virus detection function's execution code is not loaded into memory, no operation is performed to keep the virus detection function off, reducing system computational redundancy. When the target operating state is "off" and the virus detection function's execution code is loaded into memory, the vehicle can release the memory and processing resources occupied by the execution code by clearing it from memory, ensuring the smooth operation of other functions in the vehicle and avoiding system lag and operational delays.

[0017] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: determining the local configuration state in response to a configuration operation of the virus detection function; or, obtaining the vehicle's configuration parameters based on the vehicle model, the configuration parameters being used to represent the configuration state of the vehicle's infotainment system performance; and determining the local configuration state based on the configuration parameters.

[0018] In the above technical solution, after the vehicle completes the system upgrade, this application provides users with a manual configuration method based on the local configuration status, granting users control over functions and avoiding a degraded user experience due to forced system adaptation ignoring user preferences. Furthermore, the vehicle automatically determines its local configuration status by obtaining configuration parameters based on its model, complementing the manual configuration method. This reduces operational errors caused by user unfamiliarity with configuration logic and lowers vehicle maintenance costs. Therefore, when determining the local configuration status through these two methods, the process achieves both flexibility and accuracy.

[0019] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: generating a local configuration file based on the configuration instruction, the vehicle's in-vehicle system version identifier, the vehicle's identifier, and the vehicle model; determining whether an update prompt for the configuration instruction has been received upon the next vehicle startup; determining the configuration instruction through the local configuration file if no update prompt for the configuration instruction has been received; and obtaining the updated configuration instruction and updating the local configuration file based on the updated configuration instruction if an update prompt for the configuration instruction has been received.

[0020] In the above technical solution, in addition to determining the target operating status of the virus detection function based on configuration instructions and local configuration status, the vehicle can also generate a local configuration file based on configuration instructions and basic vehicle information. When the vehicle starts up again, if the configuration instructions in the cloud have not been updated, the vehicle will prioritize reading the local configuration file to determine the configuration instructions, without waiting for communication with the cloud, thus reducing the configuration waiting time after the vehicle system starts. If the configuration instructions in the cloud are updated, the vehicle will trigger an update to the local configuration file through an update prompt message, ensuring that the local configuration file is synchronized with the latest configuration instructions and guaranteeing the accuracy of the virus detection function's operating status determination.

[0021] Secondly, an apparatus for controlling vehicle upgrades is provided. The apparatus includes: an acquisition module, configured to acquire, upon completion of a system upgrade, the local configuration status of the vehicle for a virus detection function and the cloud-based configuration instructions for the virus detection function, wherein the upgraded vehicle contains the running code for the virus detection function, and the cloud and the vehicle are connected in communication; a determination module, configured to determine the target operating state of the virus detection function based on the local configuration status, or the local configuration status and the configuration instructions; and a control module, configured to control the operation of the virus detection function based on the target operating state.

[0022] In conjunction with the second aspect, in some possible implementations, the determining module is specifically used to: determine the target running state according to the configuration instruction when the local configuration state is enabled; and determine the target running state as disabled when the local configuration state is disabled.

[0023] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: if the configuration instruction is an enable instruction, determine that the target running state is enabled; if the configuration instruction is a disable instruction, determine that the target running state is disabled.

[0024] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is also used to: preload the running code of the virus detection function into memory when the local configuration state is enabled, so that the virus detection function is in a waiting-to-be-enabled state.

[0025] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the control module is specifically used to: when the target running state is enabled, control the execution code of the virus detection function to start running to start the virus detection function; when the target running state is disabled, if the execution code of the virus detection function has not been loaded into memory, control the virus detection function to remain disabled; when the target running state is disabled, if the execution code of the virus detection function has been loaded into memory, clear the execution code of the virus detection function in memory to disable the virus detection function.

[0026] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the acquisition module is specifically used to: determine the local configuration status in response to the configuration operation of the virus detection function; or, based on the vehicle model, acquire the vehicle's configuration parameters, which are used to represent the configuration status of the vehicle's infotainment system performance; and determine the local configuration status based on the configuration parameters.

[0027] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: generate a local configuration file based on the configuration instruction, the vehicle's in-vehicle system version identifier, the vehicle's identifier, and the vehicle model; determine whether an update prompt for the configuration instruction has been received upon the next vehicle startup; if no update prompt for the configuration instruction has been received, determine the configuration instruction through the local configuration file; and if an update prompt for the configuration instruction has been received, obtain the updated configuration instruction and update the local configuration file based on the updated configuration instruction.

[0028] Thirdly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof.

[0029] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0030] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating a vehicle system upgrade scenario provided in an embodiment of this application; Figure 2 This is a schematic flowchart illustrating a method for controlling vehicle upgrades provided in an embodiment of this application; Figure 3 This is an interactive flowchart of a method for controlling vehicle upgrades provided in an embodiment of this application; Figure 4 This is a schematic diagram of a device for controlling vehicle upgrades provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0032] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0033] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0034] Before introducing the solutions of the embodiments of this application, the following is a definition of the technical terms that may be involved in the embodiments of this application.

[0035] Over-the-Air (OTA) upgrades refer to the technology of remotely upgrading, repairing, and optimizing a vehicle's software system, electronic control unit (ECU), and vehicle functions via wireless communication networks.

[0036] In-store upgrade: This refers to an offline system upgrade method where the vehicle must be taken to an authorized 4S store or service center by the car manufacturer, and professional technicians use specialized diagnostic equipment to complete the upgrade. It is the opposite of the vehicle OTA upgrade.

[0037] Systematic version iteration: This refers to a model that upgrades the vehicle system in a unified manner with an overall version update as the core. The upgrade goal of this model is to cover the common needs of the entire system, rather than the personalized needs of different users.

[0038] After explaining the technical terms of the embodiments of this application, the application scenarios of the embodiments of this application are described below.

[0039] It should be understood that the application scenario of this application involves vehicle system upgrades. Currently, there are two common vehicle system upgrade methods on the market: OTA upgrades and in-station upgrades. Regardless of whether the vehicle is upgraded via OTA or in-station upgrades, the upgrade content includes, but is not limited to, upgrades to the vehicle infotainment system software version and upgrades to core ECU and other functional module software.

[0040] To facilitate a better understanding of the application scenarios of the embodiments of this application, the following will first demonstrate... Figure 1 The specific processes of OAT upgrade and on-site upgrade are described separately.

[0041] Figure 1 This is a schematic diagram of a vehicle system upgrade scenario provided in an embodiment of this application.

[0042] For example, such as Figure 1 As shown in (a) in the diagram, this is a schematic diagram of a scenario where vehicle 101 is upgraded via OTA. When vehicle 101 is upgraded via OTA, it specifically involves the interaction between vehicle 101 and cloud 102.

[0043] The complete process of vehicle 101 undergoing OTA upgrade can be divided into four stages: cloud 102 preparation, interaction between vehicle 101 and cloud 102, vehicle 101 executing the OTA upgrade, and result feedback. The following is a detailed explanation of these four stages.

[0044] Phase 1: Cloud 102 preparation.

[0045] This stage is the pre-OTA upgrade process, which is completed by the car manufacturer's technical personnel through configuration and does not involve interaction with the vehicle.

[0046] Specifically, technicians develop upgrade packages for specific vehicle models or ECUs, which include new function codes, vulnerability patches, etc., and digitally sign and encrypt the upgrade packages to prevent them from being tampered with during transmission.

[0047] Furthermore, technicians create upgrade tasks in the OTA management platform of Cloud 102, configuring the target vehicles to be upgraded (e.g., filtered by vehicle model or series), upgrade time (e.g., immediate push or scheduled push), and upgrade conditions (e.g., vehicle 101 must be stationary).

[0048] Phase 2: Vehicle 101 interacts with the cloud 102.

[0049] Vehicle 101 establishes secure communication with cloud 102 through a telematics-box (T-box), and the T-box automatically reports vehicle information to cloud 102. Vehicle information includes, for example, the vehicle identification number (VIN) of vehicle 101, the current software version, and the ECU hardware version.

[0050] Cloud 102 compares the current version of vehicle 101 with the upgrade package version to determine whether vehicle 101 needs an update. If cloud 102 determines that vehicle 101 needs an update, it pushes an upgrade notification to vehicle 101, which includes upgrade task instructions and an upgrade package download address.

[0051] After receiving the upgrade notification, vehicle 101 will display the notification to the user via a pop-up window or a message in a mobile application (App) to await the user's confirmation of acceptance. Once the user confirms acceptance, vehicle 101 will send a task reception signal to cloud 102.

[0052] Cloud 102 transmits the upgrade package to vehicle 101 through an encrypted channel. Vehicle 101 downloads the upgrade package to local storage and verifies it, and reports the download progress of the upgrade package to cloud 102 in real time.

[0053] Phase 3: Vehicle 101 performs OTA upgrade.

[0054] After downloading the upgrade package, Vehicle 101 can perform a self-check to see if it meets the upgrade requirements. If the requirements are met, Vehicle 101 backs up the current software version to a redundant partition for rollback in case of upgrade failure. Next, Vehicle 101 flashes the upgrade package to the target ECU (such as the powertrain domain or vehicle infotainment system). During the upgrade installation process, Vehicle 101 reports the progress to Cloud 102 in real time.

[0055] After installation, vehicle 101 restarts the relevant ECUs or systems to verify whether the new software version is running correctly. If the new software version is running correctly, vehicle 101 reports the upgrade completion to cloud 102.

[0056] Phase 4: Results Feedback and Log Recording.

[0057] The entire upgrade process log for Cloud 102 storage (including download time, installation results, and error information) will be used for subsequent analysis. Simultaneously, Vehicle 101 will push a successful upgrade notification to the user, along with a prompt to view the new version's feature description.

[0058] like Figure 1 As shown in (b), this is a schematic diagram of the vehicle 101 entering the station for upgrades. Since station upgrades are a manual, offline upgrade mode, relying on specialized equipment and technicians, they generally consist of the following steps: Step 1: Vehicle 101 arrives at the store for registration.

[0059] The user drives vehicle 101 to 4S store 103, where the service advisor registers vehicle information such as VIN code, current system version, and upgrade requirements.

[0060] Step 2: Vehicle pre-inspection.

[0061] The technicians drove vehicle 101 to the repair bay, connected professional diagnostic equipment, read the current ECU version and fault codes of vehicle 101, and confirmed the vehicle's status to avoid any abnormalities during the upgrade process.

[0062] Step 3: Prepare the upgrade package.

[0063] Technicians connect to the automaker's internal server using diagnostic equipment to download the official upgrade package for the corresponding vehicle model / ECU. If the upgrade package is pre-installed on the diagnostic equipment, it can be used directly.

[0064] Step 4: Perform the upgrade operation.

[0065] Technicians transmit the upgrade package to the ECU / in-vehicle infotainment system of vehicle 101 via diagnostic equipment and perform the flashing operation. During the upgrade process, technicians monitor the progress indicators on the diagnostic equipment in real time, and manually perform a rollback operation if any abnormality occurs.

[0066] Step 5: Verify after upgrade.

[0067] After the upgrade of vehicle 101 is completed, the technician restarts the vehicle system, reads the new software version through diagnostic equipment, verifies whether the functions are normal, and clears the temporary fault codes generated during the upgrade process to ensure that vehicle 101 is in a normal state.

[0068] Step 6: Vehicle handover confirmation.

[0069] The technicians returned vehicle 101 to the service advisor, who explained the upgrade details to the user. After confirming that vehicle 101 was functioning normally, the user signed for and took possession of the vehicle.

[0070] After introducing the specific processes of OTA upgrades and in-site upgrades, the application scenarios of this application embodiment are described below.

[0071] In the automotive field, with the advancement of vehicle intelligence, in-vehicle infotainment systems have transitioned from closed systems to open platforms, supporting third-party application integration, personalized function customization, and deep connectivity with mobile devices. While this transformation provides users with a richer driving experience, it also exposes vehicles to various cyber threats. Therefore, regularly upgrading vehicle systems has become essential to ensuring vehicle safety and a positive user experience.

[0072] The two main methods for vehicle upgrades are OTA (Over-The-Air) upgrades and on-site upgrades. Regardless of the method, current vehicle upgrades are essentially systemic version iterations, with the core objective focused solely on fixing discovered system vulnerabilities, optimizing the overall performance of the vehicle's infotainment system, and adding basic operating modules. They cannot provide targeted upgrades and adjustments for different vehicle models and lack the ability to select modules and load them on demand.

[0073] For example, in older vehicles with weaker hardware, forcibly enabling security features like virus detection can easily cause the vehicle's infotainment system to lag, impacting the basic user experience. In contrast, for new energy vehicles or newer models with powerful hardware and extensive connectivity features, users have a strong demand for real-time intrusion detection, data encryption, and other security protections, making continuous virus detection functionality essential.

[0074] In the vehicle infotainment system, the virus detection function is a security protection function for the vehicle's local storage, network communication data, and running processes. Its core is to identify and block malicious programs, viruses, Trojans, and illegal intrusion attempts targeting the vehicle infotainment system.

[0075] The virus detection function works by scanning files in the vehicle's flash memory, running application processes, and data packets transmitted over the network in real time or on demand, based on a preset virus signature database. This identifies whether malicious programs exist within the vehicle's system, such as Trojans that steal vehicle data or viruses that tamper with vehicle information. When a malicious program is detected in the vehicle's system, preset protective actions are triggered, a security log is recorded, and the incident is reported to the vehicle or the cloud.

[0076] Given the varying operational requirements of virus detection functions across different vehicles, the industry urgently needs to address the challenge of overcoming the limitations of traditional upgrade models and providing an on-demand vehicle upgrade solution that can adapt to different vehicle models and meet users' personalized needs for virus detection functions.

[0077] In view of this, this application proposes a method for controlling vehicle upgrades. This method can flexibly configure the state of the virus detection function by combining local configuration and cloud commands, so that the state of the virus detection function can be adapted differently between different vehicles, and the virus detection function can be flexibly scheduled.

[0078] The following is through Figure 2 This application provides a detailed description of a method for controlling vehicle upgrades based on embodiments.

[0079] Figure 2 This is a schematic flowchart illustrating a method for controlling vehicle upgrades provided in an embodiment of this application. It should be understood that this method is applied to... Figure 1 The vehicle 101 in the application is specifically applied to any ECU in the vehicle 101, such as the in-vehicle infotainment (IVI) system in the vehicle 101. This application embodiment does not limit this.

[0080] For example, such as Figure 2 As shown, the method 200 includes the following steps 201 to 203.

[0081] Step 201: After the vehicle has completed the system upgrade, obtain the local configuration status of the virus detection function in the vehicle and the configuration instructions of the virus detection function in the cloud. The vehicle that has completed the system upgrade contains the running code of the virus detection function, and the communication connection between the cloud and the vehicle is established.

[0082] It should be understood that the core of the vehicle upgrade control method provided in this application embodiment lies in the fact that after the vehicle completes the system upgrade, for the virus detection function, the vehicle can flexibly determine the operating status of the virus detection function based on the local configuration status and the configuration instructions in the cloud. Therefore, in this application embodiment, the vehicle that has completed the system upgrade includes the running code for the virus detection function.

[0083] Among them, the cloud is Figure 1 The cloud 102 in the context is typically the vehicle's Telematics Service Provider (TSP), which communicates with the vehicle and transmits data through the vehicle's T-box.

[0084] Here, the connection and difference between the running code and the running state of the virus detection function lies in the following: The running code of the virus detection function is the core software program that implements the virus detection function. It is implanted into the storage unit of the vehicle system, such as the vehicle's flash memory, during OTA or on-site upgrades. It is the foundation for the existence of the virus detection function; regardless of whether the virus detection function is enabled or not, the running code is already embedded in the vehicle system and will not disappear. The virus detection function itself is the dynamic execution state of the aforementioned running code. The same set of code can switch between different execution states depending on the running state of the virus detection function.

[0085] The local configuration status, also known as the local configuration identifier, refers to the configuration attributes stored locally on the vehicle. It records the basic permissions, such as user configuration or system presets, for allowing virus detection. Cloud-based configuration commands are instructions sent from the cloud to the vehicle via the communication network to constrain the local configuration status. Optionally, the local configuration status includes on and off states, and the configuration commands include enable and disable commands.

[0086] For example, in some older vehicles, if a user mistakenly sets the local configuration to "enabled" after an upgrade, but these vehicles may not support or meet the resource requirements for virus detection to run, then if the cloud-based configuration command is a "disable" command, the virus detection function in the vehicle will not be enabled even if the local configuration is enabled.

[0087] Therefore, this application, through the dual protection of local configuration status and cloud configuration commands, can more accurately control or adjust the operating status of the virus detection function.

[0088] The local configuration status can be determined either by the user or automatically by the vehicle. Similarly, configuration commands can be configured by cloud-based technical personnel or automatically determined by the cloud.

[0089] Before introducing the process of obtaining local configuration status and configuration commands, the configuration process of local configuration status and configuration commands will be introduced separately below.

[0090] One possible implementation method also includes: In response to configuration operations related to virus detection functionality, determine the local configuration status; or... Based on the vehicle model, obtain the vehicle's configuration parameters, which are used to indicate the configuration status of the vehicle's infotainment system. Determine the local configuration status based on the configuration parameters.

[0091] Specifically, this application provides two configuration methods for local configuration status: manual and automatic. The manual method refers to configuration performed manually by the user, while the automatic method is determined automatically by the vehicle.

[0092] When configured in manual mode, upon detecting a completed system upgrade, the vehicle can display a configuration interface on the central control screen showing the local configuration status of the virus detection function. This interface includes "On" and "Off" options. Based on this interface, users can select the corresponding configuration option according to their needs through configuration operations (e.g., voice commands, clicks), and the vehicle responds to the user's configuration actions to confirm the local configuration status.

[0093] When the configuration mode is set to automatic, there is usually a correspondence between the vehicle model and the configuration parameters. These configuration parameters represent the configuration status of the vehicle's infotainment system, including, for example, the number of processor cores, memory space, storage space, and network connectivity features.

[0094] Once the vehicle system upgrade is detected, the vehicle can obtain its configuration parameters based on its current model, and then assess whether the vehicle system supports the operation of the virus detection function based on the configuration parameters, thereby determining the local configuration status.

[0095] Specifically, if the upgraded vehicle has a pre-defined rule for determining the local configuration status based on configuration parameters, the vehicle will automatically read the vehicle model code to obtain the configuration parameters and determine the local configuration status.

[0096] For example, if the vehicle is a new energy vehicle model from 2025, the vehicle's configuration parameters could be an 8-core processor, 8GB of RAM, 128GB of storage, and 5G connectivity. The vehicle will then determine that the current configuration parameters meet the operational requirements of the virus detection function and automatically set the local configuration status to enabled.

[0097] In another example, if the vehicle is a 2015 model, an older gasoline-powered vehicle, its configuration parameters are: a 2-core processor for the vehicle's infotainment system, 1GB of RAM, 16GB of storage, and no internet connectivity or only 2G connectivity. The vehicle will then determine that the current configuration parameters do not meet the operational requirements of the virus detection function and automatically disable the local configuration.

[0098] Furthermore, the manual and automatic modes described above can be combined. For example, in some older vehicle models, after a system upgrade, the user might mistakenly configure the local settings to be enabled, but the vehicle may not actually support virus detection. In this case, the vehicle can correct the local settings through configuration parameters.

[0099] Specifically, when the local configuration state determined by the vehicle based on configuration operations is the same as the local configuration state determined by the vehicle based on configuration parameters, then either of these local configuration states is determined as the local configuration state in this embodiment. When the local configuration state determined by the vehicle based on configuration operations is different from the local configuration state determined by the vehicle based on configuration parameters, then the local configuration state determined based on configuration parameters is determined as the local configuration state in this embodiment.

[0100] In the above technical solution, after the vehicle completes the system upgrade, this application provides users with a manual configuration method based on the local configuration status, granting users control over functions and avoiding a degraded user experience due to forced system adaptation ignoring user preferences. Furthermore, the vehicle automatically determines its local configuration status by obtaining configuration parameters based on its model, complementing the manual configuration method. This reduces operational errors caused by user unfamiliarity with configuration logic and lowers vehicle maintenance costs. Therefore, when determining the local configuration status through these two methods, the process achieves both flexibility and accuracy.

[0101] Similarly, cloud-based configuration commands can be manually configured by cloud-based technical personnel or automatically determined by the cloud based on configuration parameters.

[0102] Specifically, technicians can log into the cloud-based vehicle upgrade management platform, filter by vehicle model, series, and VIN code, and select the type of vehicle to be configured. They then select the command type as enable or disable to complete the configuration process.

[0103] Furthermore, the process by which the cloud automatically determines configuration commands based on configuration parameters involves storing the correspondence between configuration parameters and configuration commands. When the vehicle upgrade is complete, upon receiving upgrade completion feedback, the cloud can obtain the vehicle's VIN code, determine the vehicle model based on the VIN code, and further determine the vehicle's configuration parameters. Through the correspondence between configuration parameters and configuration commands, the vehicle's configuration commands are determined.

[0104] Based on the configuration process described above, the vehicle can determine its local configuration status by obtaining the status flag of the local configuration status.

[0105] Specifically, in this embodiment, a status flag bit for the local configuration status can be set, and this status flag bit corresponds to different values ​​depending on the local configuration status. For example, the status flag bit can take the values ​​0 and 1. When the local configuration status is enabled, the status flag bit takes the value 1; when the local configuration status is disabled, the status flag bit takes the value 0. Based on this, the vehicle can determine the local configuration status by the value of the status flag bit.

[0106] To obtain configuration commands, the vehicle can send a configuration command retrieval command to the cloud via the T-box, so that the cloud responds to the retrieval command and issues configuration commands to the vehicle.

[0107] Step 202: Determine the target operating status of the virus detection function based on the local configuration status, or the local configuration status and configuration instructions.

[0108] After obtaining the local configuration status and configuration instructions in step 201, the vehicle can determine the target operating status of the virus detection function based on these two parameters. The specific process for determining the target operating status varies depending on the local configuration status and configuration instructions.

[0109] One possible implementation involves determining the target operational state of the virus detection function based on the local configuration state, or the local configuration state and configuration instructions, including: When the local configuration status is enabled, the target running status is determined according to the configuration instructions; If the local configuration status is off, the target running status is determined to be off.

[0110] In one scenario, when the local configuration status is off, following the configuration process described above, it indicates that the current user's intention is to disable the virus detection function, or that the cloud determines that the vehicle's infotainment system performance is insufficient to support the operation of the virus detection function. In this case, the vehicle does not need to further consider the cloud's configuration instructions and can directly determine that the virus detection function needs to be disabled to ensure the basic operation of the vehicle.

[0111] In another scenario, when the local configuration status is enabled, it indicates that the current user's intention is to enable the virus detection function, or the cloud determines that the vehicle's infotainment system performance is sufficient to support the virus detection function. In this case, the vehicle needs to further parse the cloud's configuration instructions to determine the target operating status of the virus detection function, in order to take into account the cloud's dynamic temporary adjustment strategy, such as the cloud temporarily disabling the virus detection function for a certain batch of vehicle models for a certain period of time.

[0112] In the above technical solution, when the local configuration is off, the vehicle directly determines the target operating state of the virus detection function as off, avoiding forced intervention from cloud commands and the resource consumption associated with processing cloud commands. When the local configuration is on, the vehicle uses cloud configuration commands for scheduling, which takes into account temporary adjustments to the operating state of the virus detection function for certain vehicle models by the cloud. This ensures that enabling the virus detection function meets user needs while remaining within the authorized scope of the cloud, making the determination of the virus detection function's operating state more accurate.

[0113] The process of determining the target's running status based on the configuration instructions is as follows.

[0114] In one possible implementation, when the local configuration is enabled, the target running status is determined according to the configuration instructions, including: If the configuration command is an enable command, the target running status is determined to be enabled; If the configuration command is a disable command, the target running status is determined to be off.

[0115] Specifically, when the configuration command from the cloud is an enable command, it means that the cloud's configuration permission for the virus detection function is also enabled. When the local configuration status is enabled and the cloud's configuration command is an enable command, it means that the vehicle's running permission for the virus detection function and the cloud's running permission for the virus detection function are consistent, and the vehicle determines that the target running status of the virus detection function is enabled.

[0116] Conversely, when the cloud-based configuration command is a disable command, it indicates that the cloud has closed the configuration permissions for the virus detection function. When the local configuration status is enabled and the cloud-based configuration command is a disable command, it means that the vehicle's and the cloud's permissions for the virus detection function are different. In this case, the cloud-based configuration command has higher priority than the vehicle's local configuration status, and the vehicle determines that the target operating status for the virus detection function is disabled.

[0117] In the above technical solution, when the local configuration status is enabled, the vehicle can make up for the deficiency that the local configuration cannot be remotely adjusted in batches by further determining the configuration instructions in the cloud, and reduce the risk of system failure caused by the conflicting operation status of the virus detection function when the vehicle's local permissions and cloud permissions are inconsistent.

[0118] Furthermore, since the code for virus detection is located on the vehicle side, this application embodiment also provides a method for achieving rapid response of virus detection function.

[0119] One possible implementation method also includes: When the local configuration is enabled, the code for running the virus detection function is preloaded into memory so that the virus detection function is in a state of waiting to be enabled.

[0120] Specifically, when the local configuration is enabled, the vehicle can preload the virus detection function's runtime code into memory, switching the virus detection function from a disabled state to a pending state (i.e., waiting to be enabled). Since the vehicle hasn't yet determined whether the configuration command is a disable or enable command, the virus detection function's runtime code doesn't perform detection tasks; it doesn't actively initiate virus scanning, threat identification, or other virus detection-related system tasks. It only occupies a small amount of memory and doesn't consume the central processing unit's (CPU) computing power. Therefore, this preloaded runtime code allows the vehicle to activate the virus detection function within milliseconds after determining that the configuration command from the cloud is an enable command.

[0121] In the above technical solution, when the vehicle determines that the local configuration is enabled, the virus detection function's runtime code is pre-loaded into memory, putting the virus detection function in a state of waiting to be enabled. This eliminates the need to read and load the code from memory after receiving the cloud-based startup command, thus shortening the loading latency of the virus detection function. Furthermore, this pre-loading of runtime code can detect runtime code reading failures in advance, preventing loading failures after receiving the cloud-based activation command and improving the reliability of the virus detection function.

[0122] Step 203: Control the virus detection function to run according to the target running status.

[0123] After determining the target operating state of the virus detection function through step 202, the vehicle can control the operation of the virus detection function based on the target operating state.

[0124] Depending on whether the target operating status is on or off, the specific operation control process of the vehicle's virus detection function is as follows.

[0125] One possible implementation involves controlling the virus detection function based on the target's operating state, including: When the target is running in the enabled state, the code that controls the virus detection function starts running to initiate the virus detection function; If the virus detection function's runtime code is not loaded into memory when the target is in a disabled state, the virus detection function will remain disabled. If the virus detection function's runtime code has been loaded into memory when the target is in a disabled state, clear the virus detection function's runtime code from memory to disable the virus detection function.

[0126] In one scenario, when the target operating state is "enabled," the conditions for this, as described above, are: the local configuration is enabled, and the cloud-based configuration command is an enable command. When the local configuration is enabled, the vehicle has already pre-loaded the virus detection function's runtime code into memory. Therefore, when the cloud-based configuration command is an enable command, and the vehicle determines that the target operating state of the virus detection function is enabled, it sends an execution command to the runtime code of the virus detection function in memory to start its execution. After the runtime code starts running, it triggers the detection process, such as calling the virus scanning engine, reading vehicle system files or network data, comparing virus databases, and identifying potential threat behaviors in the vehicle—all substantive detection operations related to virus detection. In this case, only the substantive detection operations performed by the virus detection function during the execution of the runtime code consume CPU computing power.

[0127] In another scenario, when the target is in a closed state, there are two scenarios: the first scenario is that the local configuration is in a closed state; the second scenario is that the local configuration is in an open state, and the cloud configuration command is closed.

[0128] When the target's running status is off, it corresponds to the first scenario above. In this case, since the virus detection function's running code is not loaded into memory, the virus detection function is always off. The vehicle only needs to continue to keep the virus detection function off.

[0129] When the target's running state is off, it corresponds to the second scenario above. In this case, since the virus detection function's running code has already been pre-loaded into memory, meaning the virus detection function is in a waiting-to-be-enabled state, while the cloud-based configuration command is a disable command, the vehicle needs to control the virus detection function to switch from the waiting-to-be-enabled state to the off state. At this time, the vehicle will locate the storage address of the virus detection function's running code in memory (e.g., the memory block where the running code is pre-loaded), clear all the running code in that memory block, and mark that memory block as available so that the running code for other functions in the vehicle's infotainment system can be pre-loaded.

[0130] It should be understood that the aforementioned pre-loading of the virus detection function's runtime code into memory can be understood as a copy of the virus detection function's runtime code, while the runtime code of the virus detection function in the vehicle's storage unit (e.g., the vehicle's flash memory) can be understood as the original runtime code. When the vehicle clears the virus detection function's runtime code from memory, only the copy of the runtime code is cleared, while the original runtime code stored in the vehicle's flash memory still exists and can be reloaded into memory when the virus detection function needs to be activated subsequently.

[0131] Once the running code of the virus detection module in memory is cleared, the running state of the virus detection function switches from waiting to be enabled to being disabled.

[0132] In the above technical solution, when the target operating state is "on," the vehicle directly triggers the pre-loaded virus detection function's execution code, eliminating the need for repeated loading processes while maintaining the virus detection function's response speed. When the target operating state is "off" and the virus detection function's execution code is not loaded into memory, no operation is performed to keep the virus detection function off, reducing system computational redundancy. When the target operating state is "off" and the virus detection function's execution code is loaded into memory, the vehicle can clear the execution code from memory, releasing the memory and CPU resources occupied by that execution code, ensuring the smooth operation of other functions in the vehicle and avoiding system lag and operational delays.

[0133] In addition, in this embodiment of the application, the vehicle can also generate a local configuration file based on cloud configuration instructions, so that the vehicle can directly obtain the cloud configuration instructions locally without having to send the acquisition instructions to the cloud again.

[0134] One possible implementation method also includes: Generate a local configuration file based on the configuration instructions, the vehicle's infotainment system version identifier, the vehicle's identifier, and the vehicle model; Upon the next vehicle startup, determine whether an update notification message for the configuration instruction has been received; If no update prompt message for configuration instructions is received, determine the configuration instructions through the local configuration file; Upon receiving an update prompt message for the configuration command, obtain the updated configuration command and update the local configuration file based on the updated configuration command.

[0135] It should be understood that after a vehicle system upgrade, the vehicle's infotainment system will restart every time the vehicle is started. At least one of the following—the local configuration status or the cloud-based configuration instructions—may change between the current start and the previous start. Therefore, the vehicle needs to re-determine whether to activate the virus detection function after each startup.

[0136] To facilitate the vehicle's rapid recognition of cloud commands, after the vehicle completes a system upgrade and starts up for the first time to obtain configuration commands from the cloud, the vehicle can generate a local configuration file based on the cloud configuration commands so that the vehicle can directly obtain cloud configuration commands locally in subsequent operations.

[0137] Optionally, the file format of the local configuration file includes, but is not limited to, JavaScript Object Notation (JSON) and Initialization (INI) files.

[0138] It should be understood that, when generating the configuration file, the configuration instructions determine the cloud's configuration permissions for the virus detection function, directly relating to the function's operational status. The vehicle identifier (e.g., the vehicle's VIN) is used to uniquely link the local configuration file to the vehicle, preventing misreading of the local configuration file. The vehicle system version identifier, such as the vehicle system version number, is used to determine whether the vehicle currently has virus detection functionality configured.

[0139] As mentioned earlier, vehicle model and configuration parameters are usually directly linked. When the vehicle model is determined, the number of processor cores, memory, storage, and networking capabilities of the vehicle's infotainment system are also fixed. Therefore, by knowing the vehicle model, one can understand its configuration parameters and determine whether the current performance of the vehicle's infotainment system supports the operation of virus detection functions.

[0140] Specifically, after the vehicle completes its first system upgrade, after obtaining the local configuration status and the configuration instructions from the cloud, the vehicle can also generate a local configuration file based on the cloud configuration instructions, the vehicle system version identifier, the vehicle identifier, and the vehicle model.

[0141] Between the generation of the local configuration file and the next vehicle startup, the configuration instructions in the cloud may be updated. Each time the cloud configuration instructions are updated, an update notification is pushed to the vehicle. This notification includes the updated configuration instructions. Based on this, upon the next vehicle startup, the vehicle can determine whether it has received the configuration instruction update notification. If no update notification is received, it means the cloud configuration instructions have not been updated, and the vehicle can directly read the configuration instructions from the local configuration file. Upon the next startup, based on the vehicle's local configuration state and the configuration instructions, the target operating state for the next round of virus detection will be redefined. If an update notification is received, it means the cloud configuration instructions have been updated. The vehicle can obtain the updated configuration instructions from the update notification and, based on the updated configuration instructions and the local configuration state, redefined the target operating state for the next round of virus detection. Simultaneously, the vehicle also needs to update the local configuration file based on the updated configuration instructions, i.e., generate an updated local configuration file according to the updated configuration instructions, the vehicle's infotainment system version identifier, the vehicle's identifier, and the vehicle model.

[0142] In the above technical solution, in addition to determining the target operating status of the virus detection function based on configuration instructions and local configuration status, the vehicle can also generate a local configuration file based on configuration instructions and basic vehicle information. When the vehicle starts up again, if the configuration instructions in the cloud have not been updated, the vehicle will prioritize reading the local configuration file to determine the configuration instructions, without waiting for communication with the cloud, thus reducing the configuration waiting time after the vehicle system starts. If the configuration instructions in the cloud are updated, the vehicle will trigger an update to the local configuration file through an update prompt message, ensuring that the local configuration file is synchronized with the latest configuration instructions and guaranteeing the accuracy of the virus detection function's operating status determination.

[0143] To facilitate understanding of the overall implementation flow of the embodiments of this application, the following is a detailed explanation. Figure 3 The entire interaction process between the cloud and the vehicle involved in the embodiments of this application is described.

[0144] Figure 3 This is an interactive flowchart of a vehicle upgrade control provided in an embodiment of this application.

[0145] For example, such as Figure 3 As shown, the method 300 includes the following steps 301 to 313.

[0146] 301, Cloud 102 sends an upgrade package to vehicle 101.

[0147] 302, Vehicle 101 received the upgrade package and performed a system upgrade based on the upgrade package.

[0148] 303. If vehicle 101 has completed a system upgrade and is started for the first time, obtain the local configuration status.

[0149] 304, Vehicle 101: Determine if the local configuration status is enabled.

[0150] If the local configuration status is off, proceed to step 305; If the local configuration status is enabled, proceed to step 306.

[0151] 305, Vehicle 101 control virus detection function is off.

[0152] 306, Vehicle 101 preloads the runtime code for the virus detection function into memory.

[0153] 307, Vehicle 101 sends a configuration command acquisition command to Cloud 102.

[0154] 308. In response to the acquisition command, cloud 102 sends a configuration command to vehicle 101.

[0155] 309, Vehicle 101 determines whether the configuration command is an enable command.

[0156] If the configuration command is set to disable, return to step 305; If the configuration command is set to enable, proceed to step 310.

[0157] 310, The code for controlling the virus detection function of vehicle 101 has started running.

[0158] 311. Vehicle 101 generates a local configuration file based on the configuration instructions, the vehicle system version identifier, the vehicle 101 identifier, and the vehicle model. 312. When the configuration instructions in the cloud 102 are updated, the cloud 102 sends an update prompt message to the vehicle 101.

[0159] 313, Vehicle 101 receives the update notification information, obtains the updated configuration instructions, and returns to step 311 to regenerate the updated local configuration file.

[0160] Steps 301 to 313 in method 300 have the same inventive concept as steps 201 to 203 in method 200. For details, please refer to the description of method 200 above, which will not be repeated here.

[0161] In summary, this application proposes a method for controlling vehicle upgrades. During implementation, after a vehicle completes a system upgrade, the vehicle obtains the local configuration status of the virus detection function and the cloud-based configuration instructions for the virus detection function. Based on the local configuration status and the configuration instructions, the target operating state of the virus detection function is determined. Finally, the operation of the virus detection function is controlled based on the target operating state. This method, combining local configuration and cloud instructions, flexibly configures the state of the virus detection function, allowing for differentiated adaptation of the virus detection function's state across different vehicles. This enables personalized control of the virus detection function across different vehicles and achieves flexible scheduling of the virus detection function.

[0162] Figure 4 This is a schematic diagram of a device for controlling vehicle upgrades provided in an embodiment of this application.

[0163] For example, such as Figure 4 As shown, the device 400 includes: The acquisition module 401 is used to acquire the local configuration status of the virus detection function of the vehicle and the configuration instructions of the virus detection function in the cloud when the vehicle has completed the system upgrade. The vehicle that has completed the system upgrade contains the running code of the virus detection function, and there is a communication connection between the cloud and the vehicle. The determination module 402 is used to determine the target operating state of the virus detection function based on the local configuration state, or the local configuration state and the configuration instruction. The control module 403 is used to control the operation of the virus detection function according to the target's operating status.

[0164] In one possible implementation, the determining module 402 is specifically used to: determine the target running state according to the configuration instruction when the local configuration state is enabled; and determine the target running state as disabled when the local configuration state is disabled.

[0165] In one possible implementation, the determining module 402 is further configured to: if the configuration instruction is an enable instruction, determine that the target running state is enabled; if the configuration instruction is a disable instruction, determine that the target running state is disabled.

[0166] In one possible implementation, the determining module 402 is further configured to: preload the running code of the virus detection function into memory when the local configuration state is enabled, so that the virus detection function is in a waiting-to-be-enabled state.

[0167] In one possible implementation, the control module 403 is specifically used to: when the target running state is enabled, control the execution code of the virus detection function to start running to start the virus detection function; when the target running state is disabled, if the execution code of the virus detection function has not been loaded into memory, control the virus detection function to remain disabled; when the target running state is disabled, if the execution code of the virus detection function has been loaded into memory, clear the execution code of the virus detection function in memory to disable the virus detection function.

[0168] In one possible implementation, the acquisition module 401 is specifically used to: determine the local configuration status in response to the configuration operation of the virus detection function; or, acquire the configuration parameters of the vehicle according to the vehicle model, the configuration parameters being used to represent the configuration status of the vehicle's infotainment system performance; and determine the local configuration status according to the configuration parameters.

[0169] In one possible implementation, the determining module 402 is further configured to: generate a local configuration file based on the configuration instruction, the vehicle's in-vehicle system version identifier, the vehicle's identifier, and the vehicle model; determine whether an update prompt for the configuration instruction has been received upon the next vehicle startup; if no update prompt for the configuration instruction has been received, determine the configuration instruction through the local configuration file; and if an update prompt for the configuration instruction has been received, obtain the updated configuration instruction and update the local configuration file based on the updated configuration instruction.

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

[0171] For example, such as Figure 5 As shown, the vehicle 101 includes a memory 501 and a processor 502. The memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform a method for controlling vehicle upgrades.

[0172] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a method for controlling vehicle upgrades provided in embodiments of this application.

[0173] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0174] When the functional modules are divided according to their respective functions, the device may also include an acquisition module, a determination module, and a control module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0175] It should be understood that the apparatus provided in this embodiment is used to execute the above-described method for controlling vehicle upgrades, and therefore can achieve the same effect as the above-described implementation method.

[0176] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0177] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0178] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a method for controlling vehicle upgrades provided in the above embodiments.

[0179] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the method for controlling vehicle upgrades provided in the above embodiment.

[0180] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement a method for controlling vehicle upgrades provided in the above embodiment.

[0181] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0182] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0184] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for controlling vehicle upgrades, characterized in that, The method includes: When the vehicle completes the system upgrade, the local configuration status of the virus detection function of the vehicle and the configuration instructions of the virus detection function of the cloud are obtained. The vehicle that has completed the system upgrade contains the running code of the virus detection function, and the cloud and the vehicle are connected in communication. The target operating state of the virus detection function is determined based on the local configuration state, or the local configuration state and the configuration instructions. The virus detection function is controlled to operate according to the target operating status.

2. The method according to claim 1, characterized in that, Determining the target operating state of the virus detection function based on the local configuration state, or the local configuration state and the configuration instructions, includes: When the local configuration status is enabled, the target running status is determined according to the configuration instructions; If the local configuration status is off, the target running status is determined to be off.

3. The method according to claim 2, characterized in that, When the local configuration state is enabled, determining the target running state according to the configuration instruction includes: If the configuration instruction is an enable instruction, the target running state is determined to be in the enabled state; If the configuration instruction is a disable instruction, the target running state is determined to be off.

4. The method according to claim 2, characterized in that, The method further includes: When the local configuration is enabled, the code for running the virus detection function is preloaded into memory so that the virus detection function is in a state of waiting to be enabled.

5. The method according to claim 4, characterized in that, The step of controlling the virus detection function to operate according to the target operating state includes: When the target running state is enabled, the code controlling the virus detection function starts running to activate the virus detection function; If the virus detection function's runtime code is not loaded into memory when the target running state is off, the virus detection function will remain off. If the target running state is off, and the virus detection function's running code has been loaded into memory, the virus detection function's running code in memory is cleared to disable the virus detection function.

6. The method according to claim 1 or 2, characterized in that, The method further includes: In response to the configuration operation of the virus detection function, determine the local configuration status; or, Based on the vehicle model, obtain the vehicle's configuration parameters, which are used to represent the configuration status of the vehicle's infotainment system. The local configuration status is determined based on the configuration parameters.

7. The method according to claim 1, characterized in that, The method further includes: A local configuration file is generated based on the configuration instructions, the vehicle's infotainment system version identifier, the vehicle's identifier, and the vehicle model. Upon the next vehicle startup, determine whether an update notification for the configuration command has been received; If no update prompt message for the configuration instruction is received, the configuration instruction is determined through the local configuration file; Upon receiving an update prompt message for the configuration instruction, the updated configuration instruction is obtained, and the local configuration file is updated based on the updated configuration instruction.

8. A device for controlling vehicle upgrades, characterized in that, The device includes: The acquisition module is used to acquire the local configuration status of the virus detection function of the vehicle and the configuration instructions of the virus detection function in the cloud when the vehicle completes the system upgrade. The vehicle that has completed the system upgrade contains the running code of the virus detection function, and the cloud and the vehicle are connected in communication. The determination module is used to determine the target operating state of the virus detection function based on the local configuration state, or the local configuration state and the configuration instructions. The control module is used to control the operation of the virus detection function according to the target's operating status.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images