Vehicle-mounted wireless communication module upgrading method, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of vehicle-mounted equipment, and discloses a vehicle-mounted wireless communication module upgrading method, electronic equipment and a storage medium. The method comprises the following steps: in a current system, continuously monitoring an upgrading instruction, and after the upgrading instruction is obtained, downloading a firmware upgrading package and continuously monitoring the state of the system and a vehicle; wherein the current system is located in a first storage partition; after downloading of the firmware upgrade package is completed and the system and vehicle states meet preset upgrade conditions, backing up system parameters in a second storage partition, and writing the firmware upgrade package into the second storage partition; after writing of the firmware upgrade package is completed, if a system switching command is obtained, switching to the target system is carried out, and the backup system parameters are recovered to the target system; wherein the target system is located in a second storage partition. Seamless operation of vehicle functions and user experience are ensured through a multi-partition mechanism, an upgrade condition judgment system and a system parameter backup mechanism.

Description

Technical Field

[0001] The embodiments of the present invention relate to the technical field of vehicle-mounted equipment, and in particular to a vehicle-mounted wireless communication module upgrading method, electronic equipment and storage medium. Background Art

[0002] With the development of automobile intelligence and networking, the on-board wireless communication module (Telematics Control Unit, TCU) or T-box has become an important part of modern vehicles. In order to ensure the continuous optimization and security update of TCU or T-box functions, OTA (Over-The-Air) technology is widely used.

[0003] At present, OTA upgrade mainly uses RECOVERY mode to upgrade the system firmware, but the system cannot perform other operations during the upgrade process, resulting in the vehicle being unable to be used normally. In addition, in some cases, system parameters may be lost after the upgrade. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a vehicle-mounted wireless communication module upgrade method, electronic device and storage medium, so as to solve the problem that the vehicle cannot be used normally during OTA upgrade and the system parameters are lost after the upgrade.

[0005] To solve the above technical problems, an embodiment of the present invention provides a method for upgrading a vehicle-mounted wireless communication module, comprising: in the current system, continuously monitoring upgrade instructions, and after obtaining the upgrade instructions, downloading a firmware upgrade package and continuously monitoring the system and vehicle status; wherein, the current system is located in the first storage partition; after the firmware upgrade package is downloaded and the system and vehicle status meet the preset upgrade conditions, the system parameters in the second storage partition are backed up, and the firmware upgrade package is written to the second storage partition; after the firmware upgrade package is written, if a system switching command is obtained, switch to the target system, and restore the backed-up system parameters to the target system; wherein, the target system is located in the second storage partition.

[0006] An embodiment of the present invention further provides an electronic device, comprising: at least one processor; and

[0007] A memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle wireless communication module upgrade method as described above.

[0008] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the vehicle-mounted wireless communication module upgrading method as described above is implemented.

[0009] In the embodiment of the present invention, through the judgment of the multi-partition mechanism and the upgrade conditions, it is ensured that the system and the vehicle perform the system upgrade of the target storage partition when the preset conditions are met, and the target storage partition to be upgraded is another storage partition that is not running, thereby ensuring that the vehicle can be used normally during the upgrade operation, and will not interfere with the stability of the system and the safety of vehicle operation, further improving the upgrade experience. At the same time, after the upgrade is completed, the system parameters that have been backed up in advance will be restored to the upgraded second storage partition, which can ensure that important system parameter data is not lost during the upgrade process, so that the upgraded partition can seamlessly undertake the operation tasks of the system before the upgrade, ensuring the normal use of vehicle functions and the consistency of user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0011] Figure 1 is a schematic diagram of a vehicle-mounted wireless communication module upgrade method provided in an embodiment of the present application;

[0012] Figure 2 It is a system startup flow chart of a vehicle-mounted wireless communication module upgrade method provided in an embodiment of the present application;

[0013] Figure 3 It is a system upgrade logic diagram in a vehicle-mounted wireless communication module upgrade method provided in an embodiment of the present application;

[0014] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0015] With the development of automobile intelligence and networking, on-board wireless communication modules (Telematics Control Unit, TCU) or T-box have become an important part of modern vehicles. These modules are responsible for realizing communication between vehicles and cloud platforms, supporting multiple functions such as navigation, voice calls, remote control, vehicle positioning, etc., and are one of the core components of the operation of the Internet of Vehicles system. To ensure the continuous optimization and security of these functions, OTA (Over-The-Air) technology is widely used. Through OTA technology, vehicles can remotely update firmware and software functions without returning to the factory, thereby improving user experience and optimizing system performance.

[0016] However, the existing OTA upgrade method mainly uses the RECOVERY mode for firmware upgrade. The RECOVERY mode is a minimized working mode. During the upgrade process, other functional modules of the system (such as wireless communication, navigation, voice calls, etc.) will be completely suspended, and only the functions related to the upgrade will be run. Although this method can ensure the focus of the upgrade operation, it also brings the following significant technical limitations:

[0017] 1. System function interruption: In RECOVERY mode, the core functions of the vehicle are completely unavailable, and users cannot use voice calls, network communications, remote unlocking, navigation positioning, etc. This functional interruption has a great negative impact on the user experience, especially when users cannot use navigation to plan trips or remote unlocking during vehicle upgrades, which seriously reduces the convenience of using intelligent vehicles.

[0018] 2. Risk of interruption during the upgrade process: During the upgrade process, if there are unexpected situations such as network interruption or power outage, the firmware upgrade may fail, resulting in the system being unable to start normally. In this case, the vehicle needs to be sent to a service point for manual recovery, which is not only time-consuming and labor-intensive, but also increases the financial burden on users. In addition, the existing RECOVERY mode lacks an effective fault-tolerant mechanism. Once the upgrade fails, the system cannot roll back to the previous stable state, further amplifying the risk of upgrade failure.

[0019] 3. Risk of system parameter loss: In the existing RECOVERY mode, the upgrade process may cause the loss of some key system parameters, such as the device's IMEI number, RFNV data, etc. These parameters are critical to the normal communication and functioning of the vehicle. If they are not properly backed up and restored during the upgrade process, the vehicle may be unable to reconnect to the network or lose certain remote service functions, thus affecting the owner's daily use and the overall performance of the vehicle.

[0020] 4. Long upgrade time: Since the upgrade process requires downloading and verifying a large firmware package (which may be hundreds of megabytes or even larger), the entire upgrade operation takes a long time. Users must wait for the upgrade to be completed before they can use the vehicle normally, especially in the era of frequent updates of the Internet of Vehicles. This model is obviously inconsistent with users' demand for fast upgrades.

[0021] 5. Insufficient system stability: In traditional systems with a single partition design, the system operating environment and the upgrade environment completely overlap. Once the firmware upgrade fails or the operation is improper, it may directly lead to a system crash and some functions of the vehicle (such as remote services or communication functions) will fail, thus affecting the user's daily use needs.

[0022] 6. The contradiction between the frequent upgrade demand and the existing model: With the development of intelligent technology, the iteration of vehicle software functions has accelerated, and the frequency of OTA upgrades has increased. However, each upgrade requires the vehicle to be unavailable. This frequent interruption conflicts with the modern user's demand for efficient and convenient vehicle experience.

[0023] In view of the above problems, the existing OTA upgrade technology needs to be improved to achieve the following goals:

[0024] 1. Support non-interruption upgrades: A new upgrade mechanism is used to ensure that the core functions of the vehicle remain normal during the upgrade process.

[0025] 2. Enhanced fault-tolerance mechanism: Provides system parameter backup function so that the upgraded partition can seamlessly take over the operating tasks of the system before the upgrade to ensure the integrity and continuity of key system functions before and after the upgrade.

[0026] 3. Improve system reliability: Ensure system stability and the security of the upgrade process through partition isolation and condition monitoring.

[0027] In view of the above problems, the present invention proposes an improved vehicle-mounted wireless communication module upgrade method to achieve non-interruption and high-reliability OTA upgrade, thereby improving the vehicle's usage efficiency and user experience.

[0028] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other under the premise of no contradiction.

[0029] An embodiment of the present invention relates to a vehicle-mounted wireless communication module upgrade method, which can be applied to vehicle-mounted terminals, mobile terminals, vehicle-mounted network devices and other devices. In the current system, the upgrade instruction is continuously monitored, and after the upgrade instruction is obtained, the firmware upgrade package is downloaded and the system and vehicle status are continuously monitored; wherein, the current system is located in the first storage partition; after the firmware upgrade package is downloaded and the system and vehicle status meet the preset upgrade conditions, the system parameters in the second storage partition are backed up, and the firmware upgrade package is written into the second storage partition; after the firmware upgrade package is written, if the system switching command is obtained, it is switched to the target system, and the backed-up system parameters are restored to the target system; wherein, the target system is located in the second storage partition. In the embodiment of the present invention, through the judgment of the multi-partition mechanism and the upgrade condition, it is ensured that the system and the vehicle perform the system upgrade of the target storage partition when the preset conditions are met, and the upgraded target storage partition is another storage partition that is not running, so as to ensure that the vehicle can be used normally during the upgrade operation, and will not interfere with the stability of the system and the safety of vehicle operation, further improving the upgrade experience. At the same time, after the upgrade is completed, the system parameters that have been backed up in advance will be restored to the upgraded second storage partition, which can ensure that important system parameter data is not lost during the upgrade process, so that the upgraded partition can seamlessly take over the operating tasks of the system before the upgrade, ensuring the normal use of vehicle functions and consistency of user experience.

[0030] The following is a detailed description of the implementation details of a vehicle-mounted wireless communication module upgrade method according to an embodiment of the present invention. The following content is only provided for the convenience of understanding the implementation details and is not necessary for the implementation of this solution.

[0031] like Figure 1 As shown, including steps 110 to 140, a method for upgrading a vehicle-mounted wireless communication module is provided.

[0032] In step 110, an independent system is created in each of the first storage partition and the second storage partition.

[0033] Specifically, in step 110, in order to improve the stability and fault tolerance of the vehicle-mounted wireless communication module, the storage medium (such as Flash storage) is divided into a first storage partition (A partition) and a second storage partition (B partition), and independent systems are created in the two partitions. The two systems run completely independently, each containing a complete image file (including modules such as Aboot, Boot, System, Modem, etc.). Through this division method, it is ensured that when a partition fails, the other partition can still run normally. In addition, the physical layout of the partition adopts an isolation design, following the principle that the physical space interval of the same image of the two independent systems is as large as possible, that is, the A partition is located in the low byte part of the Flash, and the B partition is located in the high byte part, so that bad blocks can be avoided during the operation of the flash, resulting in the same image in the AB partition system being damaged, so that the entire system cannot work normally, thereby improving the stability and reliability of the system.

[0034] Based on the above division, when the system starts, the following operations will be executed: Figure 2 The boot process shown in the figure. First, when the system starts, the primary boot loader (PBL) and the secondary boot loader (SBL) are loaded in sequence. The PBL is solidified in the SOC chip (provided by the manufacturer and cannot be modified), responsible for initializing the hardware and calling the SBL to load the partition table. The SBL parses the partition table information, chooses to activate the A partition or the B partition according to the system configuration, and loads the corresponding Aboot image. The layered design of the PBL and SBL realizes the flexibility of the boot logic. When a partition fails, the SBL can quickly switch to another healthy partition through the partition table information to ensure stable operation of the system.

[0035] Then, the Aboot image, as a key module in the boot process, is responsible for verifying the integrity and reliability of the Boot image. After the verification passes, the Boot image is loaded and the startup configuration information is passed; if the verification fails, Aboot will record the error information and trigger partition switching, trying to boot the system from another partition. The Aboot image adds a layer of protection mechanism during the system startup process to ensure that only images that pass the integrity check can be loaded and run. This design further enhances the reliability of the system and avoids system crashes caused by incorrect images.

[0036] Next, after loading, the Boot image will initialize the necessary hardware modules (such as storage controllers and communication interfaces), and then load the System image according to the startup command line parameters. At the same time, the Boot image will perform a mount check on the file system. If an abnormality is found, it will attempt to repair it. If the repair fails, it will record the abnormal information and trigger the partition switching logic to switch the running system to another partition system. The integrity of the file system is ensured through the detection and repair mechanism, and even if an abnormality occurs, normal operation can be quickly restored through partition switching.

[0037] Finally, after startup, the System image loads the core functional modules of the system, including the Modem subsystem, navigation system, and remote control function.

[0038] In step 120, in the current system, the upgrade instruction is continuously monitored, and after the system obtains the upgrade instruction, the firmware upgrade package is downloaded and the system and vehicle status are continuously monitored. Among them, the current system is located in the first storage partition, and the system to be upgraded is located in the second storage partition.

[0039] The system upgrade logic described in step 120 is as follows: Figure 3 As shown. When the current system is located in the first storage partition (partition A), the upgrade instruction is monitored in real time, and after receiving the upgrade instruction, the upgrade package is obtained from the request initiated by the telematics service provider (TSP) or the user device. During the operation of the system, the vehicle and system status will be continuously monitored to ensure that the download of the firmware package is carried out under safe and controllable conditions.

[0040] Optionally, the above upgrade instructions can be pushed by the Internet of Vehicles service provider according to preset conditions, or sent manually by the user. Specifically, TSP can actively push upgrade instructions to the vehicle based on the operating status of the vehicle system and the cloud management policy. This method is suitable for batch maintenance and emergency repair scenarios. For example, when TSP detects that the system version of the vehicle is lower than the latest version, it will automatically push upgrade instructions to ensure version consistency; if security vulnerabilities or serious problems are found in the current system, TSP can quickly trigger batch upgrade operations through the background to repair the vulnerabilities in time; in addition, when the cloud releases a firmware version that supports new functions, TSP can push upgrade instructions to bring functional enhancement experience to car owners.

[0041] In addition to the automatic push method, users can also manually send upgrade instructions through the vehicle terminal or mobile device. Car owners can select "Check for Updates" or "Upgrade Now" in the vehicle display menu, and the system will communicate with the cloud and obtain the latest firmware package. In addition, through the mobile phone app, users can remotely initiate upgrade requests, view the current system status and version information, and start the upgrade operation after confirmation. Users can also set an upgrade time window (such as idle time at night) so that the system can complete the firmware update at a specified time point. The manual trigger method provides users with more flexibility and control, especially for situations where users want to have clear control over the upgrade process.

[0042] Finally, the system supports a joint trigger mechanism between users and TSP to enhance the flexibility and security of the upgrade process. When TSP pushes an upgrade instruction, the system can prompt the user to confirm the operation, and the user decides whether to upgrade immediately based on the real-time status of the vehicle (such as whether it is driving or stationary). If the user chooses to postpone the upgrade, the system will automatically execute it when the conditions are met (such as the vehicle is turned off and the network signal is good). The joint trigger mechanism not only improves the system's automation capabilities, but also takes into account the user's active selection needs.

[0043] During the firmware download process, the system monitors its own operating status in real time to ensure that the upgrade operation does not interfere with the core functions of the currently running system. For example, the system dynamically monitors the CPU load level to ensure that the processor usage rate remains within a reasonable range when the download task is executed, and does not affect the operation of other key tasks. At the same time, the system monitors the memory usage rate to avoid slow system operation or failure due to excessive memory resources occupied by the download task. In addition, the system checks the sector status of the storage medium to ensure that the target storage partition is in normal operation without the risk of bad blocks or write conflicts. In terms of monitoring the vehicle's operating status, the system determines whether it is suitable for firmware download by sensing the vehicle's driving status, battery power, and whether it is connected to an external power supply. If the vehicle is in a driving state, the system needs to combine external sensing devices and positioning devices to determine the current state to avoid affecting driving safety; when the vehicle is stationary, especially when the engine is turned off and an external power supply is connected, the system will prioritize the download operation. In addition, if the battery power is low, the system will postpone the download task and prompt the user to connect to an external power supply to ensure the stability of the power supply during the upgrade process.

[0044] In step 130, after the firmware upgrade package is downloaded and the system and vehicle status meet the preset upgrade conditions, the system parameters in the second storage partition are backed up first, and then the firmware upgrade package is written to the second storage partition.

[0045] After the firmware upgrade package is downloaded, the system will immediately perform a comprehensive check on the downloaded firmware package to ensure that the firmware package has not been tampered with or damaged during transmission and storage. First, the system will verify the digital signature of the firmware package. By verifying the digital signature, it can be confirmed that the firmware package comes from a trusted official source to avoid attacks or damage to the system due to malicious firmware. Next, the system will use hash verification (such as SHA256) to confirm the integrity of the firmware package. Specifically, the system will calculate the hash value of the local firmware package and compare it with the original hash value provided by the server. If the comparison results are consistent, it means that the firmware package has not been modified or damaged during the download and storage process. If the comparison fails, the system will determine that there is a problem with the firmware package. In the case of a verification failure, the system will promptly prompt the user with the verification result, such as informing the user through the vehicle display or mobile app that the current firmware package is unavailable. At this time, the system will automatically or guide the user to re-download the firmware package to ensure that the subsequent upgrade operation uses a complete and trusted firmware file. Through the above verification process, the system can effectively improve the security of the firmware write operation and avoid partition unavailability or system crash due to firmware package damage or tampering.

[0046] Then, after the firmware verification is completed, as shown in 3, the system will conduct a comprehensive check of the current system status and vehicle status to ensure that the upgrade operation is carried out in a safe and stable environment. First, the system will evaluate whether the current processor and memory load are within the set safety range, such as CPU usage is less than 50% and memory usage is less than 80%. This check can prevent the system from failing due to resource overload during the write process. At the same time, the system will detect the status of the target partition (B partition), including whether there are bad blocks and whether the operating status of the sector meets the write requirements. The normality of the partition status directly determines the reliability of the write operation. In terms of vehicle status, the system will use multiple sensors to determine whether the vehicle is suitable for the upgrade operation. If the vehicle is stationary, such as parking and pulling the handbrake, the system will prioritize the upgrade operation; if the vehicle is driving, the system may delay the upgrade to avoid high-load tasks affecting driving safety; if the vehicle is driving at a low speed and there are few surrounding obstacles, it is considered that the current intelligent driving load or system load requirements are low, and it is judged to be suitable for upgrading. In addition, the battery power is also a key inspection item. The system will confirm whether the power level is above the set threshold (such as 30%), or whether the vehicle is connected to an external power source (such as a charging station) to prevent upgrade interruptions or unexpected system shutdowns due to insufficient power. Strict condition checks ensure the safety of the upgrade process and avoid upgrade failures due to poor vehicle or system status.

[0047] Then, after confirming that the upgrade conditions are met, the system will prioritize the backup of key system parameters of the current partition to prevent the loss of important data due to unexpected circumstances during the upgrade process. The backup content mainly includes the International Mobile Equipment Identity (IMEI), Radio Frequency Non-Volatile (RFNV) and other key parameters, such as device serial number, network configuration and user-defined settings. As the unique identification code of the vehicle communication module, IMEI is the basis for network registration and functional operation, and its integrity directly determines the normal operation of the communication module. RFNV data contains radio frequency calibration parameters, which are closely related to the performance and reliability of the communication module. Loss or damage may cause abnormal communication function. In addition, the backup operation will also cover other parameters closely related to user use, such as network connection settings, device serial number and personalized configuration of applications. In order to enhance the flexibility and pertinence of the backup, the user can customize the list of parameters to be backed up through the system interface when sending the upgrade command. In this way, data can be selectively backed up according to actual needs, reducing the storage resources occupied by invalid data and the system processing burden. For example, if the vehicle's network configuration does not need to be changed, the user can only back up IMEI and RFNV data, thereby optimizing the efficiency of the backup process. The above backed up data is not only stored in the device's memory, but also synchronized to the cloud, providing double protection for data recovery.

[0048] Finally, after completing the backup and verification, Figure 3 As shown, the system enters the firmware upgrade package writing phase, and gradually writes the firmware image to the second storage partition (partition B) to achieve system upgrade of the partition. First, the system writes the image files in the firmware upgrade package to the partitions in a predetermined order, including modules such as Aboot, Boot, System, and Modem. During the writing process, the system monitors the status of the target partition in real time to detect possible write conflicts or storage errors. The system checks whether the available space of the partition meets the writing requirements and detects whether there are bad blocks or write failures. If a problem is found, the system will immediately suspend the operation and try to repair the affected area or reallocate the write address. In addition, after each image file is written, the system will immediately perform segment verification. Segment verification ensures the integrity and accuracy of the written data by calculating the hash value of the written file and comparing it with the hash value of the original file. Through real-time monitoring and segment verification, the system achieves all-round protection of data integrity and stability during the writing process.

[0049] In step 140, after the firmware upgrade package is written, if a system switching command is obtained, the target system is switched to, and the backed-up system parameters are restored to the target system. The target system is located in the second storage partition.

[0050] First, after the firmware upgrade package is successfully written to partition B and passes verification, Figure 3 As shown in the figure, the system will continuously monitor whether it has received the command to switch to the target system. The triggering methods of the system switching command include: TSP push, TSP actively issues the switching command based on the vehicle status and upgrade completion; user manual trigger, the owner can manually confirm the upgrade completion through the vehicle device or mobile app and issue the switching command; automatic trigger, the system can automatically generate the switching command after detecting that the upgrade operation is completed and the conditions are met, without external intervention.

[0051] Then, after receiving the switching instruction, Figure 3 As shown, the system will update the partition table and start the target system. Specifically: update the partition table, switch the active partition mark in the partition table from A partition to B partition, and ensure that the system is loaded from B partition by default at the next startup; restart the system, after the system restarts, load the Aboot image of B partition according to the updated partition table, and start the upgraded target system; start verification, after the Aboot image of B partition passes the verification, load the Boot image and System image, and complete the normal startup of the target system.

[0052] Finally, after the target system is successfully started, such as Figure 3 As shown, the system will enter the initialization phase, load and restore the key system parameters that were previously backed up to ensure that the new system can seamlessly inherit the functions of the system before the upgrade. These parameters are critical to the normal operation of the system and the core functions of the vehicle. The specific recovery process is as follows: First, the system will load the backed-up system parameters from the local storage. These parameters include IMEI, RFNV, device serial number, etc. If the local backup data is detected to be damaged or lost during the recovery process, the system will automatically synchronize the corresponding parameters from the cloud backup. Finally, the system will update the restored parameters to the configuration area of ​​the target partition and initialize the functional modules related to these parameters, such as network registration of the communication module and calibration of the RF module. In this way, the new system can quickly enter the normal working state, and the core functions of the vehicle such as communication, navigation, remote control, etc. can run seamlessly to ensure the consistency of user experience.

[0053] Based on step 140, if the target system fails to start, switch to the system of the first storage partition and write the system data of the first storage partition into the second storage partition. Specifically, if the target system fails to start (such as the Boot image is damaged or the system parameter recovery is abnormal), the system will automatically perform a rollback operation, including: updating the partition table, switching the active partition back to partition A and restarting the system. Rewrite the system data of partition A into partition B, and repair the target system image or parameter configuration. Send a rollback message to the owner or TSP, prompting the upgrade failure and suggesting to check the system status. In this way, the fault rollback mechanism greatly improves the fault tolerance of the system, and even if the upgrade fails, the vehicle function can be quickly restored to a stable state.

[0054] Based on the above steps 110 to 140, it also supports the creation of a plurality of partitions greater than two and a corresponding multi-system architecture for realizing multi-system backup, upgrade and switching functions.

[0055] In the scenario of expansion to multiple partitions and systems, the storage medium can be divided into multiple independent storage partitions, such as A partition, B partition, C partition, and D partition. Each partition contains a complete system image file, including Aboot, Boot, System, and Modem modules, and all partitions operate independently of each other to ensure that even if one partition fails, other partitions can still work normally. The partition layout continues to follow the principle of physical isolation, such as placing the A partition in the low-byte area of ​​the memory, and the other partitions are arranged in turn to higher storage spaces, which can minimize the impact of bad blocks on multiple partitions at the same time.

[0056] During the system startup process, after PBL initializes the hardware, it calls SBL, loads the partition table, and supports information parsing of multiple partitions. SBL dynamically selects the partition to be started based on the information recorded in the partition table, for example, selects a healthy partition from partition A, partition B, or partition C, and loads the corresponding Aboot image. Through real-time monitoring of the partition status, SBL can flexibly manage partition switching operations. Even if the current partition fails, it can quickly switch to other backup partitions to continue running.

[0057] In the parameter backup operation before upgrading, the key data of the partition to be backed up can be backed up to multiple partitions. For example, when the B partition needs to be backed up, the system parameters, including IMEI, RFNV data and serial number, can be backed up to the C and D partitions at the same time. In addition, these backup data can also be stored synchronously in the cloud to provide additional recovery protection, so as to achieve multiple redundant protection.

[0058] When the target partition fails to start, the system will automatically roll back to another healthy backup partition and repair the image file or configuration data of the failed partition through log analysis. During the switching process, the system will give priority to activating the partition with good health and the latest version to ensure that the vehicle function is not affected. The system will also help users or service providers understand the operation of the partition by recording the partition status information in real time.

[0059] This multi-partition architecture provides higher fault tolerance and flexibility for the vehicle-mounted wireless communication module. For example, when the vehicle needs to be updated frequently, the B and C partitions can be upgraded in stages while the A partition is running normally; or partitions can be allocated separately for different functional modules (such as navigation system, entertainment system) to achieve modular management. This design not only improves the reliability of the system, but also can adapt to more complex scenarios and future functional expansion requirements.

[0060] In the embodiment of the present invention, through the judgment of the multi-partition mechanism and the upgrade conditions, it is ensured that the system and the vehicle perform the system upgrade of the target storage partition when the preset conditions are met, and the target storage partition to be upgraded is another storage partition that is not running, thereby ensuring that the vehicle can be used normally during the upgrade operation, and will not interfere with the stability of the system and the safety of vehicle operation, further improving the upgrade experience. At the same time, after the upgrade is completed, the system parameters that have been backed up in advance will be restored to the upgraded second storage partition, which can ensure that important system parameter data is not lost during the upgrade process, so that the upgraded partition can seamlessly undertake the operation tasks of the system before the upgrade, ensuring the normal use of vehicle functions and the consistency of user experience.

[0061] The steps of the above method are divided only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0062] In addition, the examples mentioned in the above embodiments can be freely combined, and any combination can be understood as an embodiment. The "embodiment" or "example" appearing in various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It can be understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0063] Another embodiment of the present invention relates to a terminal / electronic device / server, such as Figure 4As shown, it includes at least one processor 401; and a memory 402 that is communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor so that the at least one processor can execute a vehicle-mounted wireless communication module upgrade method as described above.

[0064] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0065] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0066] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0067] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0068] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present invention, and that in actual applications, various changes may be made in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A method for upgrading a vehicle-mounted wireless communication module, characterized in that: include: In the current system, continuously monitor the upgrade instruction, after obtaining the upgrade instruction, download the firmware upgrade package and continuously monitor the system and vehicle status; wherein the current system is located in the first storage partition; After the firmware upgrade package is downloaded and the system and vehicle status meet the preset upgrade conditions, the system parameters in the second storage partition are backed up and the firmware upgrade package is written into the second storage partition; After the firmware upgrade package is written, if a system switching command is obtained, the target system is switched to, and the backed-up system parameters are restored to the target system; wherein the target system is located in the second storage partition.

2. The vehicle-mounted wireless communication module upgrade method according to claim 1, characterized in that: Also includes: When obtaining the upgrade instruction, obtaining a list of parameters to be backed up; The backing up of the system parameters in the second storage partition includes: backing up the system parameters in the second storage partition based on the list of parameters to be backed up.

3. The vehicle-mounted wireless communication module upgrade method according to claim 2, characterized in that: The backed-up system parameters are stored in the memory and the cloud.

4. The vehicle-mounted wireless communication module upgrade method according to claim 2, characterized in that: The backup parameter list includes IMEI and RFNV data.

5. The vehicle-mounted wireless communication module upgrade method according to claim 1, characterized in that: The preset upgrade conditions include system conditions and vehicle conditions; The system condition includes whether the processor is within a preset processor load range, whether the memory is within a preset memory load range, and whether the sector operation state of the second storage partition satisfies a preset sector state. The vehicle condition includes whether the vehicle belongs to a safe driving environment.

6. The vehicle-mounted wireless communication module upgrade method according to claim 1, characterized in that: After the firmware upgrade package is downloaded, the following steps are also included: The firmware upgrade package is verified, and if the verification fails, the user is prompted with the verification result and the firmware upgrade package is downloaded again.

7. The vehicle-mounted wireless communication module upgrade method according to any one of claims 1 to 6, characterized in that: The upgrade instruction is pushed by the Internet of Vehicles service provider according to preset conditions, or sent manually by the user.

8. The vehicle-mounted wireless communication module upgrade method according to claim 1, characterized in that: After the switching to the target system, the method further includes: If the target system fails to start, the system is switched to the first storage partition, and the system data of the first storage partition is written into the second storage partition.

9. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle-mounted wireless communication module upgrading method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the vehicle-mounted wireless communication module upgrading method according to any one of claims 1 to 8 is implemented.

Images