A vehicle-mounted display screen software upgrading method, device, equipment and storage medium

Abstract

The application discloses a vehicle-mounted display screen software upgrading method and device, equipment and a storage medium, which are used for solving the problems of low upgrading efficiency of multiple software modules of a display screen and dependence of an upgrading sequence caused by no unified format of an upgrading package, so as to improve the success rate of display screen software upgrading. A first upgrading package is received, the first upgrading package is obtained according to an identification code, a feature address, feature data and a configuration file corresponding to a first function module; security check is performed on the first upgrading package, if the check is passed, the first upgrading package is written into a standby APP area; a region identifier of an effective APP area is updated to a standby area identifier, and a region identifier of the standby APP area is updated to an effective area identifier; when a BootLoader area is running, program code corresponding to the first upgrading package in a target APP area is run; the target APP area is a region with the effective area identifier; an upgrading result report corresponding to the first function module is generated, and a second upgrading package sent by a cloud is received.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, apparatus, device and storage medium for upgrading software of an in-vehicle display screen. Background Technology

[0002] Currently, in-vehicle display software upgrades primarily use a single storage area direct overwrite method, where the new version of the program is written directly to the currently running area during the upgrade process. If a power outage, network interruption, or data transmission error occurs during the upgrade process, the original program will be corrupted while the new program fails to be fully written, rendering the display completely unusable and severely impacting driving safety and user experience.

[0003] If the upgrade fails, it must be rewritten on-site by professional technicians, which greatly increases after-sales maintenance costs and time, making it difficult to meet the high standards of reliability and efficiency required for software upgrades in intelligent connected vehicles.

[0004] Furthermore, in related technologies, the upgrades of the TP, DP, and APP software for in-vehicle displays are divided into independent serial processes: each module needs to generate a separate upgrade package, and perform three complete connection establishment, data transmission, decompression, and burning operations respectively. Because the upgrade packages lack a unified format identifier, the system cannot dynamically identify the data content of different modules, causing the upgrade packages to be received and processed strictly in a preset order (e.g., TP→DP→APP). If the transmission order is disordered or any link fails (e.g., network fluctuations causing TP packet loss), the entire upgrade process will be forced to terminate and must start from scratch, not only repeatedly consuming communication resources but also significantly extending the total upgrade time due to multiple independent operations. Summary of the Invention

[0005] In view of this, this application provides a method, apparatus, device and storage medium for upgrading the software of an in-vehicle display screen, which solves the problems of low efficiency in upgrading multiple software modules of the display screen and the dependency of upgrade order due to the lack of a unified format of upgrade packages, so as to improve the success rate of display screen software upgrade.

[0006] In a first aspect, embodiments of this application provide a method for upgrading the software of an in-vehicle display screen, applied to a vehicle, the method comprising: Receive a first upgrade package sent from the cloud, wherein the first upgrade package is the upgrade package corresponding to the first functional module of the display screen; The effective APP region and the backup APP region are determined from the first APP region and the second APP region based on the region identifier in the BootLoader region; wherein, the vehicle includes the FLASH memory, and the FLASH memory includes the BootLoader region, the first APP region and the second APP region; The first upgrade package is subjected to security verification. If the verification passes, the first upgrade package is written to the backup APP area. Update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier; When the BootLoader region is running, the program code corresponding to the first upgrade package in the target APP region is executed; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

[0007] In this embodiment, due to the adoption of a dual-region backup mechanism, a usable program region is always maintained during the upgrade process. Even in the event of unexpected situations such as power outages or network interruptions during the upgrade, the vehicle can still start normally and run the original stable version, ensuring driving safety and user experience. This method implements an automated rollback mechanism; when the new version upgrade fails, the system can automatically revert to the original stable version without manual intervention, significantly reducing after-sales maintenance costs and time. Simultaneously, through strict security verification and region identification management, the correctness and reliability of the upgrade package are ensured, preventing the installation of erroneous or damaged upgrade packages and improving the upgrade success rate. For displays containing multiple functional modules, this solution supports independent upgrades for each module without interference, further improving upgrade efficiency and flexibility, and meeting the stringent requirements of intelligent connected vehicles for high reliability and efficiency in software upgrades.

[0008] In some possible embodiments, the security verification of the first upgrade package includes: Parse the first upgrade package to obtain the identification code, feature address, and feature data; the feature data is a structured identification field in the first upgrade package used for matching device identity and compatibility. The target functional module corresponding to the first upgrade package is determined based on the identification code; The feature address is compared with the feature address corresponding to the target functional module; When the feature address matches the feature address corresponding to the target functional module, the feature data is compared with the feature data corresponding to the functional module. If the feature data is consistent with the feature data corresponding to the functional module, then the first upgrade package verification is determined to be successful.

[0009] In this embodiment, the feature data is a structured identification field in the upgrade package used to match device identity and compatibility, including but not limited to: company, project, category, module number, and version; the identification code is used to determine the specific functional module type (such as touch panel, display panel, or application) corresponding to the first upgrade package; and the feature address indicates the specific location where the module upgrade data should be written to the FLASH memory.

[0010] In some possible embodiments, after the verification passes, the method further includes: If writing the first upgrade package to the backup APP area fails, the step of writing the first upgrade package to the backup APP area is executed again.

[0011] In some possible embodiments, after the verification passes, the method further includes: If writing the first upgrade package to the backup APP area fails, then the number of failures is obtained; If the number of failures exceeds the preset number of failures, the upgrade process will end. If the number of failures is less than the preset number of failures, then the step of writing the first upgrade package to the backup APP area is executed again.

[0012] In some possible embodiments, only one of the first APP area and the first APP area in the FLASH memory is a valid APP area, and the other APP area is a spare APP area; When the BootLoader area is running, the program code in the effective APP area is executed; the standby APP area is used to perform data packet writing operations.

[0013] In some possible embodiments, after the verification passes, the method further includes: If writing the first upgrade package to the backup APP area fails, the program in the valid APP area continues to be executed; the distinguishing identifier of the backup APP area remains unchanged, and the distinguishing identifier of the valid APP area remains unchanged.

[0014] In some possible embodiments, after running the program code corresponding to the first upgrade package in the target APP region, the method further includes: Generate an upgrade result report corresponding to the first functional module, and simultaneously receive a second upgrade package sent from the cloud, wherein the second upgrade package is the upgrade package corresponding to the second functional module of the display screen.

[0015] Secondly, embodiments of this application provide a method for upgrading the software of an in-vehicle display screen, applied in the cloud, the method comprising: The identification code, feature address, feature data, and configuration file corresponding to the first functional module of the display screen are compressed to obtain the first upgrade package; The first upgrade package is sent to the vehicle, and the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen are compressed to obtain the second upgrade package; wherein, the first upgrade package is used to enable the vehicle to upgrade the first functional module according to the first upgrade package; The second upgrade package is sent to the vehicle so that the vehicle can upgrade the second functional module according to the second upgrade package.

[0016] Thirdly, embodiments of this application provide a vehicle-mounted display screen software upgrade device, applied to a vehicle, the device comprising: The receiving module is used to receive the first upgrade package sent by the cloud, wherein the first upgrade package is the upgrade package corresponding to the first functional module of the display screen; The region determination module is used to determine the valid APP region and the backup APP region from the first APP region and the second APP region based on the region identifier in the BootLoader region; wherein, the vehicle includes a FLASH memory, and the FLASH memory includes the BootLoader region, the first APP region and the second APP region; The writing module is used to perform security verification on the first upgrade package. If the verification passes, the first upgrade package is written to the backup APP area. The identifier update module is used to update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier. The runtime module is used to run the program code corresponding to the first upgrade package in the target APP region when the BootLoader region is running; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

[0017] In some possible embodiments, the writing module is specifically used for: Parse the first upgrade package to obtain the identification code, feature address, and feature data; the feature data is a structured identification field in the first upgrade package used for matching device identity and compatibility. The target functional module corresponding to the first upgrade package is determined based on the identification code; The feature address is compared with the feature address corresponding to the target functional module; When the feature address matches the feature address corresponding to the target functional module, the feature data is compared with the feature data corresponding to the functional module. If the feature data is consistent with the feature data corresponding to the functional module, then the first upgrade package verification is determined to be successful.

[0018] In some possible embodiments, the writing module is also used for: If writing the first upgrade package to the backup APP area fails, the step of writing the first upgrade package to the backup APP area is executed again.

[0019] In some possible embodiments, the writing module is also used for: If writing the first upgrade package to the backup APP area fails, then the number of failures is obtained; If the number of failures exceeds the preset number of failures, the upgrade process will end. If the number of failures is less than the preset number of failures, then the step of writing the first upgrade package to the backup APP area is executed again.

[0020] In some possible embodiments, only one of the first APP area and the first APP area in the FLASH memory is a valid APP area, and the other APP area is a spare APP area; When the BootLoader area is running, the program code in the effective APP area is executed; the standby APP area is used to perform data packet writing operations.

[0021] In some possible embodiments, the writing module is also used for: If writing the first upgrade package to the backup APP area fails, the program in the valid APP area continues to be executed; the distinguishing identifier of the backup APP area remains unchanged, and the distinguishing identifier of the valid APP area remains unchanged.

[0022] In some possible embodiments, the writing module is further configured to: generate an upgrade result report corresponding to the first functional module; the receiving module is further configured to: simultaneously receive a second upgrade package sent from the cloud, wherein the second upgrade package is an upgrade package corresponding to the second functional module of the display screen.

[0023] Fourthly, embodiments of this application provide a vehicle-mounted display screen software upgrade device, applied in the cloud, the device comprising: The compression module is used to compress the identification code, feature address, feature data and configuration file corresponding to the first functional module of the display screen to obtain the first upgrade package; The sending module is used to send the first upgrade package to the vehicle. The compression module is also used to: simultaneously compress the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen to obtain the second upgrade package; the first upgrade package is used to enable the vehicle to upgrade the first functional module according to the first upgrade package. The sending module is further configured to: send the second upgrade package to the vehicle so that the vehicle upgrades the second functional module according to the second upgrade package.

[0024] Fifthly, another embodiment of this application also provides an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform any of the methods provided in the first and second aspects of this application.

[0025] Sixthly, another embodiment of this application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for causing a computer to perform any of the methods provided in the first and second aspects of the embodiments of this application.

[0026] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A schematic diagram of the overall process for an in-vehicle display software upgrade method provided in this application embodiment, wherein the executing entity is a vehicle; Figure 2 This is a schematic diagram illustrating the security verification process of a first upgrade package in a method for upgrading a vehicle display screen according to an embodiment of this application. Figure 3 A schematic diagram illustrating the overall process of a vehicle display software upgrade method provided in this application embodiment, wherein the execution entity is the cloud. Figure 4A schematic diagram illustrating the cloud-vehicle interaction process of a software upgrade method for an in-vehicle display screen, provided in an embodiment of this application; Figure 5 A schematic diagram of a device for implementing a vehicle display software upgrade method according to an embodiment of this application, wherein the executing subject is a vehicle; Figure 6 A schematic diagram of a device in which the execution subject of a vehicle display software upgrade method provided in this application is the cloud; Figure 7 This is a schematic diagram of an electronic device for an embodiment of a vehicle display software upgrade method provided in this application. Detailed Implementation

[0029] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0030] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0031] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0032] It should be understood that the term "and / or" used in this article 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, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0033] Currently, in-vehicle display software upgrades primarily use a single storage area direct overwrite method, where the new version of the program is written directly to the currently running area during the upgrade process. If a power outage, network interruption, or data transmission error occurs during the upgrade process, the original program will be corrupted while the new program fails to be fully written, rendering the display completely unusable and severely impacting driving safety and user experience.

[0034] Existing technologies lack an effective upgrade verification mechanism, making it impossible to confirm the integrity of the upgrade package before writing, which leads to the installation of erroneous or corrupted upgrade packages, resulting in functional abnormalities or system crashes.

[0035] Meanwhile, since there is no spare program area, after an upgrade fails, it must be rewritten on-site by professional technicians, which greatly increases after-sales maintenance costs and time, making it difficult to meet the high standards of reliability and efficiency required for software upgrades in intelligent connected vehicles.

[0036] To address the aforementioned problems, this application provides a method, apparatus, device, and storage medium for upgrading in-vehicle display software, thereby resolving these issues. The inventive concept of this application can be summarized as follows: A vehicle receives a first upgrade package sent from the cloud, the first upgrade package being an upgrade package corresponding to a first functional module of the display screen; a valid APP region and a backup APP region are determined from a first APP region and a second APP region based on the region identifier in the BootLoader region; the vehicle includes a FLASH memory, which includes a BootLoader region, a first APP region, and a second APP region; a security verification is performed on the first upgrade package, and if the verification passes, the first upgrade package is written to the backup APP region; the region identifier of the valid APP region in the BootLoader region is updated to the backup region identifier, and the region identifier of the backup APP region is updated to the valid region identifier; when the BootLoader region is running, the program code corresponding to the first upgrade package in the target APP region is executed; the target APP region is the region in the BootLoader region whose region identifier is the valid region identifier.

[0037] In this embodiment, due to the adoption of a dual-region backup mechanism, a usable program region is always maintained during the upgrade process. Even in the event of unexpected situations such as power outages or network interruptions during the upgrade, the vehicle can still start normally and run the original stable version, ensuring driving safety and user experience. This method implements an automated rollback mechanism. When the new version upgrade fails, the system can automatically revert to the original stable version without manual intervention, significantly reducing after-sales maintenance costs and time. Simultaneously, through strict security verification and region identification management, the correctness and reliability of the upgrade package are ensured, preventing the installation of incorrect or damaged upgrade packages and improving the upgrade success rate. For displays containing multiple functional modules, this solution supports independent upgrades for each module without interference, further improving upgrade efficiency and flexibility, and meeting the stringent requirements of intelligent connected vehicles for high reliability and efficiency in software upgrades.

[0038] For ease of understanding, the following detailed description, in conjunction with the accompanying drawings, illustrates a method for upgrading the software of an in-vehicle display screen according to an embodiment of this application: like Figure 1 The diagram shown is a schematic representation of the overall process of a vehicle-mounted display software upgrade method provided in this application embodiment, wherein: In step 101: Receive the first upgrade package sent by the cloud. The first upgrade package is the upgrade package corresponding to the first functional module of the display screen.

[0039] In this embodiment, the vehicle receives an upgrade package from the cloud via wireless communication. The "first" in the first upgrade package refers only to the specific functional module to be processed. It actually corresponds to the upgrade package of any module such as the touch panel (TP), display panel (DP), or application (APP) of the display screen, rather than the first module in sequence. The upgrade package only contains the updated content of the corresponding functional module and does not involve the code of other modules of the display screen, thereby achieving accurate and efficient modular upgrades and avoiding the waste of resources and potential risks caused by full updates.

[0040] In step 102: the valid APP region and the backup APP region are determined from the first APP region and the second APP region according to the region identifier in the BootLoader region; wherein the vehicle includes a FLASH memory, and the FLASH memory includes the BootLoader region, the first APP region and the second APP region.

[0041] In this embodiment of the application, the FLASH memory in the vehicle is divided into three parts: a BootLoader area, a first APP area, and a second APP area. The BootLoader area stores the boot program that runs when the system starts up. This area contains an area identifier field, which is used to record the information of the currently running APP area.

[0042] When an upgrade is needed, the system first reads the region identifier in the BootLoader region to determine which of the first APP region and the second APP region is the currently active and valid region, while the other is used as a backup region.

[0043] For example, if the region identifier points to the first APP region, it means that the program currently running is in the first APP region, and the second APP region is a spare region where a new version can be written; the reverse is also true.

[0044] The above design ensures that there is always a usable program area during the upgrade process, avoiding the risk of failure to start due to upgrade failure, which is common in traditional single-area upgrade methods.

[0045] In step 103: perform a security check on the first upgrade package. If the check passes, write the first upgrade package into the backup APP area.

[0046] In this embodiment, during the upgrade process, the first upgrade package received from the cloud is first subjected to security verification to confirm that the data in the first upgrade package is complete and has not been tampered with. If the verification passes, it indicates that the first upgrade package is reliable. At this time, the first upgrade package is written to the currently unused backup APP area, rather than overwriting the currently running APP area.

[0047] The above design ensures that the new version data is only safely written to the backup area without affecting the current normal operation, providing a reliable data foundation for subsequent switchover operations.

[0048] In some possible embodiments, a security verification is performed on the first upgrade package, which can be specifically implemented as follows: Figure 2 The process shown is as follows: In step 201: the first upgrade package is parsed to obtain the identification code, feature address, and feature data.

[0049] In this embodiment of the application, during the upgrade process, the received first upgrade package is parsed to extract key information.

[0050] The identification code is used to determine the specific functional module type (such as touch panel, display panel or application) corresponding to the first upgrade package. The feature address indicates the specific location where the module upgrade data should be written to the FLASH memory. The feature data contains detailed information such as company, project, category, module number and version, which is used to verify the compatibility of the upgrade package with the current vehicle system.

[0051] The extraction of the above information enables the accurate location of upgrade data for different functional modules to the correct position, and ensures that only matching upgrade packages can be applied, providing a basis for subsequent secure writing and verification.

[0052] In step 202: the target functional module corresponding to the first upgrade package is determined based on the identification code.

[0053] In this embodiment of the application, the identification code is a unique identifier pre-set in the first upgrade package, used to clearly distinguish the upgrade data of different functional modules.

[0054] By parsing the identification code in the first upgrade package, it is possible to quickly and accurately determine which specific functional module of the display is applicable to the first upgrade package, such as the touch panel (TP), display panel (DP), or application (APP).

[0055] The above mechanism ensures that the upgrade data of each functional module can be correctly identified and processed, avoiding confusion or misuse of upgrade data from different modules, and providing a basic guarantee for subsequent accurate writing and secure upgrades.

[0056] In step 203: the feature address is compared with the feature address corresponding to the target functional module.

[0057] In this embodiment, the feature address is a predefined exclusive storage location identifier for each functional module in the FLASH memory.

[0058] The feature addresses contained in the first upgrade package are compared with the feature addresses that the target functional module should have to verify whether the first upgrade package is indeed applicable to the currently processed functional module.

[0059] The above comparison mechanism ensures that the upgrade data can be accurately written to the corresponding functional module storage area, avoiding system anomalies or functional failures caused by data misalignment, and providing an important guarantee for the security and reliability of the upgrade process.

[0060] In step 204: when the feature address matches the feature address corresponding to the target functional module, the feature data is compared with the feature data corresponding to the functional module.

[0061] In this embodiment, after the feature address matching is confirmed, the feature data contained in the upgrade package will be further compared with the actual feature data of the current functional module. The feature data includes, but is not limited to, key information such as company name, vehicle model, category identifier, module number, and software version.

[0062] The above comparison ensures that the upgrade package is not only stored in the correct location, but is also fully compatible with the current vehicle's specific configuration and software environment.

[0063] For example, it can prevent upgrade packages designed for other models or older systems from being applied incorrectly, thereby avoiding anomalies caused by version incompatibility or misconfiguration and ensuring the safety and reliability of the upgrade process.

[0064] In step 205: If the feature data is consistent with the feature data corresponding to the functional module, then the first upgrade package verification is confirmed to be successful.

[0065] In this embodiment, after a successful feature address match, the feature data in the upgrade package is further compared with the actual feature data of the current functional module. Only when the feature data matches completely is it determined that the upgrade package is fully compatible with the current vehicle hardware configuration, software environment, and functional module requirements, thus confirming that the upgrade package verification has passed.

[0066] The aforementioned dual verification mechanism (feature address + feature data) ensures that the upgrade package is not only stored in the correct location, but also essentially meets the specific requirements of the current device, effectively preventing anomalies caused by version mismatch, vehicle model confusion, or module type incompatibility, and providing the highest level of security guarantee for subsequent upgrade operations.

[0067] In step 104: update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier.

[0068] In this embodiment of the application, in the dual-zone backup upgrade mechanism, the BootLoader zone stores identification information used to indicate the currently valid APP zone.

[0069] Once the new version upgrade package (first upgrade package) is successfully written to the backup APP area, the area identifier in the BootLoader area will be updated, changing the previously marked valid APP area identifier to an "invalid" state, while setting the backup APP area identifier that was just written to the new version to a "valid" state.

[0070] The aforementioned identifier switching operation ensures that the new version of the program can be correctly identified and loaded upon the next startup, achieving a seamless version switch. Since each upgrade only updates a single identifier in the BootLoader area, rather than the entire app area, this operation is fast and reliable, and does not affect the currently running system, providing users with a seamless software update experience.

[0071] In step 105: When the BootLoader region is running, the program code corresponding to the first upgrade package in the target APP region is executed; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

[0072] In this embodiment, when the vehicle's infotainment system starts up, the BootLoader region, as the first program to run, reads the valid region identifier stored within its own region. This identifier clearly indicates the APP region that should be running (the region with the valid region identifier in the first APP region and the second APP region). The BootLoader determines the specific starting address of the target APP region based on this region identifier, then jumps to that address and begins executing the program code therein.

[0073] The above mechanism ensures that the latest and valid software version is correctly loaded and run every time the system starts, while retaining the ability to switch back to an older version, providing a reliable foundation for software updates. Since the BootLoader is only responsible for identification and redirection and does not involve specific business logic, its operation is stable and reliable, effectively avoiding startup failures caused by software updates.

[0074] In some possible embodiments, after the verification passes, the first upgrade package may fail to be written to the backup APP area due to problems such as power failure, network interruption or data transmission error. In this case, the following can be done: perform the step of writing the first upgrade package to the backup APP area again.

[0075] In this embodiment of the application, if the writing of the first upgrade package to the backup APP area fails, the writing operation can be repeated.

[0076] In an automotive environment, due to various potential interference factors (such as voltage fluctuations, electromagnetic interference, and unstable communication signals), a one-time write failure is often a transient issue rather than a permanent fault. By setting up a reasonable retry mechanism, it is possible to attempt to overcome these transient interferences and complete the write operation without re-downloading the upgrade package.

[0077] The aforementioned retry mechanism significantly improves the success rate of a single upgrade, avoiding upgrade failures due to accidental factors. Secondly, it reduces the risk of the vehicle's infotainment system becoming unavailable, ensuring stable operation even if a brief anomaly occurs during the writing process. It also reduces after-sales maintenance costs, avoiding situations where professional technicians are needed for on-site repairs due to upgrade failures. Finally, it enhances the user experience, allowing users to complete the upgrade process without manual intervention, resulting in a smoother and more reliable experience.

[0078] In some other possible embodiments, in order to avoid the waste of resources caused by multiple retries, the following can be implemented: if writing the first upgrade package to the backup APP area fails, the number of failures is obtained; if the number of failures is greater than the preset number of failures, the upgrade process is terminated; if the number of failures is less than the preset number of failures, the step of writing the first upgrade package to the backup APP area is executed again.

[0079] In this embodiment, when writing the first upgrade package to the backup APP area fails, the current number of failures is first recorded, and then a decision is made based on a preset number of failures to determine whether to continue attempting. The upgrade process ends when the preset number of failures is reached.

[0080] The above methods effectively address common transient faults in the in-vehicle environment. Furthermore, the preset maximum number of retries ensures the stability and security of the vehicle's infotainment system. Without limiting retries, the system might enter an infinite loop, wasting computing resources and potentially rendering it unusable for extended periods. By setting a reasonable threshold (e.g., 2-3 times), the system can identify truly unsolvable faults while attempting recovery, avoiding unnecessary resource consumption.

[0081] More importantly, when the number of failed attempts reaches a preset limit, the upgrade process will automatically end, maintaining the normal operation of the existing stable version, rather than forcing continued attempts and causing more serious problems. This design ensures that the vehicle is always operational, and even if the upgrade fails, basic functions will not be affected, significantly improving driving safety.

[0082] Furthermore, the methods described above provide crucial information for subsequent fault diagnosis. When the upgrade ultimately fails multiple times, the vehicle's infotainment system can record detailed error information, facilitating remote diagnosis or on-site repair by technicians, thereby further optimizing the upgrade process and system stability.

[0083] In some other possible embodiments, if the upgrade fails, the current state remains unchanged and the program in the valid APP area continues to be executed; the distinguishing identifier of the backup APP area remains unchanged, while the distinguishing identifier of the valid APP area remains unchanged.

[0084] In this embodiment, considering the automotive electronic system, any situation that could lead to functional loss is unacceptable. Therefore, by retaining the original stable version, the vehicle infotainment system can still function normally even if the upgrade fails, ensuring driving safety and basic functions remain unaffected. When the upgrade fails, the system does not require complex recovery operations; it simply continues to use the verified stable version. This significantly reduces the complexity of the vehicle infotainment system and improves reliability. The vehicle infotainment system can also record detailed error logs, including the cause of failure, timestamps, and other information, providing a basis for remote diagnostics and subsequent upgrade strategy adjustments without affecting the current use of the vehicle.

[0085] In some possible embodiments, the above process can only be performed on the received second and / or third upgrade packages after the first upgrade package has been successfully upgraded. Figure 1 The upgrade process is shown below.

[0086] In this embodiment, during the upgrade of multiple software modules of the in-vehicle display, the vehicle system adopts a serial upgrade strategy to ensure reliability. When multiple upgrade packages for functional modules (such as the TP touch panel, DP display panel, and APP application) are received, they are processed in strict order of receipt: the complete upgrade process of the first module is completed first (including all steps such as receiving, verification, writing, and identifier switching). Only after confirming that the module has been successfully upgraded and is running stably will the upgrade of the next module begin.

[0087] The above design avoids resource conflicts and system instability risks that may arise from multiple upgrade operations running simultaneously, ensuring that each upgrade is an independent and complete transaction. If an upgrade of a module fails midway, the subsequent upgrade process will be immediately terminated, preserving the currently successfully upgraded parts and the original version, preventing the vehicle system from entering an uncertain state, and thus maximizing the guarantee that the vehicle is always in a safe and available state.

[0088] In other possible embodiments, in order to further improve the upgrade efficiency, the following can be implemented: generating an upgrade result report corresponding to the first functional module, and simultaneously receiving a second upgrade package sent from the cloud, wherein the second upgrade package is an upgrade package corresponding to the second functional module of the display screen.

[0089] In this embodiment, after the upgrade of the first functional module (such as the touch panel) is completed, a detailed upgrade result report is generated, recording key data during the upgrade process (including upgrade package version, verification results, write status, time consumed, etc.). This report is then sent to a cloud server via the network for remote monitoring and data analysis. Simultaneously, after confirming that the first functional module upgrade is successful and operating stably, a second upgrade package sent from the cloud is received. This upgrade package is specifically for another functional module of the display screen (such as the display panel). By receiving the second upgrade package while generating the first functional module upgrade report, network connectivity and processing resources can be fully utilized, avoiding the wasted time waiting for network transmission in traditional serial processes.

[0090] Specifically, while the upgrade report for the first module is being generated (primarily involving log recording and network transmission), the system can begin receiving upgrade data from the second module without waiting for this process to complete completely. This ensures reliable reporting of the first module's upgrade results and allows for the acquisition of resources needed for subsequent upgrades in advance. This design is particularly suitable for situations with unstable network connections in vehicle environments, reducing the risk of delays and interruptions caused by establishing multiple network connections. It makes the entire upgrade process more efficient and smoother, significantly shortening user waiting time while maintaining system stability and security.

[0091] After introducing one method for upgrading in-vehicle display software where the execution entity is the vehicle, the following describes another method for upgrading in-vehicle display software where the execution entity is the cloud: like Figure 3 The diagram shows the overall process of a vehicle display software upgrade method where the execution entity is in the cloud. In step 301: the identification code, feature address, feature data and configuration file corresponding to the first functional module of the display screen are compressed to obtain the first upgrade package.

[0092] In this embodiment, the cloud, as the provider of the upgrade service, is responsible for generating the upgrade package during the vehicle software update process. For the first functional module of the display screen (such as the touch panel TP), the cloud first collects the latest version code, identification code, feature address, feature data and related resource files of the module, and then compresses these files to generate a compact and easily transmittable first upgrade package.

[0093] The compression process described above not only significantly reduces the size of the upgrade package, lowering network bandwidth consumption and time costs, but also facilitates subsequent security verification. The compressed upgrade package contains complete yet concise module update data, ensuring that vehicles can efficiently receive and correctly parse it, providing a reliable data foundation for subsequent local upgrade operations.

[0094] In step 302: the first upgrade package is sent to the vehicle, and the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen are compressed to obtain the second upgrade package. The first upgrade package is used to enable the vehicle to upgrade the first functional module according to the first upgrade package.

[0095] In this embodiment, while the cloud sends the first upgrade package corresponding to the first functional module to the vehicle, it has already begun preparing the second upgrade package for the second functional module. This parallel processing mechanism significantly improves the overall upgrade efficiency.

[0096] When the first upgrade package is transmitted to the vehicle via the network, the cloud can immediately compress the configuration file of the second functional module and generate the second upgrade package without waiting for the transmission to complete.

[0097] This design allows the cloud to fully utilize network bandwidth and server resources, avoiding the wasted idle time of traditional serial processing methods that wait for the next upgrade package to be generated only after the previous one is completed. For multi-software module upgrade scenarios in automotive displays, this parallel operation ensures the cloud is always operating at high efficiency, quickly responding to vehicle upgrade requests, significantly reducing the total time from issuing the upgrade command to the completion of all module upgrades, while also guaranteeing the quality and integrity of each upgrade package, providing users with a smoother software update experience.

[0098] In step 303: The second upgrade package is sent to the vehicle so that the vehicle can upgrade the second functional module according to the second upgrade package.

[0099] In this embodiment, the cloud sends the second upgrade package to the vehicle, forming a continuous upgrade process with the transmission of the first upgrade package. While the first upgrade package is being transmitted or has been received and processed by the vehicle, the cloud has already prepared the second upgrade package and sends it immediately. This continuous transmission mechanism significantly improves the overall upgrade efficiency.

[0100] For multi-module software upgrade scenarios in vehicle displays, this method avoids the idle time of traditional serial modes that wait for the previous module to be fully upgraded before sending the next module's upgrade package. It allows the cloud to continuously output upgrade data, and the vehicle can begin receiving data from the second module while receiving the first module's upgrade package, fully utilizing network bandwidth resources. Especially in potentially unstable in-vehicle network environments, this continuous transmission strategy ensures that upgrade data is delivered as quickly as possible, reducing the risk of upgrade failure due to network interruptions and providing users with a faster and more reliable software update experience.

[0101] To make it easier to understand, let's take the upgrade of the in-vehicle central control display screen in a smart car as an example: like Figure 4 As shown, after receiving a software update instruction for a certain vehicle model, the cloud server first collects the latest version of the driver, touch calibration parameters, and interaction logic code for the touch panel (TP) module, performs ZIP compression processing to generate the first upgrade package, and then sends the first upgrade package to the vehicle. At the same time, the cloud does not wait for the first upgrade package to be sent, but immediately begins to process the upgrade work of the display panel (DP) module: collects the high-resolution display driver, color management algorithm, and UI interface resource files, performs compression processing to generate the second upgrade package, sends the second data package to the vehicle, and at the same time generates the third upgrade package corresponding to the application (APP) module and sends the third upgrade package to the vehicle.

[0102] It should be noted that the vehicle will execute the upgrade immediately upon receiving the first upgrade package. Figure 1 The process shown is in Figure 1 Even if a second upgrade package is received before the process shown has been completed, the second upgrade package will not be executed immediately. Figure 1 The process shown is not the same as the one described above, but rather the process of executing the second upgrade package after the first upgrade package has completed the upgrade. Figure 1 The process is shown below.

[0103] Based on the same inventive concept, this application also provides a vehicle display software upgrade device, with the vehicle as the executing entity, such as... Figure 5 As shown, the device includes: The receiving module 5001 is used to receive a first upgrade package sent from the cloud, wherein the first upgrade package is the upgrade package corresponding to the first functional module of the display screen; The region determination module 5002 is used to determine the valid APP region and the backup APP region from the first APP region and the second APP region according to the region identifier in the BootLoader region; wherein the FLASH memory includes the BootLoader region, the first APP region and the second APP region. The writing module 5003 is used to perform security verification on the first upgrade package. If the verification passes, the first upgrade package is written to the backup APP area. The identifier update module 5004 is used to update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier. The running module 5005 is used to run the program code corresponding to the first upgrade package in the target APP region when the BootLoader region is running; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

[0104] In some possible embodiments, the writing module 5003 is specifically used for: Parse the first upgrade package to obtain the identification code, feature address, and feature data; the feature data is a structured identification field in the first upgrade package used for matching device identity and compatibility. The target functional module corresponding to the first upgrade package is determined based on the identification code; The feature address is compared with the feature address corresponding to the target functional module; When the feature address matches the feature address corresponding to the target functional module, the feature data is compared with the feature data corresponding to the functional module. If the feature data is consistent with the feature data corresponding to the functional module, then the first upgrade package verification is determined to be successful.

[0105] In some possible embodiments, the writing module 5003 is also used for: If writing the first upgrade package to the backup APP area fails, the step of writing the first upgrade package to the backup APP area is executed again.

[0106] In some possible embodiments, the writing module 5003 is also used for: If writing the first upgrade package to the backup APP area fails, then the number of failures is obtained; If the number of failures exceeds the preset number of failures, the upgrade process will end. If the number of failures is less than the preset number of failures, then the step of writing the first upgrade package to the backup APP area is executed again.

[0107] In some possible embodiments, only one of the first APP area and the first APP area in the FLASH memory is a valid APP area, and the other APP area is a spare APP area; When the BootLoader area is running, the program code in the effective APP area is executed; the standby APP area is used to perform data packet writing operations.

[0108] In some possible embodiments, the writing module 5003 is also used for: If writing the first upgrade package to the backup APP area fails, the program in the valid APP area continues to be executed; the distinguishing identifier of the backup APP area remains unchanged, and the distinguishing identifier of the valid APP area remains unchanged.

[0109] In some possible embodiments, after running the program code corresponding to the first upgrade package in the target APP region, the method further includes: Generate an upgrade result report corresponding to the first functional module, and simultaneously receive a second upgrade package sent from the cloud, wherein the second upgrade package is the upgrade package corresponding to the second functional module of the display screen.

[0110] Based on the same inventive concept, this application also provides a vehicle display software upgrade device, with the cloud as the execution entity, such as... Figure 6 As shown, the device includes: Compression module 6001 is used to compress the identification code, feature address, feature data and configuration file corresponding to the first functional module of the display screen to obtain the first upgrade package; The sending module 6002 is used to send the first upgrade package to the vehicle. The compression module 6001 is also used to: simultaneously compress the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen to obtain the second upgrade package; the first upgrade package is used to enable the vehicle to upgrade the first functional module according to the first upgrade package. The sending module 6002 is further configured to: send the second upgrade package to the vehicle so that the vehicle can upgrade the second functional module according to the second upgrade package.

[0111] Corresponding to the above embodiments, this application also provides an electronic device. Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 700 may include a processor 701, a memory 702, and a communication unit 703. These components communicate through one or more buses. Those skilled in the art will understand that the structure of the electronic device shown in the figure does not constitute a limitation on the embodiment of this application. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0112] The communication unit 703 is used to establish a communication channel, enabling the electronic device to communicate with other devices. It can receive user data from other devices or send user data to other devices.

[0113] The processor 701 serves as the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 702, and calls data stored in the memory to perform various functions and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 701 may consist only of a central processing unit (CPU). In this embodiment, the CPU may have a single processing core or include multiple processing cores.

[0114] The memory 702 is used to store the execution instructions of the processor 701. The memory 702 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.

[0115] When the execution instructions in memory 702 are executed by processor 701, the electronic device 700 is able to perform operations. Figures 1-4 Some or all of the steps in the illustrated embodiments.

[0116] In a specific implementation, this application also provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, it may include some or all of the steps of the various embodiments of the vehicle display software upgrade method provided in this application. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0117] Those skilled in the art will clearly understand that the techniques in the embodiments of this application can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application or some parts of the embodiments.

[0118] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments and terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

Claims

1. A method for upgrading the software of an in-vehicle display screen, characterized in that, Applied to vehicles, the method includes: Receive a first upgrade package sent from the cloud, wherein the first upgrade package is the upgrade package corresponding to the first functional module of the display screen; The effective APP region and the backup APP region are determined from the first APP region and the second APP region based on the region identifier in the BootLoader region; wherein, the vehicle includes a FLASH memory, and the FLASH memory includes a BootLoader region, a first APP region and a second APP region; The first upgrade package is subjected to security verification. If the verification passes, the first upgrade package is written to the backup APP area. Update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier; When the BootLoader region is running, the program code corresponding to the first upgrade package in the target APP region is executed; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

2. The method according to claim 1, characterized in that, The security verification of the first upgrade package includes: Parse the first upgrade package to obtain the identification code, feature address, and feature data; The target functional module corresponding to the first upgrade package is determined based on the identification code; The feature address is compared with the feature address corresponding to the target functional module; When the feature address matches the feature address corresponding to the target functional module, the feature data is compared with the feature data corresponding to the functional module. If the feature data is consistent with the feature data corresponding to the functional module, then the first upgrade package verification is determined to be successful.

3. The method according to claim 1, characterized in that, After the verification passes, the method further includes: If writing the first upgrade package to the backup APP area fails, then the number of failures is obtained; If the number of failures exceeds the preset number of failures, the upgrade process will end. If the number of failures is less than the preset number of failures, then the step of writing the first upgrade package to the backup APP area is executed again.

4. The method according to claim 1, characterized in that, In the FLASH memory, only one of the first APP areas is a valid APP area, and the other APP area is a spare APP area. When the BootLoader area is running, the program code in the effective APP area is executed; the standby APP area is used to perform data packet writing operations.

5. The method according to claim 1, characterized in that, After the verification passes, the method further includes: If writing the first upgrade package to the backup APP area fails, the program in the valid APP area continues to be executed; the distinguishing identifier of the backup APP area remains unchanged, and the distinguishing identifier of the valid APP area remains unchanged.

6. The method according to claim 1, characterized in that, After running the program code corresponding to the first upgrade package in the target APP area, the method further includes: Generate an upgrade result report corresponding to the first functional module, and simultaneously receive a second upgrade package sent from the cloud, wherein the second upgrade package is the upgrade package corresponding to the second functional module of the display screen.

7. A method for upgrading the software of an in-vehicle display screen, characterized in that, Applied to the cloud, the method includes: The identification code, feature address, feature data, and configuration file corresponding to the first functional module of the display screen are compressed to obtain the first upgrade package; The first upgrade package is sent to the vehicle, and the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen are compressed to obtain the second upgrade package; wherein, the first upgrade package is used to enable the vehicle to upgrade the first functional module according to the first upgrade package; The second upgrade package is sent to the vehicle so that the vehicle can upgrade the second functional module according to the second upgrade package.

8. A vehicle-mounted display screen software upgrade device, characterized in that, Applied to vehicles, the device includes: The receiving module is used to receive the first upgrade package sent by the cloud, wherein the first upgrade package is the upgrade package corresponding to the first functional module of the display screen; The region determination module is used to determine the valid APP region and the backup APP region from the first APP region and the second APP region based on the region identifier in the BootLoader region; wherein, the vehicle includes a FLASH memory, and the FLASH memory includes the BootLoader region, the first APP region and the second APP region; The writing module is used to perform security verification on the first upgrade package. If the verification passes, the first upgrade package is written to the backup APP area. The identifier update module is used to update the region identifier of the valid APP region in the BootLoader region to the backup region identifier, and update the region identifier of the backup APP region to the valid region identifier. The running module is used to run the program code corresponding to the first upgrade package in the target APP region when the BootLoader region is running; the target APP region is the region in the BootLoader region whose region identifier is a valid region identifier.

9. A vehicle-mounted display screen software upgrade device, characterized in that, The device, applied in the cloud, includes: The compression module is used to compress the identification code, feature address, feature data and configuration file corresponding to the first functional module of the display screen to obtain the first upgrade package; The sending module is used to send the first upgrade package to the vehicle so that the vehicle can upgrade the first functional module according to the first upgrade package; the compression module is also used to: simultaneously compress the identification code, feature address, feature data and configuration file corresponding to the second functional module of the display screen to obtain the second upgrade package; The sending module is further configured to: send the second upgrade package to the vehicle so that the vehicle upgrades the second functional module according to the second upgrade package.

10. An electronic device, characterized in that, It includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to perform the method of any one of claims 1-7.

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

Images