Vehicle software upgrade method and apparatus, terminal device and storage medium

Abstract

The present application discloses a vehicle software upgrade method and apparatus, a terminal device and a storage medium. The method comprises: in response to a vehicle OTA upgrade instruction, acquiring a target upgrade software package, the target upgrade software package being used for upgrading initial-version software of a core domain controller; installing the target upgrade software package to a second partition that is different from a first partition where the initial-version software is stored, to obtain upgraded-version software of the core domain controller; and in response to an authorization instruction triggered by a user, controlling state switching of the first partition and the second partition so as to run the upgraded-version software.

Description

Vehicle software upgrade method, device, terminal device and storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application No. 202410011325.3 filed on January 2, 2024, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of vehicle electronic technology, and in particular to a vehicle software upgrading method, apparatus, terminal device, and storage medium. Background Art

[0004] With the development of Internet of Vehicles (IoV) services and the continuous evolution of electronic and electrical architecture, most cars now support OTA (Over the Air, vehicle remote software download) services. However, with the development of vehicle-side operating systems and autonomous driving, the software packages required for each OTA are often too large. Oversized software packages are relatively full during the installation process, which has an adverse impact on the user experience and the risk of low battery in the vehicle.

[0005] However, existing vehicle software upgrade technologies utilize traditional electronic and electrical architectures that lack support for A / B partitioning, making it impossible to perform system upgrades while the vehicle is in motion. Furthermore, due to the large size of the overall installation package, the software package installation is slow after the user triggers the authorization command for installation. In summary, existing technologies suffer from the problem of slow vehicle software upgrades. Summary of the Invention

[0006] The main purpose of this application is to provide a vehicle software upgrade method, device, terminal device and storage medium, aiming to solve the problem of slow vehicle software upgrade.

[0007] To achieve the above objectives, the present application provides a vehicle software upgrade method, which is applied to a vehicle remote software download OTA upgrade scenario, and the vehicle software upgrade method includes the following steps:

[0008] In response to a vehicle OTA upgrade instruction, obtaining a target upgrade software package, wherein the target upgrade software package is used to upgrade an initial version of software of a core domain controller;

[0009] Installing the target upgrade software package to a second partition different from the first partition where the initial version software is stored, to obtain an upgraded version software of the core domain controller;

[0010] In response to an authorization instruction triggered by a user, the first partition and the second partition are controlled to switch states so as to run the upgraded version software.

[0011] In one embodiment, the method is applied to a vehicle, and the step of obtaining a target upgrade software package in response to a vehicle OTA upgrade instruction, wherein the target upgrade software package is used to upgrade the initial software of the core domain controller, includes:

[0012] In response to the vehicle OTA upgrade instruction, establish a communication connection with the OTA cloud and receive the OTA upgrade task issued by the OTA cloud;

[0013] Detecting the system status of the vehicle side, and if the system status of the vehicle side meets the preset conditions, synchronizing the OTA upgrade task;

[0014] Silently download the OTA software package corresponding to the OTA upgrade task, and determine the target software upgrade package from the OTA software package.

[0015] In one embodiment, before the step of controlling the first partition and the second partition to switch states to run the upgraded version software in response to the authorization instruction triggered by the user, the step includes:

[0016] In response to the authorization instruction triggered by the user, the first type ECU and the second type ECU are installed in sequence according to the preset electronic control unit ECU flashing order. The first type ECU includes the high-voltage ECU and the power ECU, and the second type ECU includes the body ECU, the chassis ECU and the network ECU.

[0017] In one embodiment, the step of controlling the first partition and the second partition to switch states to run the upgraded version software in response to the authorization instruction triggered by the user includes:

[0018] In response to the authorization instruction triggered by the user, by updating the first vehicle-side field mark data corresponding to the first partition and the second vehicle-side field mark data corresponding to the second partition, the first partition is controlled to switch from the running state to the standby state, and the second partition is controlled to switch from the standby state to the running state to run the upgraded version software.

[0019] In one embodiment, the step of controlling the first partition to switch from a running state to a standby state and controlling the second partition to switch from a standby state to a running state by updating first vehicle-side field tag data corresponding to the first partition and second vehicle-side field tag data corresponding to the second partition in response to a user-triggered authorization instruction to run the upgraded software includes:

[0020] Verifying the upgraded version of the software by querying the updated first vehicle-side field tag data and the updated second vehicle-side field tag data to obtain a verification result;

[0021] According to the verification result, a corresponding result reporting operation is performed.

[0022] In one embodiment, the step of performing a corresponding result reporting operation according to the verification result includes:

[0023] If the verification result is successful, a corresponding pop-up message is generated, and the pop-up message is used to visualize the verification result;

[0024] If the verification result is a verification failure, the verification result is reported to the OTA cloud, and a partition switching rejection instruction sent by the OTA cloud is received to stop switching the operating status of the first partition and the second partition.

[0025] In one embodiment, the vehicle software upgrade method further includes:

[0026] A communication connection is established with the user's mobile communication terminal through the OTA cloud to receive the user's authorization instructions, which include immediate upgrade instructions, scheduled upgrade instructions, and nighttime upgrade instructions.

[0027] In addition, to achieve the above-mentioned purpose, the present application also provides a vehicle software upgrade device, the device comprising:

[0028] A data acquisition module, configured to acquire a target upgrade software package in response to a vehicle OTA upgrade instruction, wherein the target upgrade software package is used to upgrade an initial version of the core domain controller software;

[0029] a storage partition module, configured to install the target upgrade software package into a second partition different from the first partition where the initial version software is stored, to obtain an upgraded version software of the core domain controller;

[0030] The partition switching module is used to control the state switching between the first partition and the second partition in response to the authorization instruction triggered by the user to run the upgraded version software.

[0031] In one embodiment, the data acquisition module is further configured to:

[0032] In response to the vehicle OTA upgrade instruction, establish a communication connection with the OTA cloud and receive the OTA upgrade task issued by the OTA cloud;

[0033] Detecting the system status of the vehicle side, and if the system status of the vehicle side meets the preset conditions, synchronizing the OTA upgrade task;

[0034] Silently download the OTA software package corresponding to the OTA upgrade task, and determine the target software upgrade package from the OTA software package.

[0035] In one embodiment, the partition switching module is further configured to:

[0036] In response to the authorization instruction triggered by the user, the first type ECU and the second type ECU are installed in sequence according to the preset electronic control unit ECU flashing order. The first type ECU includes the high-voltage ECU and the power ECU, and the second type ECU includes the body ECU, the chassis ECU and the network ECU.

[0037] In one embodiment, the partition switching module is further configured to:

[0038] In response to the authorization instruction triggered by the user, by updating the first vehicle-side field mark data corresponding to the first partition and the second vehicle-side field mark data corresponding to the second partition, the first partition is controlled to switch from the running state to the standby state, and the second partition is controlled to switch from the standby state to the running state to run the upgraded version software.

[0039] In one embodiment, the partition switching module is further configured to:

[0040] Verifying the upgraded version of the software by querying the updated first vehicle-side field tag data and the updated second vehicle-side field tag data to obtain a verification result;

[0041] According to the verification result, a corresponding result reporting operation is performed.

[0042] In one embodiment, the partition switching module is further configured to:

[0043] If the verification result is successful, a corresponding pop-up message is generated, and the pop-up message is used to visualize the verification result;

[0044] If the verification result is a verification failure, the verification result is reported to the OTA cloud, and a partition switching rejection instruction sent by the OTA cloud is received to stop switching the operating status of the first partition and the second partition.

[0045] In one embodiment, the partition switching module is further configured to:

[0046] A communication connection is established with the user's mobile communication terminal through the OTA cloud to receive the user's authorization instructions, which include immediate upgrade instructions, scheduled upgrade instructions, and nighttime upgrade instructions.

[0047] In addition, to achieve the above-mentioned purpose, the present application also provides a terminal device, which includes a memory and a processor, and the memory stores a vehicle software upgrade program that can be run on the processor. When the vehicle software upgrade program is executed by the processor, the vehicle software upgrade method as described above is implemented.

[0048] In addition, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a vehicle software upgrade program is stored. When the vehicle software upgrade program is executed by a processor, the vehicle software upgrade method as described above is implemented.

[0049] The embodiments of the present application propose a vehicle software upgrade method, apparatus, terminal device, and storage medium. The method obtains a target upgrade software package in response to a vehicle OTA upgrade instruction. The target upgrade software package is used to upgrade the initial version software of the core domain controller; the target upgrade software package is installed in a second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; and in response to an authorization instruction triggered by a user, the first partition and the second partition are controlled to switch states to run the upgraded version software. Based on obtaining the target upgrade software package corresponding to the core domain controller, the embodiments of the present application partition the storage area and install the target upgrade software package in an area different from the initial version software. In this way, when the user triggers the authorization instruction, only the state switching between the first partition and the second partition is required, thereby improving the upgrade speed of the vehicle software. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] FIG1 is a schematic diagram of the functional modules of a terminal device to which the vehicle software upgrade device of the present application belongs;

[0051] FIG2 is a flow chart of a first exemplary embodiment of a vehicle software upgrade method of the present application;

[0052] FIG3 is a schematic diagram of the basic architecture for implementing rapid OTA upgrade based on A / B partitions in the first exemplary embodiment of the vehicle software upgrade method of the present application;

[0053] FIG4 is a flow chart of a second exemplary embodiment of a vehicle software upgrade method of the present application;

[0054] FIG5 is a flowchart of a third exemplary embodiment of a vehicle software upgrade method of the present application;

[0055] FIG6 is a schematic diagram of the business logic of OTA rapid upgrade in the fourth exemplary embodiment of the vehicle software upgrade method of the present application;

[0056] FIG7 is a schematic diagram showing the difference between OTA rapid upgrade and traditional upgrade in the fourth exemplary embodiment of the vehicle software upgrade method of the present application.

[0057] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0058] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0059] The main solution of the embodiment of the present application is: in response to the vehicle OTA upgrade instruction, obtain the target upgrade software package, which is used to upgrade the initial version software of the core domain controller; install the target upgrade software package to a second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; in response to the authorization instruction triggered by the user, control the first partition and the second partition to switch states to run the upgraded version software.

[0060] The embodiments of this application take into account that the current industry's existing vehicle software upgrade technology uses a traditional electronic and electrical architecture that does not support A / B partitioning, making it impossible to perform system upgrades while the vehicle is in motion. Furthermore, due to the large size of the overall installation package, the software package installation speed is relatively slow after the user triggers the authorization instruction for software package installation. In summary, the existing technology suffers from the problem of slow vehicle software upgrades.

[0061] Based on this, an embodiment of the present application provides a solution. On the basis of obtaining the target upgrade software package corresponding to the core domain controller, the target upgrade software package is installed in an area different from the initial version software by partitioning the storage area. In this way, when the user triggers the authorization instruction, only the status of the first partition and the second partition needs to be switched, thereby improving the upgrade speed of the vehicle software.

[0062] Specifically, referring to Figure 1 , Figure 1 is a schematic diagram of the functional modules of a terminal device to which the vehicle software upgrade device of the present application belongs. The vehicle software upgrade device can be a device independent of the terminal device that is capable of upgrading vehicle software and can be hosted on the terminal device in the form of hardware or software. The terminal device can be a smart mobile terminal with data processing capabilities, or a fixed terminal device or server with data processing capabilities. In addition, the vehicle software upgrade device can also be hosted in a vehicle software upgrade system.

[0063] In this embodiment, the terminal device to which the vehicle software upgrading apparatus belongs includes at least an output module 110 , a processor 120 , a memory 130 and a communication module 140 .

[0064] The memory 130 stores an operating system and a vehicle software upgrade program. The output module 110 may be a display screen, etc. The communication module 140 may include a WIFI module, a mobile communication module, and a Bluetooth module, etc., and communicates with an external device or server through the communication module 140.

[0065] Among them, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are implemented: in response to the vehicle OTA upgrade instruction, the target upgrade software package is obtained, and the target upgrade software package is used to upgrade the initial version software of the core domain controller; the target upgrade software package is installed to a second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; in response to the authorization instruction triggered by the user, the first partition and the second partition are controlled to switch states to run the upgraded version software.

[0066] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: in response to the vehicle OTA upgrade instruction, a communication connection is established with the OTA cloud, and the OTA upgrade task issued by the OTA cloud is received; the system status of the vehicle side is detected, and if the system status of the vehicle side meets the preset conditions, the OTA upgrade task is synchronized; the OTA software package corresponding to the OTA upgrade task is silently downloaded, and the target software upgrade package is determined from the OTA software package.

[0067] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: in response to the authorization instruction triggered by the user, the first type ECU and the second type ECU are installed in sequence according to the preset electronic control unit ECU flashing order, the first type ECU includes a high-voltage ECU and a power ECU, and the second type ECU includes a body ECU, a chassis ECU and a network ECU.

[0068] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: in response to the authorization instruction triggered by the user, by updating the first vehicle-side field tag data corresponding to the first partition and the second vehicle-side field tag data corresponding to the second partition, the first partition is controlled to switch from the running state to the standby state, and the second partition is controlled to switch from the standby state to the running state to run the upgraded version of the software.

[0069] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: by querying the updated first vehicle-end field tag data and the updated second vehicle-end field tag data, the upgraded version software is verified to obtain a verification result; based on the verification result, the corresponding result reporting operation is performed.

[0070] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: if the verification result is a successful verification, a corresponding pop-up message is generated, and the pop-up message is used to visualize the verification result; if the verification result is a failed verification, the verification result is reported to the OTA cloud, and a partition switching rejection instruction sent by the OTA cloud is received to stop switching the operating status of the first partition and the second partition.

[0071] In one embodiment, when the vehicle software upgrade program in the memory 130 is executed by the processor, the following steps are also implemented: establishing a communication connection with the user's mobile communication terminal through the OTA cloud to receive the user's authorization instructions, the authorization instructions including immediate upgrade instructions, scheduled upgrade instructions and nighttime upgrade instructions.

[0072] This embodiment adopts the above scheme, and obtains the target upgrade software package by responding to the vehicle OTA upgrade instruction, and the target upgrade software package is used to upgrade the initial version software of the core domain controller; the target upgrade software package is installed to the second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; and in response to the authorization instruction triggered by the user, the first partition and the second partition are controlled to switch states to run the upgraded version software. Based on obtaining the target upgrade software package corresponding to the core domain controller, the embodiment of the present application partitions the storage area and installs the target upgrade software package in an area different from the initial version software. In this way, when the user triggers the authorization instruction, only the state switching between the first partition and the second partition is required, thereby improving the upgrade speed of the vehicle software.

[0073] Based on the above terminal device architecture but not limited to the above architecture, an embodiment of the method of the present application is proposed.

[0074] Referring to Figure 2, Figure 2 is a flow chart of a first exemplary embodiment of a vehicle software upgrade method of the present application. The method is applied to a vehicle remote software download OTA upgrade scenario, and the vehicle software upgrade method includes:

[0075] Step S10: In response to the vehicle OTA upgrade instruction, a target upgrade software package is obtained, where the target upgrade software package is used to upgrade the initial version software of the core domain controller.

[0076] It should be noted that with the continuous improvement of the degree of vehicle electrification, OTA is an increasingly popular remote vehicle software upgrade method. In OTA upgrades, it is necessary to use vehicle communication technology (such as 4G, 5G, vehicle networking, etc.) to achieve remote communication, use encryption algorithms and digital signatures and other technologies to ensure the secure transmission of data, and use cloud computing platforms to achieve data storage and distribution, etc. In this embodiment, after the vehicle OTA upgrade instruction is generated, the vehicle side will respond to this instruction to perform the vehicle OTA upgrade, and the vehicle OTA upgrade mainly downloads and installs the OTA software package. Among them, the speed of OTA software package installation mainly depends on the size of the software package. From a practical point of view, the core domain controller of the vehicle, including DHU (cockpit domain controller) and ADCU (autonomous driving domain controller), has the largest corresponding software package volume, the longest installation time, and is most likely to cause installation failure. Therefore, the vehicle software upgrade method proposed in the embodiment of the present application adopts A / B storage partitioning for the storage corresponding to the core domain controller, that is, the initial version of the software is installed in area A (also known as the first partition), and the upgraded version of the software package is installed in area B (also known as the second partition).

[0077] Referring to FIG. 3 , FIG. 3 is a schematic diagram of the basic architecture for implementing fast OTA upgrades based on A / B partitions in an embodiment of the present application. As shown in FIG. 3 , the process of implementing fast OTA upgrades mainly involves interactions between three terminals, namely, the OTA cloud, the vehicle terminal, and the mobile terminal. The structural relationship between the three terminals is described as follows:

[0078] OTA Cloud: OTA Cloud is also known as OTA Server, which supports basic OTA operations. The OTA cloud includes a service layer and an interface layer. The service layer is used for task management, BSS (electric vehicle battery replacement) management, software management, chart statistics, fault diagnosis, vehicle management, VDN (Vehicle Data Network) management, digital containers, log management, nightly upgrades and rapid upgrades; the interface layer includes OS (operating system) version, historical information, installation instructions, instruction cancellation, task request, OTA settings, synchronization status, task creation, task cancellation, blacklist and APP (application) control. The OS version interface is used to connect to TSP (Telematics Service Provider), and the historical information interface is used to connect to GTSP (Global Automotive Telematics Service Provider). The installation instructions are issued through CDN (Content Delivery Network), the instruction cancellation is implemented through OCSP (Online Certificate Status Protocol), the task creation is implemented through the script development tool TC, the task cancellation is implemented through the production execution system MES system, the blacklist is generated by blacklist query through the car network Carcom, and the APP control is implemented through the security certificate PKI.

[0079] On the vehicle side: The vehicle communicates with the OTA cloud via the TCAM (on-board intelligent communication terminal). The TCAM is equivalent to the TBOX (on-board network box), integrating vehicle-mounted network and wireless communication functions. It can also be simply understood as a box with built-in communication capabilities. As shown in Figure 3, the vehicle-side TCAM enables vehicle-cloud communication (i.e., communication between the vehicle and the cloud), software downloads, status reporting (the vehicle reports system status to the cloud), remote wake-up, and other functions. The vehicle side includes the BGM (on-board controller), DHU, and ADCU. Both the DHU and ADCU are divided into A / B zones to control the various ECU modules. ECU1 to ECUs in Figure 3 refer to the first to the sth ECU module. It is worth noting that, in actual implementation, it is possible to partition the storage area of ​​only the DHU or only the ADCU into A / B zones to reduce the storage space waste caused by partitioning.

[0080] Mobile: This can also be any other mobile communication device with mobile communication capabilities, including the car-connected vehicle control center, iOS (iOS), and Android apps. Users can establish a communication connection with the OTA cloud server to control the app or issue authorization commands for software upgrades, such as immediate, scheduled, and nightly upgrades.

[0081] Furthermore, in this embodiment, in step S10, in response to the vehicle OTA upgrade instruction, a target upgrade software package is obtained, where the target upgrade software package is used to upgrade the initial version software of the core domain controller and includes:

[0082] Step A1: In response to the vehicle OTA upgrade instruction, establish a communication connection with the OTA cloud and receive the OTA upgrade task issued by the OTA cloud;

[0083] Step A2: detecting the system status of the vehicle side, and if the system status of the vehicle side meets the preset conditions, synchronizing the OTA upgrade task;

[0084] Step A3: silently download the OTA software package corresponding to the OTA upgrade task, and determine the target software upgrade package from the OTA software package.

[0085] Specifically, this embodiment establishes a communication connection between the vehicle and the OTA cloud to receive the OTA upgrade task issued by the OTA cloud. At the same time, the vehicle will detect its own system status, such as the remaining battery status and network connection status, to ensure that the current vehicle system status is suitable for OTA upgrade and synchronize the OTA upgrade task to the current task list. After the OTA task synchronization is completed, the vehicle will silently download the OTA software package corresponding to the OTA upgrade task. The silent download refers to the automatic download of relevant data in the background without notifying the user. Then, this embodiment determines the software package corresponding to the DHU and / or ADCU as the target software upgrade package.

[0086] Step S20: Install the target upgrade software package to a second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller.

[0087] Specifically, in this embodiment, the initial version of the core domain controller software is stored in the first partition. Therefore, the target upgrade software package should be installed in the idle second partition to obtain the upgraded version of the core domain controller software. The first partition and the second partition can back up each other to increase the vehicle system's availability.

[0088] Step S30: In response to the authorization instruction triggered by the user, the first partition and the second partition are controlled to switch states so as to run the upgraded version software.

[0089] Specifically, when the user stops driving the vehicle, turns off the engine and powers off the vehicle, or removes the seat belt while parking, a pop-up window will appear on the vehicle-side TCAM screen to remind the user that a system update is available. The user clicks the confirmation button on the vehicle-side TCAM to trigger the authorization instruction.

[0090] Furthermore, in this embodiment, step S30, in response to the authorization instruction triggered by the user, controlling the first partition and the second partition to switch states so as to run the upgraded version software includes:

[0091] Step S301, in response to the authorization instruction triggered by the user, by updating the first vehicle-side field mark data corresponding to the first partition and the second vehicle-side field mark data corresponding to the second partition, the first partition is controlled to switch from the running state to the standby state, and the second partition is controlled to switch from the standby state to the running state to run the upgraded version software.

[0092] Specifically, this embodiment uses vehicle-side field marking data to mark the status of the first partition and the second partition. The vehicle-side field marking data of the first partition is the first vehicle-side field marking data, and the vehicle-side field marking data of the second partition is the second vehicle-side field marking data. The specific naming rules of the vehicle-side field marking data are as follows:

[0093] Field 1: zone, 1 represents the running zone, 0 represents the standby zone;

[0094] Field 2: Enable, 1 means activated, 0 means not activated;

[0095] Field 3: state, 1 means installed, 0 means not installed;

[0096] Field 4: space, marking the remaining storage space;

[0097] When the vehicle leaves the factory, the default state of the first partition (also known as zone A) of the core domain controller (DHU and / or ADCU) is as follows:

[0098] zone: 1;

[0099] Enable: 1;

[0100] state: 1;

[0101] Space: marks the remaining storage space of the first partition, in MB, such as 1024MB;

[0102] Similarly, when the vehicle leaves the factory, the default state of the second partition (i.e., Zone B) of the core domain control (DHU and / or ADCU) is set as follows:

[0103] zone: 0;

[0104] Enable: 0;

[0105] state: 0;

[0106] Space: marks the remaining storage space of the second partition in MB, such as 5120MB.

[0107] It is understandable that the process of silently downloading the OTA software package on the vehicle side can be carried out while the vehicle is in motion. This process does not require notifying the user. The OTA software package can be stored in the spare second partition (i.e., area B). When the user triggers the authorization instruction, it is only necessary to switch the state of the first partition and the second partition. Based on the above description of the naming rules for the vehicle-side field marking data, during the OTA upgrade process, the update process of the first vehicle-side field identification data corresponding to the first partition (area A) and the second vehicle-side field identification data of the second partition (area B) is shown in the following Table 1:

[0108] Table 1

[0109] In one embodiment, the vehicle software upgrade method proposed in the embodiment of the present application further includes:

[0110] A communication connection is established between the OTA cloud and the user's mobile communication terminal to receive the user's authorization instruction, which includes an immediate upgrade instruction, a scheduled upgrade instruction, and a nighttime upgrade instruction.

[0111] After receiving the authorization instruction, the vehicle side responds to the authorization instruction and completes the software activation of the second partition. Among them, the authorization instruction includes an immediate upgrade instruction, a scheduled upgrade instruction, and a nighttime upgrade instruction. After the immediate upgrade instruction is triggered, the vehicle side will immediately perform an OTA upgrade; after the scheduled upgrade instruction is triggered, the vehicle side will obtain the scheduled upgrade time set by the user through a pop-up window, and start the built-in timer to automatically perform an OTA upgrade at the preset time; when the nighttime upgrade instruction is triggered, the vehicle side will start a silent OTA upgrade at night. It can be understood that the user enters the authorization information on the mobile phone side (or other mobile communication terminal), connects to the OTA cloud through the mobile phone side, and conveys the authorization instruction to the vehicle side through the OTA cloud.

[0112] This embodiment adopts the above scheme, specifically by responding to the vehicle OTA upgrade instruction, obtaining the target upgrade software package, the target upgrade software package is used to upgrade the initial version software of the core domain controller; installing the target upgrade software package to the second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; and responding to the authorization instruction triggered by the user, controlling the first partition and the second partition to switch states to run the upgraded version software. Based on obtaining the target upgrade software package corresponding to the core domain controller, the embodiment of the present application partitions the storage area and installs the target upgrade software package in an area different from the initial version software. In this way, when the user triggers the authorization instruction, only the state switching between the first partition and the second partition is required, thereby improving the upgrade speed of the vehicle software.

[0113] 4 , which is a flow chart of a second exemplary embodiment of a vehicle software upgrade method of the present application.

[0114] Based on the first embodiment, the second embodiment of the present application is proposed. The difference between the second embodiment of the present application and the first embodiment is that:

[0115] In this embodiment, step S30, in response to the authorization instruction triggered by the user, controlling the first partition and the second partition to switch states to run the upgraded version software, includes:

[0116] Step S25, in response to the authorization instruction triggered by the user, the first type ECU and the second type ECU are installed in sequence according to the preset electronic control unit ECU flashing order, the first type ECU includes the high-voltage ECU and the power ECU, and the second type ECU includes the body ECU, the chassis ECU and the network ECU.

[0117] Specifically, the vehicle OTA upgrade process includes not only the installation of core domain controllers (such as the DHU and / or ADCU), but also the installation of other ECUs. When the user stops driving the vehicle, turns off the engine, or unbuffers the seatbelt while parked, a pop-up window will appear on the vehicle's TCAM screen, reminding the user that a system update is available. The user clicks the confirmation button on the vehicle's TCAM to trigger the authorization instruction. At this point, the vehicle will first complete the installation of the first type of ECUs, followed by the installation of the second type of ECUs. The first type of ECUs includes high-voltage ECUs and power ECUs, while the second type of ECUs includes body ECUs, chassis ECUs, and network ECUs. The first type of ECUs typically involve the vehicle's core control systems, such as the powertrain and high-voltage system. These ECUs have a significant impact on the vehicle's safety and stability. Therefore, to ensure the normal operation and safety of the vehicle during the upgrade process, the update of these critical control systems must be completed first. At the same time, the update of the first type of ECUs may affect the functionality and compatibility of other ECUs. By completing the installation of the first type of ECUs first, it can be ensured that the vehicle can correctly adapt to the new control system during the upgrade process and maintain the stability and consistency of the overall system. Furthermore, after completing the installation of the first category of ECUs, the vehicle can better adapt to the new control system during subsequent installations, providing a better foundation for upgrading other ECUs. Similarly, prioritizing the installation of the first category of ECUs can reduce the overall system load by completing the update of these important ECUs first, providing a more stable environment for subsequent DHU and / or ADCU flashing.

[0118] This embodiment, through the above solution, specifically responds to the user-triggered authorization instruction and sequentially installs the first and second types of ECUs according to a preset ECU flashing sequence. The first type of ECUs includes the high-voltage ECU and the power ECU, and the second type of ECUs includes the body ECU, chassis ECU, and network ECU. By optimizing the ECU flashing sequence, this embodiment reduces the probability of failure caused by flashing the DHU and / or ADCU, thereby improving the overall OTA upgrade success rate.

[0119] 5 , which is a flowchart of a third exemplary embodiment of a vehicle software upgrade method of the present application.

[0120] Based on the first embodiment, a third embodiment of the present application is proposed. The difference between the third embodiment of the present application and the first embodiment is that:

[0121] In this embodiment, step S301, in response to a user-triggered authorization instruction, controlling the first partition to switch from a running state to a standby state and controlling the second partition to switch from a standby state to a running state by updating first vehicle-side field tag data corresponding to the first partition and second vehicle-side field tag data corresponding to the second partition to run the upgraded version of the software, includes:

[0122] Step S302, verifying the upgraded version of the software by querying the updated first vehicle-side field tag data and the updated second vehicle-side field tag data to obtain a verification result;

[0123] Step S303: Execute corresponding result reporting operation according to the verification result.

[0124] Specifically, after the OTA upgrade is completed, it is first necessary to query the updated first vehicle-side field tag data and the updated second vehicle-side field tag data. These data are stored in the vehicle control unit and are used to record key information such as vehicle software version information and upgrade status. Then, according to Table 1 in the first embodiment above, the actual updated first vehicle-side field tag data and second vehicle-side field tag data are compared with the data in Table 1 to verify the upgraded version and obtain the verification result. Based on the verification result, the corresponding result reporting operation is performed.

[0125] In one implementation, in this embodiment, step S303, performing corresponding result reporting operations according to the verification result includes:

[0126] Step B1: If the verification result is successful, a corresponding pop-up message is generated, and the pop-up message is used to visualize the verification result;

[0127] Step B2: If the verification result is a verification failure, the verification result is reported to the OTA cloud, and a partition switching rejection instruction sent by the OTA cloud is received to stop switching the operating status of the first partition and the second partition.

[0128] Specifically, if the verification result is successful, a pop-up message is generated to visually display the verification result to the user. In this way, the user can see the message of successful verification; if the verification result is failed, the verification result will be reported to the OTA cloud. In this way, the OTA cloud can receive the failed verification result and send an instruction to reject the partition switch. In this way, the switching of the operating status of the first partition and the second partition can be stopped to ensure the reliability of the vehicle-side system. In this way, since the DHU and ADCU have A / B partitioning capabilities, the first partition and the second partition can be divided as described in the vehicle system upgrade method proposed in this application, which greatly improves the robustness of the system after the installation fails. Even if the system installation fails, the OTA cloud can refuse to issue an instruction to switch the available zone to the user whose system installation fails.

[0129] This embodiment, through the above-described solution, specifically verifies the upgraded software version by querying the updated first vehicle-side field tag data and the updated second vehicle-side field tag data to obtain a verification result; and performs a corresponding result reporting operation based on the verification result. This embodiment divides the first partition and the second partition, and in the event of a system installation failure, the OTA cloud can refuse to issue an instruction to switch to an available zone for the user whose system installation failed. This greatly improves the system robustness after an installation failure and ensures the availability of the vehicle-side system.

[0130] 6 , which is a business logic diagram of OTA fast upgrade of the fourth exemplary embodiment of the vehicle software upgrade method of the present application.

[0131] Based on the first to third embodiments, a fourth embodiment of the present application is proposed. The overall interaction object and implementation method of the present application may also be shown in FIG6 . The method may further include:

[0132] First, the OTA cloud (i.e., OTA Sever) sends an OTA upgrade task to the vehicle-side TCAM. The vehicle-side TCAM responds to the OTA upgrade task, detects the vehicle-side status, and initiates task synchronization between the vehicle-side and the OTA cloud. Then, after completing the synchronization between the vehicle-side and the OTA vehicle-side, the system software package is downloaded. At this time, the DHU / ADCU software package, which occupies a relatively large space in the system software package, is downloaded and installed to the spare area (i.e., the second partition). Then, after the download is complete, the vehicle-side generates an installation pop-up window to remind the user that the installation (OTA upgrade) can be performed. After the user clicks to confirm, an authorization instruction is generated. The vehicle-side TCAM responds to the authorization instruction, addresses the system software package through its internal BGM, and executes software flashing to install each ECU. The specific ECU flashing order can be customized according to the actual implementation situation and is not specifically limited in this embodiment. Then, the vehicle-side TCAM records the installation status of each ECU, checks the installation status of the ECU, and completes the operation partition switching of the DHU / ADCU. Finally, the vehicle-side system status is verified to report the installation result.

[0133] Referring to FIG7 , FIG7 is a schematic diagram illustrating the difference between OTA rapid upgrades and traditional upgrades in an embodiment of the present application. As shown in FIG7 , the traditional OTA upgrade process employs a vehicle software upgrade method in which the software package is silently downloaded and then flashed and installed after the vehicle is powered off. However, the OTA rapid upgrade method based on the vehicle software upgrade method proposed in this application allows the software package corresponding to the DHU / ADCU to be directly installed in the pre-partitioned B zone during the silent download. After user authorization, only the software packages corresponding to other ECUs need to be installed, and the DHU / ADCU's corresponding A zone is switched to the standby zone, and the DHU / ADCU's corresponding B zone is switched to the operational zone. Furthermore, this embodiment only partitions the DHU / ADCU into A / B zones to obtain the first and second zones. This is due to cost considerations. While the use of A / B partitioning for rapid OTA upgrades in a fully electronic and electrical architecture can accelerate vehicle software upgrades, it also has the disadvantage of being prohibitively expensive. In addition, this embodiment also controls the status of the vehicle-side system and the first partition and the second partition through the OTA cloud. More specifically, the OTA cloud can also configure and adjust OTA upgrade-related policies based on different strategic solutions according to different vehicle models, which has high flexibility.

[0134] This embodiment uses the above solution, specifically by partitioning the DHCU / ADCU, to significantly reduce the installation time of the OTA system software package while keeping hardware costs under control. It also optimizes the ECU flashing sequence, reducing the failure probability caused by DHU / ADCU flashing, thereby improving the overall OTA upgrade success rate. Furthermore, the A / B partitioning capabilities of the DHU and ADCU greatly enhance system robustness after installation failures, ensuring vehicle-side system availability.

[0135] It should be noted that the above embodiments can be reasonably combined and implemented according to actual conditions, and this embodiment will not be described in detail.

[0136] In addition, an embodiment of the present application also provides a vehicle software upgrade device, which includes: a data acquisition module for obtaining a target upgrade software package in response to a vehicle OTA upgrade instruction, wherein the target upgrade software package is used to upgrade the initial version software of the core domain controller; a storage partition module for installing the target upgrade software package to a second partition different from the first partition where the initial version software is stored, to obtain an upgraded version software of the core domain controller; a partition switching module for controlling the state switching between the first partition and the second partition to run the upgraded version software in response to an authorization instruction triggered by the user.

[0137] For the principle and implementation process of implementing vehicle software upgrade in this embodiment, please refer to the above embodiments and will not be repeated here.

[0138] In addition, an embodiment of the present application also proposes a terminal device, which includes a memory and a processor, and the memory stores a vehicle software upgrade program that can be run on the processor. When the vehicle software upgrade program is executed by the processor, the steps of the vehicle software upgrade method described above are implemented.

[0139] Since the vehicle software upgrade program adopts all the technical solutions of all the aforementioned embodiments when executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

[0140] In addition, an embodiment of the present application also provides a computer-readable storage medium, on which a vehicle software upgrade program is stored. When the vehicle software upgrade program is executed by a processor, the steps of the vehicle software upgrade method described above are implemented.

[0141] Since the vehicle software upgrade program adopts all the technical solutions of all the aforementioned embodiments when executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

[0142] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0143] The above-mentioned order of the embodiments of the present application is for description only and does not represent the advantages or disadvantages of the embodiments.

[0144] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0145] The above are merely optional embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for vehicle software upgrade, wherein, The method is applied to the vehicle remote software download OTA upgrade scenario. The vehicle software upgrade method includes the following steps: In response to a vehicle OTA upgrade instruction, obtain a target upgrade software package, where the target upgrade software package is used to upgrade the initial version software of the core domain controller; Install the target upgrade software package into a second partition different from the first partition where the initial version software is stored, to obtain the upgraded version software of the core domain controller; In response to an authorization instruction triggered by the user, control the first partition and the second partition to perform a status switch to run the upgraded version software.

2. The vehicle software upgrade method according to claim 1, wherein, The method is applied to the vehicle side. The step of, in response to a vehicle OTA upgrade instruction, obtaining a target upgrade software package, where the target upgrade software package is used to upgrade the initial software of the core domain controller, includes: In response to a vehicle OTA upgrade instruction, establish a communication connection with the OTA cloud and receive an OTA upgrade task sent by the OTA cloud; Detect the system status of the vehicle side. If the system status of the vehicle side meets a preset condition, synchronize the OTA upgrade task; Silently download the OTA software package corresponding to the OTA upgrade task, and determine a target software upgrade package from the OTA software package.

3. The vehicle software upgrade method according to claim 1, wherein, Before the step of, in response to an authorization instruction triggered by the user, controlling the first partition and the second partition to perform a status switch to run the upgraded version software, the method further includes: In response to the authorization instruction triggered by the user, install the first type of ECU and the second type of ECU in sequence according to a preset electronic control unit (ECU) flashing order. The first type of ECU includes a high-voltage ECU and a power ECU, and the second type of ECU includes a body ECU, a chassis ECU, and a network ECU.

4. The vehicle software upgrade method according to claim 1, wherein, The step of, in response to an authorization instruction triggered by the user, controlling the first partition and the second partition to perform a status switch to run the upgraded version software includes: In response to an authorization instruction triggered by the user, by updating the first vehicle-side field marker data corresponding to the first partition and the second vehicle-side field marker data corresponding to the second partition, control the first partition to switch from the running state to the standby state, and control the second partition to switch from the standby state to the running state, to run the upgraded version software.

5. The vehicle software upgrade method according to claim 4, wherein, After the step of, in response to an authorization instruction triggered by the user, by updating the first vehicle-side field marker data corresponding to the first partition and the second vehicle-side field marker data corresponding to the second partition, controlling the first partition to switch from the running state to the standby state, and controlling the second partition to switch from the standby state to the running state, to run the upgraded version software, the method further includes: Verify the upgraded version software by querying the updated first vehicle-side field marker data and the updated second vehicle-side field marker data, to obtain a verification result; Perform a corresponding result reporting operation according to the verification result.

6. The vehicle software upgrade method according to claim 5, wherein, The step of performing a corresponding result reporting operation according to the verification result includes: If the verification result is verification success, generate a corresponding pop-up message, where the pop-up message is used to visualize the verification result; If the verification result is a verification failure, report the verification result to the OTA cloud, and receive a partition switching rejection instruction sent by the OTA cloud to stop switching the operating states of the first partition and the second partition.

7. The vehicle software upgrade method according to claim 3, wherein, The method further includes: Establish a communication connection between the OTA cloud and the user's mobile communication terminal to receive the user's authorization instruction, where the authorization instruction includes an immediate upgrade instruction, a reservation upgrade instruction, and a night upgrade instruction.

8. The vehicle software upgrade method according to claim 2, wherein, The method further includes: The OTA cloud sends the OTA upgrade task to the vehicle-side TCAM. In response to the OTA upgrade task, the vehicle-side TCAM detects the vehicle state and initiates task synchronization between the vehicle and the OTA cloud; After the task synchronization between the vehicle and the OTA cloud is completed, download the system software package, and download and install the DHU / ADCU software package in the system software package to the standby area; After the download is completed, the vehicle generates an installation pop-up window to remind the user to install.

9. The vehicle software upgrade method according to claim 8, wherein, After the step of the vehicle generating an installation pop-up window to remind the user to install, the method further includes: After the user clicks to confirm, an authorization instruction is generated. In response to the authorization instruction, the vehicle-side TCAM performs address search of the system software package through its internal BGM and executes software flashing to install each ECU.

10. The vehicle software upgrade method according to claim 9, wherein, After the step that after the user clicks to confirm, an authorization instruction is generated. In response to the authorization instruction, the vehicle-side TCAM performs address search of the system software package through its internal BGM and executes software flashing to install each ECU, the method further includes: The vehicle-side TCAM records the installation status of each ECU and checks the installation status of the ECU.

11. The vehicle software upgrade method according to claim 10, wherein, After the step that the vehicle-side TCAM records the installation status of each ECU and checks the installation status of the ECU, the method further includes: Verify the vehicle system state to report the installation result.

12. A vehicle software upgrade device, wherein, The vehicle software upgrade device includes: A data acquisition module, configured to obtain a target upgrade software package in response to a vehicle OTA upgrade instruction, where the target upgrade software package is used to upgrade the initial version software of the core domain controller; A storage partition module, configured to install the target upgrade software package to a second partition different from the first partition where the initial version software is stored to obtain the upgraded version software of the core domain controller; A partition switching module, configured to control the first partition and the second partition to perform state switching to run the upgraded version software in response to an authorization instruction triggered by the user.

13. A terminal device, wherein, The terminal device includes a memory and a processor. A vehicle software upgrade program that can run on the processor is stored on the memory. When the vehicle software upgrade program is executed by the processor, it implements the vehicle software upgrade method according to any one of claims 1-11.

14. A computer-readable storage medium, wherein, A vehicle software upgrade program is stored on the computer-readable storage medium. When the vehicle software upgrade program is executed by the processor, it implements the vehicle software upgrade method according to any one of claims 1-11.

Images