Upgrade method, in-vehicle system, and vehicle

Abstract

The embodiments of the present application relate to the technical field of vehicles. Provided are an upgrade method, an in-vehicle system, and a vehicle, which enable an SOC and an MCU, which are in high correlation, to simultaneously run a latest-version program, thereby ensuring the reliability of communication between the SOC and the MCU. The upgrade method comprises: an SOC upgrading, on the basis of a first upgrade package in a storage partition thereof, a first original-version program in an upgrade runtime partition, so as to obtain a first upgraded-version program; if determining that the upgrade of the SOC itself is successful, the SOC sending an upgrade instruction to an MCU; in response to the upgrade instruction, the MCU upgrading a second original-version program in a second runtime partition on the basis of a second upgrade package, so as to obtain a second upgraded-version program; if determining that the upgrade of the MCU itself is successful, the MCU sending a restart instruction to the SOC, controlling the MCU itself to restart, and running the second upgraded-version program in the second runtime partition after the restart; and if the SOC determines that the upgrade of the MCU is successful, performing a restart in response to the restart instruction, and running the first upgraded-version program in the upgrade runtime partition after the restart.

Description

An upgrading method, vehicle-mounted system and vehicle

[0001] The present application claims priority to the Chinese patent application No. 202411026201.9, filed on July 29, 2024, and entitled "An upgrading method, vehicle-mounted system and vehicle", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] Embodiments of the present application relate to the vehicle technical field, and in particular, to an upgrading method, vehicle-mounted system and vehicle. BACKGROUND

[0003] Currently, more and more vehicle manufacturers use over-the-air technology (OTA) to remotely upgrade vehicles. However, if a strong association hardware unit is involved in a certain upgrade process, how to ensure that the strong association hardware units can normally communicate after the upgrade is completed is a technical problem that needs to be solved. SUMMARY

[0004] Embodiments of the present application propose an upgrading method, vehicle-mounted system and vehicle, in the case that the SOC has two running partitions and the MCU has one running partition, the strongly associated SOC and MCU run the latest version of the program at the same time, thereby ensuring that the SOC and MCU can normally communicate.

[0005] In a first aspect, embodiments of the present application provide an upgrading method applied to a vehicle-mounted system, the vehicle-mounted system including a system on chip (SOC) and a micro control unit (MCU), the SOC having two first running partitions and a storage partition, the storage partition storing a plurality of upgrade packages, the MCU having a second running partition, and the method including:

[0006] The SOC upgrades a first original version program in an upgrade running partition according to a first upgrade package in the storage partition of the SOC, to obtain a first upgraded version program, the upgrade running partition being a running partition other than a currently used initial running partition among the two first running partitions;

[0007] The SOC determines that the upgrade is successful, and sends an upgrade instruction to the MCU, the upgrade instruction carrying a second upgrade package in the storage partition;

[0008] The MCU upgrades a second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction, to obtain a second upgraded version program;

[0009] if the MCU determines that the MCU is upgraded successfully, sends a restart instruction to the SOC, controls the MCU to restart, and runs the second upgraded version program in the second running partition after the MCU restarts;

[0010] if the SOC determines that the MCU is upgraded successfully, restarts in response to the restart instruction, and runs the first upgraded version program in the upgraded running partition after the SOC restarts.

[0011] In the embodiment of the application, the SOC and the MCU in the vehicle-mounted system can be considered as hardware units with strong association, and the SOC has two running partitions, and the MCU has only one running partition. At this time, the SOC can first upgrade in the upgraded running partition of the two running partitions, and then control the MCU to upgrade if the SOC is upgraded successfully. In the case that the MCU determines that the MCU is upgraded successfully, the MCU controls the MCU to restart. At the same time, the MCU sends a restart instruction to the SOC to make the SOC restart. In the case that the SOC determines that the MCU is upgraded successfully, the SOC also restarts. That is, in the case that the SOC has two running partitions, the MCU has only one running partition, and the MCU and the SOC are upgraded successfully at different times, the MCU and the SOC restart at the same time, and after the restart, the MCU runs the latest version program in the corresponding running partition, and the SOC runs the latest version program in the upgraded running partition by switching the running partition. That is, the MCU and the SOC run the latest version programs respectively, so that the MCU and the SOC with strong association can communicate normally in the case that the MCU and the SOC are upgraded successfully at different times.

[0012] Optionally, after the MCU upgrades the second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction, and obtains the second upgraded version program, the method further comprises:

[0013] if the SOC determines that the MCU fails to upgrade, sends a rollback instruction to the MCU, and the rollback instruction carries the first rollback package in the storage partition;

[0014] the MCU upgrades the second upgraded version program in the second running partition based on the first rollback package in response to the rollback instruction;

[0015] if the MCU determines that the MCU is rolled back successfully, sends a restart instruction to the SOC, controls the MCU to restart, and runs the second original version program in the second running partition after the MCU restarts;

[0016] the SOC restarts in response to the restart instruction, and runs the first original version program in the initial running partition after the SOC restarts.

[0017] In the embodiment of the present application, the SOC and the MCU in the vehicle-mounted system can be considered as hardware units with strong association, and the SOC has two running partitions, while the MCU has only one running partition. At this time, the SOC can first upgrade in the upgrade running partition of the two running partitions, and if the SOC upgrade is successful, the MCU is controlled to upgrade. If the SOC determines that the MCU upgrade fails, the MCU is controlled to rollback first. If the MCU rollback is successful, the MCU is controlled to restart, and at the same time, a restart instruction is sent to make the SOC restart. The SOC also restarts after determining that the MCU rollback is successful. That is, in the case that the SOC has two running partitions, the MCU has only one running partition, and the MCU and the SOC are both upgraded, and the MCU upgrade fails, the MCU will rollback, and then restart simultaneously with the SOC, and after the restart, the SOC runs the original version program of the MCU through the way of not switching the running partition, so as to ensure that the MCU and the SOC with strong association can communicate normally in the case that the MCU and the SOC are both upgraded but the MCU upgrade fails.

[0018] Optionally, the MCU further comprises a backup partition, and before the MCU upgrades the second original version program in the second running partition based on the second upgrade package to obtain a second upgraded version program in response to the upgrade instruction, the method further comprises:

[0019] The MCU backs up the second original version program in the second running partition to the backup partition in response to the upgrade instruction;

[0020] After the MCU upgrades the second original version program in the second running partition based on the second upgrade package to obtain a second upgraded version program in response to the upgrade instruction, the method further comprises:

[0021] If the MCU determines that the upgrade fails, the second running partition is rolled back based on the second original version program in the backup partition;

[0022] If the MCU determines that the rollback is successful, a restart instruction is sent to the SOC, the MCU is controlled to restart, and after the restart, the second original version program in the second running partition is run;

[0023] The SOC restarts in response to the restart instruction, and after the restart, the first original version program in the initial running partition is run.

[0024] In the embodiment of the present application, the SOC and the MCU in the vehicle-mounted system can be considered as hardware units with strong association, and the SOC has two running partitions, while the MCU has only one running partition and one backup partition. At this time, the SOC can first upgrade the original version program of itself in the upgrade running partition of the two running partitions, and if the SOC upgrade is successful, the MCU controls the original version program of itself to be backed up to the backup partition, and then the original version program is upgraded in the running partition of the SOC. If the MCU determines that the upgrade fails, the original version program in the backup partition can be used to roll back the running partition. If the MCU rollback is successful, the MCU controls itself to restart, and at the same time, sends a restart instruction to make the SOC restart. The SOC also restarts after determining that the MCU rollback is successful. That is, in the case that the SOC has two running partitions, the MCU has only one running partition and one backup partition, and the MCU and the SOC are upgraded, and the MCU upgrade fails, the MCU uses the original version program backed up by the backup partition to roll back, and then restarts at the same time as the SOC, and after restarting, the SOC runs the original version program at the same time as the MCU without switching the running partition, so that in the case that the MCU and the SOC with strong association are upgraded but the MCU upgrade fails, normal communication can be ensured.

[0025] Optionally, the second running partition is two, and the method further comprises:

[0026] The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program, and the first upgrade running partition is a running partition other than the currently used first initial running partition among the two first running partitions;

[0027] The SOC determines that the upgrade is successful, sends an upgrade instruction to the MCU, and the upgrade instruction carries the second upgrade package in the storage partition;

[0028] The MCU upgrades the second original version program in the second upgrade running partition based on the second upgrade package, to obtain a second upgraded version program, and the second upgrade running partition is a running partition other than the currently used second initial running partition among the two second running partitions;

[0029] If the MCU determines that the upgrade is successful, sends a restart instruction to the SOC, controls itself to restart, and runs the second upgraded version program in the second upgrade running partition after restarting;

[0030] If the SOC determines that the MCU is upgraded successfully, the SOC restarts in response to the restart instruction, and runs the first upgraded version program in the first upgrade running partition after the restart.

[0031] In the embodiments of the present application, the SOC and the MCU in the vehicle-mounted system can be considered as hardware units with strong association, and both the SOC and the MCU have two running partitions. At this time, the SOC can first upgrade its original version program in the upgrade running partition of the two running partitions, and if the SOC is upgraded successfully, the SOC controls the MCU to upgrade its original version in the upgrade running partition of the two running partitions. In the case that the MCU determines that it is upgraded successfully, the MCU controls itself to restart. At the same time, the MCU sends a restart instruction to make the SOC restart. In the case that the MCU is also upgraded successfully, the SOC also restarts. That is, in the case that the SOC and the MCU both have two running partitions and the MCU and the SOC are upgraded successfully at different times, the SOC and the MCU restart at the same time, and after the restart, the MCU and the SOC run the latest version program in the upgrade running partition by switching the running partition, so as to ensure that the MCU and the SOC with strong association can communicate normally in the case that the MCU and the SOC are upgraded successfully at different times.

[0032] Optionally, after the MCU upgrades the second original version program in the second upgrade running partition based on the second upgrade package to obtain the second upgraded version program, the method further comprises:

[0033] If the MCU determines that it is upgraded unsuccessfully, the MCU sends a restart instruction to the SOC and controls itself to restart, and after the restart, the MCU runs the second original version program in the second initial running partition.

[0034] If the SOC determines that the MCU is upgraded unsuccessfully, the SOC restarts in response to the restart instruction, and after the restart, the SOC runs the first original version program in the first initial running partition.

[0035] In the embodiment of the present application, the SOC and the MCU in the vehicle-mounted system can be considered as hardware units with strong association, and both the SOC and the MCU have two running partitions, at this time, the SOC can first upgrade the original version program of itself in the upgrade running partition of the two running partitions, if the SOC upgrade is successful, the MCU is controlled to upgrade the original version of itself in the upgrade running partition of the two running partitions. In the case that the MCU determines that the upgrade fails, the MCU is controlled to restart; at the same time, a restart instruction is sent to make the SOC restart. In the case that the SOC determines that the upgrade of the MCU fails, the SOC also restarts. That is to say, in the case that the SOC and the MCU both have two running partitions, and the MCU and the SOC both upgrade in the upgrade running partition, in the case that the upgrade of the MCU fails, the MCU and the SOC restart at the same time, and after restarting, the SOC and the MCU run the original version program in the initial running partition of each without switching the running partition, so that in the case that the MCU and the SOC with strong association both upgrade but the upgrade of the MCU fails, normal communication can be ensured.

[0036] Optionally, the vehicle-mounted system further comprises an instrument, the instrument comprises two third running partitions, and the method further comprises:

[0037] The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program, and the first upgrade running partition is a running partition other than the currently used first initial running partition of the two first running partitions;

[0038] The SOC determines that the upgrade of itself is successful, sends an upgrade instruction to the instrument, and the upgrade instruction carries a third upgrade package in the storage partition;

[0039] The instrument upgrades a third original version program in a third upgrade running partition based on the third upgrade package in response to the upgrade instruction, to obtain a third upgraded version program, and the third upgrade running partition is a running partition other than the currently used third initial running partition of the two third running partitions;

[0040] If the SOC determines that the upgrade of the instrument is successful, a restart instruction is sent to the instrument, and the SOC is controlled to restart, and after restarting, the first upgraded version program in the first upgrade running partition is run;

[0041] The instrument restarts in response to the restart instruction, and after restarting, the third upgraded version program in the third upgrade running partition is run.

[0042] In the embodiment, the SOC and the instrument in the vehicle-mounted system can be considered as hardware units with strong association, and both the SOC and the instrument have two running partitions, at this time, the SOC can first upgrade the original version program of itself in the upgrade running partition of the two running partitions, if the SOC upgrade is successful, the instrument is controlled to upgrade the original version of itself in the upgrade running partition of the two running partitions. If the SOC determines that the instrument also upgrades successfully, it will control itself to restart; at the same time, it will send a restart instruction to make the instrument also restart. That is to say, in the case that the SOC and the instrument both have two running partitions and the instrument and the SOC upgrade successfully at different times, the two will restart at the same time, and after restarting, the instrument and the SOC will run the latest version program in the upgrade running partition through switching the running partition, so as to ensure that the instrument and the SOC with strong association can communicate normally in the case that the instrument and the SOC upgrade successfully at different times.

[0043] Optionally, after the instrument upgrades the third original version program in the third upgrade running partition based on the third upgrade package in response to the upgrade instruction, and obtains the third upgrade version program, the method further comprises:

[0044] If the SOC determines that the instrument fails to upgrade, it sends a restart instruction to the instrument, controls itself to restart, and runs the first original version program in the first initial running partition after restarting;

[0045] The instrument restarts in response to the restart instruction, and runs the third original version program in the third initial running partition after restarting.

[0046] In the embodiment, the SOC and the instrument in the vehicle-mounted system can be considered as hardware units with strong association, and both the SOC and the instrument have two running partitions, at this time, the SOC can first upgrade the original version program of itself in the upgrade running partition of the two running partitions, if the SOC upgrade is successful, the instrument is controlled to upgrade the original version of itself in the upgrade running partition of the two running partitions. If the SOC determines that the instrument also upgrades successfully, it will control itself to restart; at the same time, it will send a restart instruction to make the instrument also restart. That is to say, in the case that the SOC and the instrument both have two running partitions and the instrument and the SOC upgrade successfully at different times, the two will restart at the same time, and after restarting, the instrument and the SOC will run the latest version program in the upgrade running partition through switching the running partition, so as to ensure that the instrument and the SOC with strong association can communicate normally in the case that the instrument and the SOC upgrade successfully at different times.

[0047] Optionally, the vehicle-mounted system further comprises an instrument, the instrument comprising a third running partition, and the method further comprises:

[0048] The SOC upgrades the first original version program in the upgrade running partition based on the first upgrade package in the storage partition to obtain a first upgraded version program, the upgrade running partition being a running partition other than the currently used initial running partition among the two first running partitions;

[0049] The SOC determines that the upgrade is successful, sends an upgrade instruction to the instrument, and the upgrade instruction carries a third upgrade package in the storage partition;

[0050] The instrument upgrades a third original version program in a third running partition based on the third upgrade package in response to the upgrade instruction to obtain a third upgraded version program;

[0051] If the SOC determines that the upgrade of the instrument is successful, the SOC sends a restart instruction to the instrument and controls itself to restart, and runs the first upgraded version program in the upgrade running partition after the restart;

[0052] The instrument restarts in response to the restart instruction and runs the third upgraded version program in the third running partition after the restart.

[0053] In the embodiments, the SOC and the instrument in the vehicle-mounted system can be considered as hardware units with strong association, and the SOC has two running partitions while the instrument has only one running partition. In this case, the SOC can first upgrade its original version program in the upgrade running partition among the two running partitions, and if the SOC upgrade is successful, the MCU is controlled to upgrade the original version program of the SOC in the single running partition of the SOC. If the SOC determines that the upgrade of the instrument is also successful, the SOC controls itself to restart, and at the same time, sends a restart instruction to make the instrument restart. That is, in the case that the SOC has two running partitions, the instrument has only one running partition, and the instrument and the SOC upgrade successfully at different times, the instrument and the SOC restart at the same time, and after the restart, the SOC runs the latest version program of itself by switching the running partition, so as to ensure that the instrument and the SOC with strong association can communicate normally in the case that they upgrade successfully at different times.

[0054] Optionally, after the instrument upgrades the third original version program in the third running partition based on the third upgrade package to obtain the third upgraded version program, the method further comprises:

[0055] if the SOC determines that the instrument fails to upgrade, sending a rollback instruction to the instrument, the rollback instruction carrying a third rollback package in the storage partition;

[0056] the instrument, in response to the rollback instruction, rolling back the third upgraded version program in the third running partition based on the third rollback package;

[0057] if the SOC determines that the instrument successfully rolls back, sending a restart instruction to the instrument and controlling itself to restart, and running the first original version program in the first initial running partition after restarting;

[0058] the instrument, in response to the restart instruction, restarting and running the third original version program in the third running partition after restarting.

[0059] In the embodiments of the present application, the SOC and the instrument in the vehicle-mounted system can be considered as hardware units with strong association, and the SOC has two running partitions, while the instrument has only one running partition. At this time, the SOC can first upgrade the original version program of itself in the upgraded running partition of the two running partitions. If the SOC upgrades successfully, the original version program of the instrument in the single running partition is controlled to be upgraded. If the SOC determines that the instrument fails to upgrade, the instrument is controlled to roll back. If the SOC determines that the instrument successfully rolls back, the SOC is controlled to restart, and at the same time, a restart instruction is sent to make the instrument restart as well. That is to say, in the case that the SOC has two running partitions, the instrument has only one running partition, and the instrument and the SOC are both upgraded, and the instrument fails to upgrade, the instrument will roll back, and then restart together with the SOC, and after restarting, the SOC runs the original version program together with the instrument by not switching the running partition, so as to ensure that the instrument and the SOC with strong association are both upgraded, and in the case that the instrument fails to upgrade, the instrument can communicate normally.

[0060] In a second aspect, the embodiments of the present application provide a vehicle-mounted system, which comprises a system on chip (SOC) and a micro control unit (MCU), the SOC has two first running partitions and a storage partition, the storage partition stores a plurality of upgrade packages, and the MCU has a second running partition;

[0061] the SOC is configured to upgrade a first original version program in an upgraded running partition according to a first upgrade package in the storage partition of the SOC, to obtain a first upgraded version program, the upgraded running partition being a running partition other than a currently used initial running partition of the two first running partitions;

[0062] The SOC is further configured to send an upgrade instruction to the MCU if it is determined that the upgrade is successful, wherein the upgrade instruction carries a second upgrade package in the storage partition;

[0063] The MCU is configured to upgrade a second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction, to obtain a second upgraded version program;

[0064] The MCU is further configured to send a restart instruction to the SOC and control itself to restart if it is determined that the upgrade is successful, and to run the second upgraded version program in the second running partition after the restart;

[0065] The SOC is further configured to restart in response to the restart instruction and run the first upgraded version program in the upgrade running partition after the restart if it is determined that the upgrade of the MCU is successful.

[0066] Optionally, the SOC is further configured to send a rollback instruction to the MCU if it is determined that the upgrade of the MCU fails, wherein the rollback instruction carries a first rollback package in the storage partition;

[0067] The MCU is further configured to rollback the second upgraded version program in the second running partition based on the first rollback package in response to the rollback instruction;

[0068] The MCU is further configured to send a restart instruction to the SOC and control itself to restart if it is determined that the rollback is successful, and to run the second original version program in the second running partition after the restart;

[0069] The SOC is further configured to restart in response to the restart instruction and run the first original version program in the initial running partition after the restart.

[0070] Optionally, the MCU is further configured to backup the second original version program in the second running partition to the backup partition in response to the upgrade instruction;

[0071] If the MCU determines that the upgrade fails, the second running partition is rolled back based on the second original version program in the backup partition;

[0072] The MCU is further configured to send a restart instruction to the SOC and control itself to restart if it is determined that the rollback is successful, and to run the second original version program in the second running partition after the restart;

[0073] The SOC is further configured to restart in response to the restart instruction and run the first original version program in the initial running partition after the restart.

[0074] Optionally, the second running partition is two, and the SOC is further configured to upgrade the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition to obtain a first upgraded version program, the first upgrade running partition being a running partition other than a currently used first initial running partition in the two first running partitions.

[0075] The SOC is further configured to determine that the SOC is successfully upgraded, and send an upgrade instruction to the MCU, the upgrade instruction carrying a second upgrade package in the storage partition.

[0076] The MCU is further configured to, in response to the upgrade instruction, upgrade a second original version program in a second upgrade running partition based on the second upgrade package to obtain a second upgraded version program, the second upgrade running partition being a running partition other than a currently used second initial running partition in the two second running partitions.

[0077] The MCU is further configured to, if it is determined that the MCU is successfully upgraded, send a restart instruction to the SOC, control the MCU to restart, and run the second upgraded version program in the second upgrade running partition after the restart.

[0078] The SOC is further configured to, if it is determined that the MCU is successfully upgraded, restart in response to the restart instruction, and run the first upgraded version program in the first upgrade running partition after the restart.

[0079] Optionally, the MCU is further configured to, if it is determined that the MCU fails to be upgraded, send a restart instruction to the SOC, control the MCU to restart, and run the second original version program in the second initial running partition after the restart.

[0080] The SOC is further configured to, if it is determined that the MCU fails to be upgraded, restart in response to the restart instruction, and run the first original version program in the first initial running partition after the restart.

[0081] Optionally, the vehicle-mounted system further comprises an instrument, the instrument comprising two third running partitions, and the SOC is further configured to upgrade the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition to obtain a first upgraded version program, the first upgrade running partition being a running partition other than a currently used first initial running partition in the two first running partitions.

[0082] The SOC is further configured to determine that the SOC is successfully upgraded, and send an upgrade instruction to the instrument, the upgrade instruction carrying a third upgrade package in the storage partition.

[0083] the instrument, in response to the restart instruction, restarts, and after restarting, runs the third original version program in the third initial running partition.

[0084] the SOC, in response to determining that the instrument upgrades successfully, sends a restart instruction to the instrument, controls itself to restart, and after restarting, runs the first upgraded version program in the first upgraded running partition.

[0085] the instrument, in response to the restart instruction, restarts, and after restarting, runs the third upgraded version program in the third upgraded running partition.

[0086] optionally, the SOC, in response to determining that the instrument upgrades unsuccessfully, sends a restart instruction to the instrument, controls itself to restart, and after restarting, runs the first original version program in the first initial running partition.

[0087] the instrument, in response to the restart instruction, restarts, and after restarting, runs the third original version program in the third initial running partition.

[0088] optionally, the vehicle-mounted system further includes an instrument, the instrument including a third running partition, and the SOC is further configured to upgrade a first original version program in an upgraded running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program, the upgraded running partition being a running partition other than a currently used initial running partition among the two first running partitions.

[0089] the SOC, in response to determining that the instrument upgrades successfully, sends a restart instruction to the instrument, controls itself to restart, and after restarting, runs the first upgraded version program in the first upgraded running partition.

[0090] the instrument, in response to the restart instruction, restarts, and after restarting, runs the third upgraded version program in the third upgraded running partition.

[0091] the SOC, in response to determining that the instrument upgrades successfully, sends a restart instruction to the instrument, controls itself to restart, and after restarting, runs the first upgraded version program in the first upgraded running partition.

[0092] the instrument, in response to the restart instruction, restarts, and after restarting, runs the third upgraded version program in the third upgraded running partition.

[0093] Optionally, the SOC is further configured to send a rollback instruction to the instrument if it is determined that the instrument upgrade fails, wherein the rollback instruction carries a third rollback package in the storage partition;

[0094] The instrument is further configured to rollback the third upgraded version program in the third running partition based on the third rollback package in response to the rollback instruction;

[0095] The SOC is further configured to send a restart instruction to the instrument if it is determined that the instrument rollback succeeds, and control itself to restart, and run the first original version program in the first initial running partition after the restart;

[0096] The instrument is further configured to restart in response to the restart instruction, and run the third original version program in the third running partition after the restart.

[0097] In a third aspect, an embodiment of the present application provides a vehicle, which comprises the vehicle-mounted system of the second aspect.

[0098] It should be understood that the second to third aspects of the embodiments of the present application are consistent with the technical solution of the first aspect of the embodiments of the present application, and the beneficial effects obtained by the aspects and corresponding feasible implementation manners are similar, and will not be repeated. BRIEF DESCRIPTION OF DRAWINGS

[0099] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0100] FIG. 1 is a flowchart of an upgrade method according to an embodiment of the present application;

[0101] FIG. 2 is a flowchart of another upgrade method according to an embodiment of the present application;

[0102] FIG. 3 is a flowchart of another upgrade method according to an embodiment of the present application;

[0103] FIG. 4 is a flowchart of another upgrade method according to an embodiment of the present application;

[0104] FIG. 5 is a flowchart of an upgrade method according to an embodiment of the present application;

[0105] FIG. 6 is a flowchart of another upgrade method according to an embodiment of the present application;

[0106] FIG. 7 is a flowchart of another upgrade method according to an embodiment of the present application;

[0107] FIG. 8 is a flow diagram of another upgrading method according to an embodiment of the present application;

[0108] FIG. 9 is a flow diagram of another upgrading method according to an embodiment of the present application;

[0109] FIG. 10 is a flow diagram of another upgrading method according to an embodiment of the present application;

[0110] FIG. 11 is a flow diagram of another upgrading method according to an embodiment of the present application;

[0111] FIG. 12 is a flow diagram of another upgrading method according to an embodiment of the present application;

[0112] FIG. 13 is a structural diagram of a vehicle-mounted system according to an embodiment of the present application;

[0113] FIG. 14 is a structural diagram of a vehicle according to an embodiment of the present application. DETAILED DESCRIPTION

[0114] In order to better understand the technical solutions of the present application, the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0115] It should be clear that the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0116] The terms used in the embodiments of the present application are only for the purpose of describing the specific embodiments, and are not intended to limit the present application. The singular forms "a", "an" and "the" used in the embodiments of the present application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0117] At present, more and more vehicle manufacturers use over-the-air technology (OTA) to remotely upgrade vehicles. However, if a strong association hardware unit is involved in a certain upgrade process, for example, the strong association hardware unit is a system on chip (SOC) and a microcontroller unit (MCU), how to ensure that the strong association hardware units can normally communicate after the upgrade is completed is a technical problem that needs to be solved.

[0118] In view of this, the embodiment of the present application proposes an upgrading method, in which the SOC can first upgrade in the upgrading running partition of the two running partitions, and if the SOC upgrades successfully, the MCU is controlled to upgrade. In the case that the MCU determines that it upgrades successfully, it will control itself to restart; at the same time, it will send a restart instruction to make the SOC also restart. In the case that the SOC determines that the MCU also upgrades successfully, it will also restart. That is to say, in the case that the SOC has two running partitions and the MCU has only one running partition, and the MCU and the SOC upgrade successfully at different times, they will restart at the same time, and after restarting, the MCU will run the latest version program in the corresponding running partition, and the SOC will run the latest version program in the upgrading running partition by switching the running partition, that is, the MCU and the SOC run the latest version program respectively, so that in the case that the MCU and the SOC upgrade successfully at different times, they can communicate normally.

[0119] Firstly, the process of obtaining the upgrade package is described below.

[0120] After the vehicle is powered on, the SOC can report the device identifiers of each electronic control unit (ECU) and the corresponding current version numbers to the OTA upgrade master control module (hereinafter referred to as DA module) in the vehicle Tbox. For example, each ECU includes but is not limited to: instrument and instrument screen, central control screen, car machine (including SOC and MCU). After the DA module receives the device identifiers of the above-mentioned multiple ECUs and the corresponding current version numbers, it sends them to the OTA cloud platform. The OTA cloud platform compares the current version number corresponding to each device identifier with the latest version number. If the latest version number is higher than the current version number, it is considered that the corresponding ECU needs to be upgraded; otherwise, if the latest version number is lower than the current version number, it is considered that the corresponding ECU needs to be downgraded. The present application mainly takes the upgrading process as an example for description. The OTA cloud platform will inform the DA module which ECUs have upgrade packages. After the DA module learns that there are upgrade packages for the ECUs to be upgraded, it initiates a request to the OTA cloud platform to obtain the upgrade packages corresponding to the above-mentioned ECUs to be upgraded from the OTA cloud platform. After the DA module obtains the upgrade packages corresponding to the multiple ECUs to be upgraded, it sends the upgrade packages corresponding to the above-mentioned multiple ECUs to be upgraded to the SOC. After the SOC receives the multiple upgrade packages, it stores the multiple upgrade packages in the storage partition of itself, of course, the SOC will also store the device identifier corresponding to each upgrade package in the above-mentioned multiple upgrade packages, so as to know which upgrade package is used to upgrade which ECU in the subsequent upgrading process.

[0121] The technical solutions provided by the embodiments of the present application are described below in combination with the drawings.

[0122] Scenario one: both the SOC and the MCU have only one running partition, that is, the SOC has a first running partition and the MCU has a second running partition.

[0123] Please refer to FIG. 1, which is a flowchart of an upgrading method provided by an embodiment of the present application. The method can be applied to a vehicle-mounted system, which includes a SOC and a MCU. The flow of the method is described as follows:

[0124] Step 101: The SOC upgrades a first original version program in the first running partition based on a first upgrade package in the storage partition, to obtain a first upgraded version program.

[0125] In the embodiment of the present application, before upgrading, it can be considered that the first original version program is running in the first running partition of the SOC. When a preset upgrading condition is met, the SOC can upgrade the first original version program in the first running partition based on the first upgrade package in the storage partition, to obtain the first upgraded version program. It should be understood that, since the SOC has only one running partition, the SOC needs to enter a boot loader mode in the above upgrading process.

[0126] For example, the preset upgrading condition can be detecting a user-initiated upgrade confirmation operation, or can be detecting that a preset upgrade time period set by the user is reached, or can also be detecting that the vehicle-mounted system is currently in an idle state. The present application does not particularly limit the preset upgrading condition.

[0127] Step 102: If the SOC determines that the upgrading is successful, the SOC sends an upgrading instruction to the MCU.

[0128] In the embodiment of the present application, after the upgrading is completed, the SOC can perform a Message-Digest Algorithm 5 (MD5) check. If the check is passed, it can be considered that the SOC upgrading is successful. On this basis, the SOC can send an upgrading instruction to the MCU, which carries a second upgrade package stored in the storage partition of the SOC, so as to control the MCU to perform upgrading based on the second upgrade package.

[0129] Step 103: The MCU upgrades a second original version program in the second running partition based on the second upgrade package in response to the upgrading instruction, to obtain a second upgraded version program.

[0130] In the embodiment of the present application, before upgrading, it can be considered that the second original version program runs in the second running partition of the MCU. After the MCU receives the second upgrade package from the SOC, the original second original version program can be upgraded based on the second upgrade package to obtain the second upgraded version program. It should be understood that, since the MCU has only one running partition, the MCU needs to enter the bootloader mode during the above-mentioned upgrading process.

[0131] Step 104: If the MCU determines that the upgrading is successful, the MCU sends a restart instruction to the SOC.

[0132] Step 105: If the MCU determines that the upgrading is successful, the MCU controls itself to restart, and after the restart, the second upgraded version program in the second running partition is run.

[0133] In the embodiment of the present application, after the MCU upgrading is completed, the SOC initiates MD5 verification to the MCU. Of course, other verification methods can also be used, which are not particularly limited in the present application. If the verification is passed, it can be considered that the MCU upgrading is successful, at this time, the MCU can control itself to restart, and after the restart, the second upgraded version program in the second running partition is run. At the same time, the MCU also sends a restart instruction to the SOC, so that the SOC can restart at the same time in the case of successful upgrading.

[0134] Step 106: If the SOC determines that the MCU upgrading is successful, the SOC restarts in response to the restart instruction, and after the restart, the first upgraded version program in the first running partition is run.

[0135] In the embodiment of the present application, after the verification is passed, the MCU notifies the SOC. Then, in the case that the SOC determines that the upgrading is successful and the MCU also upgrades successfully, the SOC and the MCU restart at the same time, and after the restart, the first upgraded version program in the first running partition is run.

[0136] In the above-mentioned embodiment, in the case that the MCU and the SOC upgrade successfully at different times, the MCU and the SOC restart at the same time, and after the restart, the MCU and the SOC run the latest version programs at the same time, so that the MCU and the SOC with strong association can communicate normally in the case that the MCU and the SOC upgrade successfully at different times.

[0137] In some embodiments, considering that the MCU can also fail in the upgrading process, if the SOC runs the latest version program and the MCU runs the original version program, the communication between the SOC and the MCU can also be abnormal. Therefore, in the embodiments of the present application, in the case that the SOC and the MCU are both upgraded and the MCU fails in the upgrading, the program versions running in the SOC and the MCU can be unified, so as to ensure that the SOC and the MCU can normally communicate.

[0138] Please refer to FIG. 2, which is a flowchart of another upgrading method provided by the embodiments of the present application. After step 103, 107-112 can also be executed.

[0139] Step 107: If the SOC determines that the MCU fails in the upgrading, the SOC sends a rollback instruction to the MCU.

[0140] In the MD5 check initiated by the SOC, if the MCU determines that the check fails, the MCU can notify the SOC of the check result. If the check result received by the SOC is that the MCU fails in the check, it can be determined that the MCU fails in the upgrading. At this time, the SOC can send a rollback instruction to the MCU, and the rollback instruction carries the first rollback package stored in the storage partition of the SOC, which is used to control the version rollback of the MCU that fails in the upgrading.

[0141] Of course, in the case that the SOC determines that the MCU fails in the upgrading for the first time, the SOC can not directly control the MCU to perform the version rollback, but send a second upgrading package to the MCU again, so as to control the MCU to upgrade again. By analogy, if the SOC determines that the number of times that the MCU fails in the upgrading reaches a set threshold, the SOC sends a rollback instruction to the MCU.

[0142] Step 108: The MCU responds to the rollback instruction and rolls back the second upgrading version program in the second running partition based on the first rollback package.

[0143] In the embodiments of the present application, after receiving the rollback instruction from the SOC, the MCU rolls back the second upgrading version program in the second running partition based on the first rollback package, that is, the program running in the second running partition is rolled back to the second original version program. It should be understood that, since the MCU has only one running partition, the MCU needs to be in a bootloader mode in the above rollback process.

[0144] Step 109: The SOC rolls back the first upgrading version program in the first running partition based on the second rollback package in the storage partition.

[0145] In the embodiment of the application, in the case that the SOC upgrade is successful but the MCU upgrade fails, since the MCU needs to be rolled back, in order to ensure normal communication between the SOC and the MCU, the SOC also needs to be rolled back. Then the SOC can roll back the first upgrade version program in the first running partition based on the second rollback package in the self storage partition, so as to make the program running in the first running partition roll back to the first original version program.

[0146] Step 110: If the MCU determines that the self rollback is successful, a restart instruction is sent to the SOC.

[0147] Step 111: If the MCU determines that the self rollback is successful, the self is controlled to restart, and after the restart, the second original version program in the second running partition is run.

[0148] In the embodiment of the application, if the MCU determines that the self rollback is successful, on one hand, the self is controlled to restart, and after the restart, the second original version program is run in the second running partition; on the other hand, the SOC is also controlled to restart.

[0149] Step 112: If the SOC determines that the self rollback is successful, a restart instruction is sent to the SOC, and after the restart, the first original version program in the first running partition is run.

[0150] In the embodiment of the application, in the case that the SOC determines that the self rollback is successful and the MCU also rolls back successfully, the SOC and the MCU are restarted at the same time, and after the restart, the SOC runs the first original version program in the first running partition.

[0151] In the above embodiment, in the case that the MCU and the SOC each have only a single running partition, and the MCU and the SOC are upgraded, and the MCU upgrade fails, the MCU and the SOC each roll back and are restarted at the same time, and after the restart, the MCU and the SOC run the original version programs respectively, so that in the case that the MCU and the SOC with strong association are upgraded but the MCU upgrade fails, normal communication can be ensured.

[0152] It is worth noting that when the SOC and the MCU are upgraded, the SOC upgrade may also fail. At this time, the SOC is rolled back based on the second rollback package of the storage area, and then the self is controlled to restart, and after the restart, the first original version program in the first initial running partition is run, and the MCU is not upgraded. Then the restarted SOC and the MCU run the original version programs respectively, so that in the case that the MCU and the SOC with strong association are upgraded but the SOC upgrade fails, normal communication can be ensured.

[0153] Scenario two: the SOC has two running partitions, and the MCU has one running partition, i.e., the SOC has two first running partitions, and the MCU has one second running partition.

[0154] Please refer to FIG. 3, which is a flowchart of another upgrading method provided by the embodiments of the present application. The flow of the method is described as follows:

[0155] Step 201: The SOC upgrades the first original version program in the upgrading running partition according to the first upgrade package in the storage partition of the SOC, to obtain a first upgraded version program.

[0156] In the embodiments of the present application, the two first running partitions in the SOC can be divided into an initial running partition and an upgrading running partition. The initial running partition can be considered as a partition in a working state before the SOC is upgraded, and the upgrading running partition can be considered as a partition in an idle state before the SOC is upgraded. It can be considered that both of the above-mentioned partitions store the first original version program. Therefore, the SOC can upgrade the first original version program in the upgrading running partition according to the first upgrade package in the storage partition, to obtain a first upgraded version program.

[0157] Step 202: If the SOC determines that the SOC is upgraded successfully, the SOC sends an upgrading instruction to the MCU.

[0158] In the embodiments of the present application, the SOC can perform MD5 check after the upgrading is completed. If the check is passed, it can be considered that the SOC is upgraded successfully. On this basis, the SOC can send an upgrading instruction to the MCU, which carries the second upgrade package stored in the storage partition of the SOC, so as to control the MCU to upgrade based on the second upgrade package.

[0159] Step 203: The MCU upgrades the second original version program in the second running partition based on the second upgrade package in response to the upgrading instruction, to obtain a second upgraded version program.

[0160] In the embodiments of the present application, before the upgrading, it can be considered that the second original version program is running in the second running partition of the MCU. After the MCU receives the second upgrade package from the SOC, the original second original version program can be upgraded based on the second upgrade package, to obtain a second upgraded version program. It should be understood that, since the MCU has only one running partition, the MCU needs to enter a boot loader mode in the above-mentioned upgrading process.

[0161] Step 204: If the MCU determines that the MCU is upgraded successfully, the MCU sends a restart instruction to the SOC.

[0162] Step 205: If the MCU determines that the upgrade is successful, the MCU controls itself to restart and, after the restart, runs the second upgraded version program in the second running partition.

[0163] In the embodiment of the present application, after the MCU upgrade is completed, the SOC initiates MD5 verification on the MCU. Of course, other verification methods can also be used, and the present application does not make special limitations on this. If the verification is passed, it can be considered that the MCU upgrade is successful, at which time the MCU can control itself to restart and, after the restart, run the second upgraded version program in the second running partition. At the same time, the MCU also sends a restart instruction to the SOC, so that the SOC can restart at the same time as the MCU in the case of successful upgrade.

[0164] Step 206: If the SOC determines that the MCU upgrade is successful, the SOC restarts in response to the restart instruction and, after the restart, runs the first upgraded version program in the upgrade running partition.

[0165] In the embodiment of the present application, the MCU notifies the SOC after the verification is passed. Then, in the case where the SOC determines that the upgrade is successful and the MCU also upgrades successfully, the SOC and the MCU restart at the same time and, after the restart, run the first upgraded version program in the upgrade running partition.

[0166] It should be understood that, in the case where the SOC has two running partitions, the SOC sets a restart interface flag when determining that the MCU upgrade is successful. Through the restart interface flag, the SOC can switch the running partition during the restart process, that is, the SOC runs in the upgrade running partition after the restart.

[0167] In the above embodiment, in the case where the SOC has two running partitions, the MCU has only one running partition, and the MCU and the SOC upgrade successfully at different times, the MCU and the SOC restart at the same time and, after the restart, the MCU runs the latest version program in the corresponding running partition, and the SOC runs the latest version program in the upgrade running partition by switching the running partition, that is, the MCU and the SOC run the respective latest version programs, so that the MCU and the SOC with strong association can communicate normally in the case where the MCU and the SOC upgrade successfully at different times.

[0168] In some embodiments, considering that the MCU may also fail to upgrade during the upgrade process, if the SOC runs the latest version program and the MCU runs the original version program at this time, the problem of abnormal communication between the SOC and the MCU may also occur. Therefore, in the embodiment of the present application, in the case where the SOC and the MCU are upgraded and the MCU fails to upgrade, the program versions run by the SOC and the MCU can also be unified, so as to ensure that the SOC and the MCU can communicate normally.

[0169] Please refer to FIG. 4, which is a flow diagram of another upgrading method provided by the embodiments of the present application. After step 203 is performed, steps 207 to 211 can also be performed:

[0170] Step 207: If the MCU determines that the upgrading fails, the SOC sends a rollback instruction to the MCU.

[0171] In the MD5 check initiated by the SOC in the embodiments of the present application, if the MCU determines that the check fails, the MCU can notify the SOC of the check result. If the check result received by the SOC is that the check of the MCU fails, it can be determined that the upgrading of the MCU fails. At this time, the SOC can send a rollback instruction to the MCU, which carries the first rollback package stored in the storage partition of the SOC, for controlling the MCU that fails in upgrading to perform version rollback.

[0172] Of course, in the case that the SOC determines that the upgrading of the MCU fails for the first time, the SOC can not directly control the MCU to perform version rollback, but send the second upgrading package to the MCU again, so as to control the MCU to upgrade again. By analogy, if the SOC determines that the number of times of the upgrading of the MCU fails reaches a set threshold, the SOC sends a rollback instruction to the MCU.

[0173] Step 208: The MCU responds to the rollback instruction and rolls back the second upgraded version program in the second running partition based on the first rollback package.

[0174] In the embodiments of the present application, after receiving the rollback instruction from the SOC, the MCU rolls back the second upgraded version program in the second running partition based on the first rollback package, that is, makes the program running in the second running partition roll back to the second original version program. It should be understood that, since the MCU has only one running partition, the MCU needs to be in a bootloader mode in the above rollback process.

[0175] Step 209: If the MCU determines that the rollback succeeds, the MCU sends a restart instruction to the SOC.

[0176] Step 210: If the MCU determines that the rollback succeeds, the MCU controls itself to restart and runs the second original version program in the second running partition after the restart.

[0177] In the embodiments of the present application, if the MCU determines that the rollback succeeds, on the one hand, the MCU controls itself to restart and runs the second original version program in the second running partition after the restart; on the other hand, the MCU also controls the SOC to restart at the same time.

[0178] Step 211: The SOC responds to the restart instruction and restarts, and runs the first original version program in the initial running partition after the restart.

[0179] In the embodiment of the application, the SOC will restart simultaneously with the MCU in the case that the MCU rollback succeeds, and the SOC runs the first original version program in the initial running partition after restarting.

[0180] It should be understood that in the case that the SOC has two running partitions, the SOC sets the restart without switching partition flag bit when determining that the MCU upgrade fails, and through the restart without switching partition flag bit, the SOC will not switch the running partition during the restart process, that is, it is ensured that the SOC still runs in the initial running partition after restarting.

[0181] In the above embodiment, in the case that the SOC has two running partitions, the MCU has only one running partition, and the MCU and the SOC are both upgraded, the MCU will be rolled back in the case that the MCU upgrade fails, and then restart simultaneously with the SOC, and the SOC runs the original version program without switching the running partition after restarting, so that the MCU and the SOC with strong association can communicate normally in the case that the MCU upgrade fails although the MCU and the SOC are both upgraded.

[0182] It should be noted that in the case that the SOC and the MCU are both upgraded, the SOC upgrade failure may also occur, the SOC can set the restart without switching partition flag bit and control itself to directly restart, through the restart without switching partition flag bit, the SOC still runs the first original version program in the initial running partition after restarting, and the MCU is not upgraded, so that the SOC and the MCU run the original version program after restarting, thereby ensuring that the MCU and the SOC with strong association can communicate normally in the case that the SOC upgrade fails although the MCU and the SOC are both upgraded.

[0183] Scenario three: the SOC has two running partitions, and the MCU has one running partition and one backup partition, that is, the SOC has two first running partitions, and the MCU has one second running partition and one backup partition.

[0184] Please refer to FIG. 5, which is a flowchart of an upgrade method provided by an embodiment of the application. The flowchart of the method is described as follows:

[0185] Step 301: The SOC upgrades the first original version program in the upgrade running partition according to the first upgrade package in the storage partition of the SOC, to obtain a first upgrade version program.

[0186] In the embodiment of the present application, the two first running partitions in the SOC can be divided into an initial running partition and an upgraded running partition. The initial running partition can be considered as a partition in a working state before the SOC is upgraded, and the upgraded running partition can be considered as a partition in an idle state before the SOC is upgraded. The two partitions can be considered as both storing the first original version program. Therefore, the SOC can upgrade the first original version program in the upgraded running partition according to the first upgrade package in the storage partition, and obtain the first upgraded version program.

[0187] Step 302: If the SOC determines that the SOC is upgraded successfully, the SOC sends an upgrade instruction to the MCU.

[0188] In the embodiment of the present application, the SOC can perform MD5 check after the upgrade is completed. If the check is passed, it can be considered that the SOC is upgraded successfully. On this basis, the SOC can send an upgrade instruction to the MCU, and the upgrade instruction carries the second upgrade package stored in the storage partition of the SOC, so as to control the MCU to perform upgrade based on the second upgrade package.

[0189] Step 303: The MCU responds to the upgrade instruction, and backs up the second original version program in the second running partition to the backup partition.

[0190] Step 304: The MCU responds to the upgrade instruction, and upgrades the second original version program in the second running partition based on the second upgrade package, to obtain the second upgraded version program.

[0191] In the embodiment of the present application, before the upgrade, it can be considered that the second original version program is running in the second running partition of the MCU. At this time, the second original version program can be backed up to the backup partition of the MCU. On this basis, after the MCU receives the second upgrade package from the SOC, the second original version program in the second running partition can be upgraded based on the second upgrade package to obtain the second upgraded version program. It should be understood that, since the MCU has only one running partition, the MCU needs to enter the boot loader mode in the above-mentioned upgrade process.

[0192] Step 305: If the MCU determines that the MCU is upgraded successfully, the MCU sends a restart instruction to the SOC.

[0193] Step 306: If the MCU determines that the MCU is upgraded successfully, the MCU controls itself to restart, and runs the second upgraded version program in the second running partition after the restart.

[0194] In the embodiment of the present application, after the MCU upgrade is completed, the SOC initiates MD5 check on the MCU. Of course, other ways can also be used for check, and the present application does not make special limitation thereto. If the check is passed, it can be considered that the MCU upgrade is successful, at which time the MCU can restart itself and run the second upgraded version program in the second running partition after the restart. At the same time, the MCU also sends a restart instruction to the SOC, so that the SOC can restart at the same time with the MCU in the case of the same successful upgrade.

[0195] Step 307: If the SOC determines that the MCU upgrade is successful, it restarts in response to the restart instruction and runs the first upgraded version program in the upgraded running partition after the restart.

[0196] In the embodiment of the present application, the MCU notifies the SOC after the check is passed. Then, in the case that the SOC determines that its own upgrade is successful and the MCU also upgrades successfully, it restarts at the same time with the MCU and runs the first upgraded version program in the upgraded running partition after the restart.

[0197] It should be understood that, in the case that the SOC has two running partitions, the SOC sets a restart interface flag when it determines that the MCU upgrade is successful, and through the restart interface flag, the SOC can switch the running partition during the restart process, i.e., ensure that the SOC runs in the upgraded running partition after the restart.

[0198] In the above embodiment, in the case that the SOC has two running partitions, the MCU has only one running partition and one backup partition, and the MCU and the SOC upgrade successfully at different times, they restart at the same time and, after the restart, the MCU runs the latest version program in the corresponding running partition, and the SOC runs the latest version program in the upgraded running partition by switching the running partition, i.e., the MCU and the SOC run the respective latest version programs at the same time, thereby ensuring that the MCU and the SOC with strong association can communicate normally in the case that they upgrade successfully at different times.

[0199] In some embodiments, considering that the MCU can also fail to upgrade during the upgrade process, if the SOC runs the latest version program and the MCU runs the original version program at this time, the problem of abnormal communication between the SOC and the MCU can also occur. Therefore, in the embodiment of the present application, in the case that the SOC and the MCU are upgraded and the MCU fails to upgrade, the program versions respectively run by the SOC and the MCU can also be unified, thereby ensuring that the SOC and the MCU can communicate normally.

[0200] Please refer to FIG. 6, which is a flow diagram of another upgrade method provided by the embodiment of the present application. After step 304 is executed, steps 308 to 312 can also be continuously executed:

[0201] Step 308: If the MCU determines that the self-upgrade fails, the second running partition is rolled back based on the second original version program in the backup partition.

[0202] In the embodiment, in the MD5 check initiated by the SOC, if the MCU determines that the self-check fails, it can be determined that the MCU upgrade fails. Since the second original version program is backed up in the backup partition, the MCU can roll back the second running partition based on the second original version program in the backup partition.

[0203] Step 309: If the MCU determines that the self-rollback succeeds, a restart instruction is sent to the SOC.

[0204] Step 310: If the MCU determines that the self-rollback succeeds, the self-restart is controlled, and the second original version program in the second running partition is run after the restart.

[0205] In the embodiment, if the MCU determines that the self-rollback succeeds, on the one hand, the self-restart is controlled, and the second original version program is run in the second running partition after the restart; on the other hand, the SOC is also controlled to restart simultaneously.

[0206] Step 311: The SOC restarts in response to the restart instruction, and the first original version program in the initial running partition is run after the restart.

[0207] In the embodiment, the SOC restarts simultaneously with the MCU in the case that the MCU rollback succeeds, and the first original version program in the initial running partition is run after the restart of the SOC.

[0208] It should be understood that in the case that the SOC has two running partitions, the SOC sets a restart non-switching face flag bit when determining that the MCU upgrade fails, and through the restart non-switching face flag bit, the SOC can not switch the running partition during the restart process, that is, it is ensured that the SOC still runs in the initial running partition after the restart.

[0209] In the above embodiment, in the case that the SOC has two running partitions, the MCU has only one running partition and one backup partition, and the MCU and the SOC are upgraded, in the case that the MCU upgrade fails, the MCU rolls back using the original version program backed up by the backup partition, and then restarts simultaneously with the SOC, and after the restart, the SOC runs the respective original version programs with the MCU without switching the running partition, so that in the case that the MCU and the SOC with strong association are upgraded but the MCU upgrade fails, normal communication can be ensured.

[0210] It is worth noting that when the SOC and the MCU are both upgraded, the SOC upgrade failure can also occur. The SOC can set a restart non-cutting flag bit and control itself to directly restart. Through the restart non-cutting flag bit, the SOC still runs the first original version program in the initial running partition after the restart, and does not upgrade the MCU. Then, the SOC and the MCU after the restart run the respective original version programs, so that in the case that the MCU and the SOC with strong association are both upgraded but the SOC upgrade failure occurs, normal communication can be performed.

[0211] Scenario four: the SOC has two running partitions, and the MCU has two running partitions, that is, the SOC has two first running partitions, and the MCU has two second running partitions.

[0212] Please refer to FIG. 7, which is a flowchart of another upgrading method provided by an embodiment of the present application. The flow of the method is described as follows:

[0213] Step 401: The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgrade version program.

[0214] In the embodiment of the present application, the two first running partitions in the SOC can be divided into a first initial running partition and a first upgrade running partition. The first initial running partition can be considered as a partition in a working state before the SOC upgrade, and the first upgrade running partition can be considered as a partition in an idle state before the SOC upgrade. It can be considered that the above two partitions both store the first original version program. Therefore, the SOC can upgrade the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgrade version program.

[0215] Step 402: If the SOC determines that the upgrade is successful, the SOC sends an upgrade instruction to the MCU.

[0216] In the embodiment of the present application, the SOC can perform MD5 verification after the upgrade is completed. If the verification is passed, it can be considered that the SOC upgrade is successful. On this basis, the SOC can send an upgrade instruction to the MCU, which carries the second upgrade package stored in the SOC storage partition, so as to control the MCU to upgrade based on the second upgrade package.

[0217] Step 403: The MCU upgrades the second original version program in the second upgrade running partition based on the second upgrade package in response to the upgrade instruction, to obtain a second upgrade version program.

[0218] In the embodiment of the present application, the two second running partitions in the MCU can be divided into a second initial running partition and a second upgrade running partition. The second initial running partition can be considered as a partition in a working state before the upgrade of the MCU, and the second upgrade running partition can be considered as a partition in an idle state before the upgrade of the MCU. The two partitions can be considered as both storing the second original version program. Then, after the MCU receives the second upgrade package from the SOC, the second original version program in the second upgrade running partition can be upgraded based on the second upgrade package to obtain the second upgrade version program.

[0219] Step 404: If the MCU determines that the upgrade is successful, a restart instruction is sent to the SOC.

[0220] Step 405: If the MCU determines that the upgrade is successful, the MCU is controlled to restart, and after the restart, the second upgrade version program in the second upgrade running partition is run.

[0221] In the embodiment of the present application, after the upgrade of the MCU is completed, the SOC initiates MD5 verification on the MCU. Of course, other verification manners can also be used, which are not particularly limited in the present application. If the verification is passed, it can be considered that the upgrade of the MCU is successful. At this time, the MCU can control itself to restart, and after the restart, the second upgrade version program in the second upgrade running partition is run. At the same time, the MCU also sends a restart instruction to the SOC, so that the SOC can restart at the same time in the case of successful upgrade.

[0222] It should be understood that, in the case that the MCU has two running partitions, when the MCU determines that the upgrade is successful, a restart interface flag bit is set. Through the restart interface flag bit, the running partition can be switched during the restart of the MCU, that is, it is ensured that the second upgrade running partition is run after the restart of the MCU.

[0223] Step 406: If the SOC determines that the upgrade of the MCU is successful, the SOC restarts in response to the restart instruction, and after the restart, the first upgrade version program in the first upgrade running partition is run.

[0224] In the embodiment of the present application, after the verification is passed, the MCU notifies the SOC. Then, in the case that the SOC determines that the upgrade is successful and the MCU also upgrades successfully, the SOC restarts at the same time with the MCU, and after the restart, the first upgrade version program in the first upgrade running partition is run.

[0225] It should be understood that, in the case that the SOC has two running partitions, when the SOC determines that the upgrade of the MCU is successful, a restart interface flag bit is set. Through the restart interface flag bit, the running partition can be switched during the restart of the SOC, that is, it is ensured that the first upgrade running partition is run after the restart of the SOC.

[0226] In the above embodiment, in the case that the SOC and the MCU both have two running partitions, and the MCU and the SOC are successfully upgraded at different time, the SOC and the MCU will restart at the same time, and after the restart, the MCU and the SOC will run the latest version program in the upgrade running partition at the same time by switching the running partition, so as to ensure that the MCU and the SOC with strong association can communicate normally in the case that the MCU and the SOC are successfully upgraded at different time.

[0227] In some embodiments, considering that the MCU may also fail to upgrade during the upgrade process, if the SOC runs the latest version program and the MCU runs the original version program, the communication between the SOC and the MCU may also be abnormal. Therefore, in the embodiment of the present application, in the case that the SOC and the MCU are both upgraded and the MCU fails to upgrade, the program version running in the SOC and the MCU can be unified, so as to ensure that the SOC and the MCU can communicate normally.

[0228] Please refer to FIG. 8, which is a flowchart of another upgrade method provided by the embodiment of the present application. After step 403 is executed, steps 407 to 409 can be further executed.

[0229] Step 407: If the MCU determines that it fails to upgrade, it sends a restart instruction to the SOC.

[0230] Step 408: If the MCU determines that it fails to upgrade, it controls itself to restart, and after the restart, it runs the second original version program in the second initial running partition.

[0231] In the MD5 check initiated by the SOC in the embodiment of the present application, if the MCU determines that it fails to check, it can determine that it fails to upgrade. At this time, on the one hand, the MCU controls itself to restart, and after the restart, it runs the second original version program in the second initial running partition; on the other hand, it also controls the SOC to restart at the same time.

[0232] It should be understood that in the case that the MCU has two running partitions, when the MCU determines that it fails to upgrade, the restart without switching flag bit is set, and by the restart without switching flag bit, the MCU will not switch the running partition during the restart, that is, it is ensured that the MCU still runs in the second initial running partition after the restart.

[0233] Step 409: If the SOC determines that the MCU fails to upgrade, it restarts in response to the restart instruction, and after the restart, it runs the first original version program in the first initial running partition.

[0234] In the embodiment of the present application, when the MCU determines that the self-upgrade fails, the SOC is notified. If the SOC determines that the MCU upgrade fails, the SOC and the MCU are simultaneously restarted, and the SOC running the first original version program in the first initial running partition after the restart.

[0235] It should be understood that, in the case that the SOC has two running partitions, when the SOC determines that the MCU upgrade fails, the restart without switching partition flag bit is set, and through the restart without switching partition flag bit, the SOC can not switch the running partition during the restart, that is, the SOC still runs in the first initial running partition after the restart.

[0236] In the above embodiment, in the case that the SOC and the MCU both have two running partitions, and the MCU and the SOC both upgrade in the upgrade running partition, when the MCU upgrade fails, the MCU and the SOC are simultaneously restarted, and after the restart, the SOC and the MCU both run the original version program in the initial running partition without switching the running partition, so that in the case that the MCU and the SOC with strong association both upgrade but the MCU upgrade fails, the normal communication can be ensured.

[0237] It should be noted that, when the SOC and the MCU both upgrade, the SOC upgrade can also fail. The SOC can set the restart without switching partition flag bit and control the self-restart directly. Through the restart without switching partition flag bit, the SOC still runs the first original version program in the initial running partition after the restart, and the MCU is not upgraded. Then, the SOC and the MCU after the restart run the original version program respectively, so that in the case that the MCU and the SOC with strong association both upgrade but the SOC upgrade fails, the normal communication can be ensured.

[0238] It should be understood that, in the above scenarios one to four, the SOC can be upgraded first. In the case that the SOC upgrade succeeds, the MCU is upgraded, and then the two are simultaneously restarted and run the latest version program. Once the SOC upgrade fails, the SOC runs the original version program, and the MCU is not upgraded, or once the MCU upgrade fails, the SOC and the MCU both run the original version program.

[0239] Of course, the MCU can also be upgraded first. In the case that the MCU upgrade succeeds, the SOC is upgraded, and then the two are simultaneously restarted and run the latest version program. Once the MCU upgrade fails, the MCU runs the original version program, and the SOC is not upgraded, or once the SOC upgrade fails, the SOC and the MCU both run the original version program.

[0240] In some embodiments, in addition to the strong association between the SOC and the MCU, the SOC can also have a strong association with the meter, and therefore, the upgrade process of the strongly associated SOC and meter is described in detail below.

[0241] Scenario five: the SOC has two running partitions, and the meter also has two running partitions, i.e., the SOC has two first running partitions, and the meter has two third running partitions.

[0242] Referring to FIG. 9, a flowchart of another upgrade method provided by the embodiments of the present application is shown. The flowchart of the method is described as follows:

[0243] Step 501: The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program.

[0244] In the embodiments of the present application, the two first running partitions in the SOC can be divided into a first initial running partition and a first upgrade running partition. The first initial running partition can be considered as a partition in a working state before the SOC upgrade, and the first upgrade running partition can be considered as a partition in an idle state before the SOC upgrade. Both of the above-mentioned partitions can be considered as storing the first original version program. Therefore, the SOC can upgrade the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program.

[0245] Step 502: The SOC determines that the upgrade is successful, and sends an upgrade instruction to the meter.

[0246] In the embodiments of the present application, the SOC can perform MD5 check after the upgrade is completed. If the check is passed, it can be considered that the SOC upgrade is successful. On this basis, the SOC can send an upgrade instruction to the meter, which carries the third upgrade package stored in the storage partition of the SOC, so as to control the meter to perform upgrade based on the third upgrade package.

[0247] Step 503: The meter upgrades the third original version program in the third upgrade running partition based on the third upgrade package in response to the upgrade instruction, to obtain a third upgraded version program.

[0248] In the embodiment of the present application, the two third operation partitions in the instrument can be divided into a third initial operation partition and a third upgraded operation partition. The third initial operation partition can be considered as a partition in a working state before the instrument is upgraded, and the third upgraded operation partition can be considered as a partition in an idle state before the instrument is upgraded. The two partitions can be considered as both storing the third original version program. Then, after the instrument receives the third upgrade package from the SOC, the third original version program in the third upgraded operation partition can be upgraded based on the third upgrade package to obtain the third upgraded version program.

[0249] Step 504: If the SOC determines that the instrument is upgraded successfully, a restart instruction is sent to the instrument.

[0250] Step 505: If the SOC determines that the instrument is upgraded successfully, the SOC is controlled to restart, and after the restart, the first upgraded version program in the first upgraded operation partition is run.

[0251] In the embodiment of the present application, after the instrument is upgraded, the SOC initiates MD5 verification on the instrument. Of course, other verification manners can also be used, which are not particularly limited in the present application. If the verification is passed, it can be considered that the instrument is upgraded successfully, and the SOC is notified. The SOC can control itself to restart and run the first upgraded version program in the first upgraded operation partition after the restart in the case that the instrument is upgraded successfully. At the same time, the SOC also sends a restart instruction to the instrument, so that the instrument can restart at the same time with the SOC in the case that the instrument is also upgraded successfully.

[0252] It should be understood that in the case that the SOC has two operation partitions, when the SOC determines that the instrument is upgraded successfully, a restart interface flag bit is set. Through the restart interface flag bit, the SOC can switch the operation partition during the restart process, that is, the SOC runs in the first upgraded operation partition after the restart.

[0253] Step 506: If the instrument restarts in response to the restart instruction, and after the restart, the third upgraded version program in the third upgraded operation partition is run.

[0254] In the embodiment of the present application, in the case that the instrument determines that it is upgraded successfully, a restart interface flag bit is set. Through the restart interface flag bit, the instrument switches the operation partition during the restart process, so that the third upgraded version program in the third upgraded operation partition is run after the restart.

[0255] In the above embodiment, in the case that the SOC and the instrument each have two running partitions, and the instrument and the SOC are upgraded successfully at different time points, the SOC and the instrument will restart at the same time, and after restarting, the instrument and the SOC will run the latest version program in the upgraded running partition at the same time by switching the running partition, so as to ensure that the instrument and the SOC with strong association can communicate normally in the case that the instrument and the SOC are upgraded successfully at different time points.

[0256] In some embodiments, considering that the instrument may also fail to upgrade during the upgrading process, if the SOC runs the latest version program and the instrument runs the original version program, the communication between the SOC and the instrument may also be abnormal. Therefore, in the embodiment of the present application, in the case that the SOC and the instrument are upgraded, and the instrument fails to upgrade, the program version running in the SOC and the instrument can also be unified, so as to ensure that the SOC and the instrument can communicate normally.

[0257] Please refer to FIG. 10, which is a flowchart of another upgrading method provided by the embodiment of the present application. After step 503, steps 507 to 509 can also be executed:

[0258] Step 507: If the SOC determines that the instrument fails to upgrade, the SOC sends a restart instruction to the instrument.

[0259] Step 508: If the SOC determines that the instrument fails to upgrade, the SOC controls itself to restart, and after restarting, runs the first original version program in the first initial running partition.

[0260] In the MD5 check initiated by the SOC, if the instrument determines that the check fails, it can be determined that the instrument fails to upgrade. The instrument will notify the SOC of the result of the failure to upgrade. After determining that the instrument fails to upgrade, the SOC will set a restart without switching flag, and then controls itself to restart. During the restarting process, the SOC will not switch the running partition through the restart without switching flag, so that after restarting, the SOC still runs the first original version program in the second initial running partition. On the other hand, the SOC also controls the instrument to restart at the same time.

[0261] Step 509: The instrument restarts in response to the restart instruction, and after restarting, runs the third original version program in the third initial running partition.

[0262] In the embodiment of the present application, in the case that the instrument determines that the instrument fails to upgrade, the restart without switching flag is set. Through the restart without switching flag, the instrument will not switch the running partition during the restarting process, so that after restarting, the instrument still runs the third original version program in the third initial running partition.

[0263] In the above embodiment, in the case that the SOC and the instrument each have two running partitions, and the instrument and the SOC each upgrade in the upgrade running partition, and the instrument upgrade fails, the instrument and the SOC will simultaneously restart, and after the restart, the SOC and the instrument each run the original version program in the initial running partition without switching the running partition, so that in the case that the instrument and the SOC with strong association each upgrade but the instrument upgrade fails, normal communication can be performed.

[0264] Notably, in the case that the SOC and the instrument each upgrade, the SOC upgrade can also fail. The SOC can set a restart without switching flag bit and control itself to directly restart. Through the restart without switching flag bit, the SOC still runs the first original version program in the initial running partition after the restart, and does not upgrade the instrument. Then, the SOC and the instrument after the restart each run the original version program, so that in the case that the instrument and the SOC with strong association each upgrade but the SOC upgrade fails, normal communication can be performed.

[0265] Scenario six: the SOC has two running partitions, and the instrument has one running partition, that is, the SOC has two first running partitions, and the instrument has one third running partition.

[0266] Please refer to FIG. 11, which is a flowchart of another upgrade method provided by the embodiment of the application. The flowchart of the method is described as follows:

[0267] Step 601: The SOC upgrades the first original version program in the upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgrade version program.

[0268] In the embodiment of the application, the two first running partitions in the SOC can be divided into an initial running partition and an upgrade running partition. The initial running partition can be considered as a partition in a working state before the SOC upgrades, and the upgrade running partition can be considered as a partition in an idle state before the SOC upgrades. The above two partitions can be considered as each storing the first original version program. Therefore, the SOC can upgrade the first original version program in the upgrade running partition based on the first upgrade package in the storage partition, to obtain the first upgrade version program.

[0269] Step 602: The SOC determines that the SOC upgrade is successful, and sends an upgrade instruction to the instrument.

[0270] In the embodiment of the application, the SOC can perform MD5 verification after the upgrade is completed. If the verification is passed, it can be considered that the SOC upgrade is successful. On this basis, the SOC can send an upgrade instruction to the instrument, the upgrade instruction carrying the third upgrade package stored in the storage partition of the SOC, so as to control the instrument to upgrade based on the third upgrade package.

[0271] Step 603: The meter upgrades the third original version program in the third running partition based on the third upgrade package in response to the upgrade instruction, to obtain a third upgraded version program.

[0272] In the embodiment of the present application, before upgrading, the third original version program can be considered to be running in the third running partition of the meter. After the meter receives the third upgrade package from the SOC, the original third original version program can be upgraded based on the third upgrade package to obtain a third upgraded version program. It should be understood that, since the meter has only one running partition, the meter needs to enter the bootloader mode during the above-mentioned upgrading process.

[0273] Step 604: If the SOC determines that the meter has been upgraded successfully, the SOC sends a restart instruction to the meter.

[0274] Step 605: If the SOC determines that the meter has been upgraded successfully, the SOC controls itself to restart, and after restarting, the SOC runs the first upgraded version program in the upgraded running partition.

[0275] In the embodiment of the present application, after the meter is upgraded, the SOC initiates MD5 verification on the meter. Of course, other verification methods can also be used, which are not particularly limited in the present application. If the verification is passed, it can be considered that the meter has been upgraded successfully, and the SOC is notified. The SOC can control itself to restart and run the first upgraded version program in the upgraded running partition after restarting, in the case that the meter has been upgraded successfully. At the same time, the SOC also sends a restart instruction to the meter, so that the meter can restart at the same time as the SOC in the case that the meter has also been upgraded successfully.

[0276] It should be understood that, in the case that the SOC has two running partitions, when the SOC determines that the meter has been upgraded successfully, the SOC sets a restart interface flag. Through the restart interface flag, the SOC can switch the running partition during the restarting process, that is, ensure that the SOC runs in the upgraded running partition after restarting.

[0277] Step 606: If the meter restarts in response to the restart instruction, and after restarting, the meter runs the third upgraded version program in the third running partition.

[0278] In the embodiment of the present application, the meter can restart in response to the restart instruction of the SOC, restart at the same time as the SOC, and run the third upgraded program in the third running partition after restarting.

[0279] In the above embodiment, the SOC has two running partitions, the meter has only one running partition, and in the case that the meter and the SOC upgrade successfully at different times, the meter and the SOC will restart at the same time, and after the restart, the SOC runs the latest version program in the running partition by switching the running partition, so that the meter and the SOC with strong association can communicate normally in the case that the meter and the SOC upgrade successfully at different times.

[0280] In some embodiments, considering that the meter may also fail to upgrade during the upgrade process, if the SOC runs the latest version program and the meter runs the original version program, the communication between the SOC and the meter may also be abnormal. Therefore, in the embodiment of the present application, in the case that the SOC and the meter are upgraded and the meter fails to upgrade, the program versions running in the SOC and the meter can also be unified, so as to ensure that the SOC and the meter can communicate normally.

[0281] Please refer to FIG. 12, which is a flowchart of another upgrade method provided by the embodiment of the present application. After step 603 is executed, steps 607 to 611 can also be executed:

[0282] Step 607: If the SOC determines that the meter fails to upgrade, the SOC sends a rollback instruction to the meter.

[0283] In the MD5 check initiated by the SOC in the embodiment of the present application, if the meter determines that the meter fails to upgrade, the meter can notify the SOC of the result of the upgrade failure. If the SOC learns that the meter fails to upgrade, the SOC can send a rollback instruction to the meter, and the rollback instruction carries a third rollback package stored in the storage partition of the SOC, which is used to control the version rollback of the meter that fails to upgrade.

[0284] Of course, in the case that the SOC determines that the meter fails to upgrade for the first time, the SOC can also not directly control the meter to perform version rollback, but send the third upgrade package to the meter again, so as to control the meter to upgrade again. By analogy, if the SOC determines that the number of times that the meter fails to upgrade reaches a set threshold, the SOC will send a rollback instruction to the meter.

[0285] Step 608: The meter rolls back the third upgrade version program in the third running partition based on the third rollback package in response to the rollback instruction.

[0286] In the embodiment of the present application, after receiving the rollback instruction from the SOC, the meter rolls back the third upgrade version program in the third running partition based on the third rollback package, that is, the program running in the third running partition is rolled back to the third original version program. It should be understood that, since the meter has only one running partition, the meter needs to be in the bootloader mode during the above rollback process.

[0287] Step 609: If the SOC determines that the instrument rollback is successful, a restart instruction is sent to the instrument.

[0288] Step 610: If the SOC determines that the instrument rollback is successful, the SOC controls itself to restart, and after the restart, the first original version program in the initial running partition is run.

[0289] In the embodiments of the present application, if the SOC determines that the instrument rollback is successful, on the one hand, the SOC controls itself to restart, and after the restart, the second original version program in the first initial running partition is run; on the other hand, the SOC also controls the instrument to restart at the same time, so that the original version programs of the SOC and the instrument are run at the same time subsequently.

[0290] It should be understood that in the case where the SOC has two running partitions, when the SOC determines that the instrument upgrade fails, the restart without switching flag bit is set, and through the restart without switching flag bit, the SOC will not switch the running partition during the restart, that is, it is ensured that the SOC still runs in the initial running partition after the restart.

[0291] Step 611: The instrument restarts in response to the restart instruction, and after the restart, the third original version program in the third running partition is run.

[0292] In the embodiments of the present application, the instrument restarts at the same time as the SOC in the case where the instrument rollback is successful, and after the restart, the instrument runs the third original version program in the third running partition.

[0293] In the above embodiments, in the case where the SOC has two running partitions, the instrument has only one running partition, and the instrument and the SOC are both upgraded, and the instrument upgrade fails, the instrument will rollback, then restart at the same time as the SOC, and after the restart, the SOC runs the original version programs of the SOC and the instrument at the same time without switching the running partition, so that it is ensured that the instrument and the SOC with strong association are both upgraded, but in the case where the instrument upgrade fails, the instrument can communicate normally.

[0294] It should be noted that when the SOC and the instrument are both upgraded, the SOC upgrade can also fail, the SOC can set the restart without switching flag bit and control itself to directly restart, through the restart without switching flag bit, the SOC still runs the first original version program in the initial running partition after the restart, and the instrument is not upgraded, so that the SOC and the instrument run the original version programs of the SOC and the instrument at the same time after the restart, so that it is ensured that the instrument and the SOC with strong association are both upgraded, but in the case where the SOC upgrade fails, the instrument can communicate normally.

[0295] It should be understood that in the above scenario five to scenario six, the SOC can be upgraded first, and in the case of successful SOC upgrade, the instrument is upgraded, and then both are restarted and run the latest version program. Once the SOC upgrade is unsuccessful, the SOC runs the original version program and does not upgrade the instrument, or once the instrument upgrade is unsuccessful, the SOC and the instrument both run the original version program.

[0296] Of course, the instrument can also be upgraded first, and in the case of successful instrument upgrade, the SOC is upgraded, and then both are restarted and run the latest version program. Once the instrument upgrade is unsuccessful, the instrument runs the original version program and does not upgrade the SOC, or once the SOC upgrade fails, the SOC and the instrument both run the original version program.

[0297] Notably, the plurality of upgrade packages in the storage area of the SOC can also include an upgrade package for the central control screen and / or an upgrade package for the instrument screen. In the present application, the SOC can first upgrade the central control screen and / or the instrument screen based on the above-mentioned upgrade packages, and then upgrade itself and the MCU, or itself and the instrument. Of course, the SOC can also first upgrade itself and the MCU, or itself and the instrument, and then upgrade the central control screen and / or the instrument screen. The present application does not make special limitations in this regard.

[0298] Referring to FIG. 13, based on the same inventive concept, the present embodiment provides a vehicle-mounted system 70, which comprises a SOC 701 and an MCU 702; the SOC 701 has two first running partitions and a storage partition, the storage partition stores a plurality of upgrade packages, and the MCU 702 has a second running partition;

[0299] The SOC 701 is configured to upgrade a first original version program in the upgrade running partition according to a first upgrade package in the storage partition of the SOC itself, to obtain a first upgraded version program, and the upgrade running partition is a running partition other than a currently used initial running partition among the two first running partitions;

[0300] The SOC 701 is further configured to determine that the upgrade is successful, send an upgrade instruction to the MCU 702, and the upgrade instruction carries a second upgrade package in the storage partition;

[0301] The MCU 702 is configured to upgrade a second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction, to obtain a second upgraded version program;

[0302] The MCU 702 is further configured to determine that the upgrade is successful, send a restart instruction to the SOC 701, control itself to restart, and run the second upgraded version program in the second running partition after the restart;

[0303] The SOC 701 is further configured to restart in response to the restart instruction and run the first original version program in the initial running partition after the restart if the MCU 702 is determined to be successfully upgraded.

[0304] Optionally, the SOC 701 is further configured to send a rollback instruction to the MCU 702 if the MCU 702 is determined to fail in the upgrade, the rollback instruction carrying the first rollback package in the storage partition.

[0305] The MCU 702 is further configured to rollback the second upgraded version program in the second running partition based on the first rollback package in response to the rollback instruction.

[0306] The MCU 702 is further configured to send a restart instruction to the SOC 701 and control itself to restart if the MCU 702 is determined to be successfully rolled back, and run the second original version program in the second running partition after the restart.

[0307] The SOC 701 is further configured to restart in response to the restart instruction and run the first original version program in the initial running partition after the restart.

[0308] Optionally, the MCU 702 further comprises a backup partition, and the MCU 702 is further configured to backup the second original version program in the second running partition to the backup partition in response to the upgrade instruction.

[0309] The MCU 702 is further configured to rollback the second running partition based on the second original version program in the backup partition if the MCU 702 is determined to fail in the upgrade.

[0310] The MCU 702 is further configured to send a restart instruction to the SOC 701 and control itself to restart if the MCU 702 is determined to be successfully rolled back, and run the second original version program in the second running partition after the restart.

[0311] The SOC 701 is further configured to restart in response to the restart instruction and run the first original version program in the initial running partition after the restart.

[0312] Optionally, the second running partition is two, and the SOC 701 is further configured to upgrade the first original version program in the first upgraded running partition based on the first upgrade package in the storage partition, to obtain the first upgraded version program, the first upgraded running partition being a running partition other than the currently used first initial running partition among the two first running partitions.

[0313] The SOC 701 is further configured to send an upgrade instruction to the MCU 702 if the SOC 701 is determined to be successfully upgraded, the upgrade instruction carrying the second upgrade package in the storage partition.

[0314] MCU 702 is further configured to upgrade the second original version program in the second upgrade running partition based on the second upgrade package, to obtain a second upgraded version program, the second upgrade running partition being a running partition other than the currently used second initial running partition among the two second running partitions;

[0315] MCU 702 is further configured to, if it is determined that the upgrade is successful, send a restart instruction to SOC 701, and control itself to restart, and run the second upgraded version program in the second upgrade running partition after the restart;

[0316] SOC 701 is further configured to, if it is determined that the upgrade of the MCU is successful, restart in response to the restart instruction, and run the first upgraded version program in the first upgrade running partition after the restart.

[0317] Optionally, MCU 702 is further configured to, if it is determined that the upgrade of the MCU fails, send a restart instruction to SOC, and control itself to restart, and run the second original version program in the second initial running partition after the restart;

[0318] SOC 701 is further configured to, if it is determined that the upgrade of the MCU fails, restart in response to the restart instruction, and run the first original version program in the first initial running partition after the restart.

[0319] Optionally, the vehicle-mounted system further comprises an instrument 703, the instrument 703 comprising two third running partitions, and SOC 701 is further configured to upgrade the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, to obtain a first upgraded version program, the first upgrade running partition being a running partition other than the currently used first initial running partition among the two first running partitions;

[0320] SOC 701 is further configured to, if it is determined that the upgrade of the instrument 703 is successful, send an upgrade instruction to the instrument 703, the upgrade instruction carrying a third upgrade package in the storage partition;

[0321] The instrument 703 is configured to, in response to the upgrade instruction, upgrade a third original version program in a third upgrade running partition based on the third upgrade package, to obtain a third upgraded version program, the third upgrade running partition being a running partition other than the currently used third initial running partition among the two third running partitions;

[0322] SOC 701 is further configured to, if it is determined that the upgrade of the instrument 703 is successful, send a restart instruction to the instrument, and control itself to restart, and run the first upgraded version program in the first upgrade running partition after the restart;

[0323] The instrument 703 is further configured to, in response to the restart instruction, restart, and run the third upgraded version program in the third upgrade running partition after the restart.

[0324] Optionally, the SOC 701 is further configured to, if determining that the instrument 703 fails to upgrade, send a restart instruction to the instrument 703, and control itself to restart, and run the first original version program in the first initial running partition after the restart;

[0325] The instrument 703 is further configured to, in response to the restart instruction, restart, and run the third original version program in the third initial running partition after the restart.

[0326] Optionally, the vehicle-mounted system further comprises the instrument 703, and the instrument 703 comprises a third running partition;

[0327] The SOC 701 is further configured to, based on the first upgrade package in the storage partition, upgrade the first original version program in the upgrade running partition to obtain a first upgraded version program, and the upgrade running partition is a running partition other than the initial running partition currently in use among the two first running partitions;

[0328] The SOC 701 is further configured to, if determining that the instrument 703 upgrades successfully, send an upgrade instruction to the instrument 703, and the upgrade instruction carries a third upgrade package in the storage partition;

[0329] The instrument 703 is further configured to, in response to the upgrade instruction, based on the third upgrade package, upgrade the third original version program in the third running partition to obtain a third upgraded version program;

[0330] The SOC 701 is further configured to, if determining that the instrument 703 upgrades successfully, send a restart instruction to the instrument 703, and control itself to restart, and run the first upgraded version program in the upgrade running partition after the restart;

[0331] The instrument 703 is further configured to, in response to the restart instruction, restart, and run the third upgraded version program in the third running partition after the restart.

[0332] Optionally, the SOC 701 is further configured to, if determining that the instrument 703 fails to upgrade, send a rollback instruction to the instrument, and the rollback instruction carries a third rollback package in the storage partition;

[0333] The instrument 703 is further configured to, in response to the rollback instruction, based on the third rollback package, rollback the third upgraded version program in the third running partition;

[0334] The SOC 701 is further configured to, if determining that the instrument 703 rolls back successfully, send a restart instruction to the instrument 703, and control itself to restart, and run the first original version program in the first initial running partition after the restart;

[0335] The instrument 703 is further configured to, in response to the restart instruction, restart, and run the third original version program in the third running partition after the restart.

[0336] Referring to FIG. 14, based on the same inventive concept, an embodiment of the present application provides a vehicle 80 comprising the vehicle-mounted system 70 as shown in FIG. 13. The vehicle can be a pure electric vehicle, a plug-in hybrid vehicle, or a range-extended vehicle, and the present application does not make special limitations thereto.

[0337] An embodiment of the present application further provides a computer storage medium, wherein the computer storage medium stores computer instructions, and when the computer instructions run on a computer, the computer executes the method as shown in FIGS. 1-12.

[0338] The above merely describes preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An upgrade method characterized by, The method is applied to a vehicle-mounted system including a system on chip (SOC) and a micro control unit (MCU), the SOC has two first running partitions and a storage partition, the storage partition stores a plurality of upgrade packages, the MCU has a second running partition, and the method comprises the following steps: The SOC upgrades a first original version program in an upgrade running partition according to a first upgrade package in the storage partition of the SOC to obtain a first upgraded version program, and the upgrade running partition is a running partition other than an initial running partition currently used in the two first running partitions; The SOC determines that the SOC is upgraded successfully, sends an upgrade instruction to the MCU, and the upgrade instruction carries a second upgrade package in the storage partition; The MCU upgrades a second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction to obtain a second upgraded version program; If the MCU determines that the MCU is upgraded successfully, the MCU sends a restart instruction to the SOC, controls the MCU to restart, and runs the second upgraded version program in the second running partition after the MCU restarts; If the SOC determines that the MCU is upgraded successfully, the SOC restarts in response to the restart instruction, and runs the first upgraded version program in the upgrade running partition after the SOC restarts.

2. The method of claim 1, wherein, After the MCU upgrades the second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction to obtain the second upgraded version program, the method further comprises the following steps: If the SOC determines that the MCU fails to be upgraded, the SOC sends a rollback instruction to the MCU, and the rollback instruction carries a first rollback package in the storage partition; The MCU rolls back the second upgraded version program in the second running partition based on the first rollback package in response to the rollback instruction; If the MCU determines that the MCU is rolled back successfully, the MCU sends a restart instruction to the SOC, controls the MCU to restart, and runs the second original version program in the second running partition after the MCU restarts; The SOC restarts in response to the restart instruction, and runs the first original version program in the initial running partition after the SOC restarts.

3. The method of claim 1, wherein, Before the MCU upgrades the second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction to obtain the second upgraded version program, the method further comprises the following steps: The MCU backs up the second original version program in the second running partition to a backup partition in response to the upgrade instruction; After the MCU upgrades the second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction to obtain the second upgraded version program, the method further comprises the following steps: If the MCU determines that the MCU fails to be upgraded, the MCU rolls back the second running partition based on the second original version program in the backup partition; If the MCU determines that the MCU fails to be upgraded, the MCU rolls back the second running partition based on the second original version program in the backup partition; If the MCU determines that the rollback is successful, the MCU sends a restart instruction to the SOC, controls itself to restart, and runs the second original version program in the second running partition after the restart; The SOC restarts in response to the restart instruction, and runs the first original version program in the initial running partition after the restart.

4. The method of claim 1, wherein, The second running partition is two, and the method further comprises: The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, obtains a first upgrade version program, and the first upgrade running partition is a running partition other than a currently used first initial running partition in the two first running partitions; The SOC determines that the upgrade is successful, sends an upgrade instruction to the MCU, and the upgrade instruction carries a second upgrade package in the storage partition; The MCU upgrades the second original version program in the second upgrade running partition based on the second upgrade package in response to the upgrade instruction, obtains a second upgrade version program, and the second upgrade running partition is a running partition other than a currently used second initial running partition in the two second running partitions; If the MCU determines that the upgrade is successful, the MCU sends a restart instruction to the SOC, controls itself to restart, and runs the second upgrade version program in the second upgrade running partition after the restart; If the SOC determines that the MCU upgrade is successful, the SOC restarts in response to the restart instruction, and runs the first upgrade version program in the first upgrade running partition after the restart.

5. The method of claim 4, wherein, After the MCU upgrades the second original version program in the second upgrade running partition based on the second upgrade package, obtains a second upgrade version program, the method further comprises: If the MCU determines that the upgrade is unsuccessful, the MCU sends a restart instruction to the SOC, controls itself to restart, and runs the second original version program in the second initial running partition after the restart; If the SOC determines that the MCU upgrade is unsuccessful, the SOC restarts in response to the restart instruction, and runs the first original version program in the first initial running partition after the restart.

6. The method of claim 1, wherein, The vehicle-mounted system further comprises an instrument, the instrument comprises two third running partitions, and the method further comprises: The SOC upgrades the first original version program in the first upgrade running partition based on the first upgrade package in the storage partition, obtains a first upgrade version program, and the first upgrade running partition is a running partition other than a currently used first initial running partition in the two first running partitions; The SOC determines that the upgrade is successful, sends an upgrade instruction to the instrument, and the upgrade instruction carries a third upgrade package in the storage partition; The instrument upgrades the third original version program in the third upgrade running partition based on the third upgrade package in response to the upgrade instruction, obtains a third upgrade version program, and the third upgrade running partition is a running partition other than a currently used third initial running partition in the two third running partitions; and The instrument runs the third upgrade version program in the third upgrade running partition after the restart. If the SOC determines that the instrument upgrades successfully, a restart instruction is sent to the instrument, the SOC is controlled to restart, and the first upgraded version program in the first upgrade running partition is run after the SOC restarts; The instrument restarts in response to the restart instruction, and the third upgraded version program in the third upgrade running partition is run after the instrument restarts.

7. The method of claim 6, wherein, After the instrument upgrades the third original version program in the third running partition based on the third upgrade package to obtain a third upgraded version program in response to the upgrade instruction, the method further includes: If the SOC determines that the instrument upgrades unsuccessfully, a restart instruction is sent to the instrument, the SOC is controlled to restart, and the first original version program in the first initial running partition is run after the SOC restarts; The instrument restarts in response to the restart instruction, and the third original version program in the third initial running partition is run after the instrument restarts.

8. The method of claim 1, wherein, The vehicle-mounted system further includes an instrument, and the instrument includes a third running partition. The method further includes: The SOC upgrades a first original version program in an upgrade running partition based on a first upgrade package in the storage partition to obtain a first upgraded version program, and the upgrade running partition is a running partition other than a currently used initial running partition among the two first running partitions; The SOC determines that the SOC upgrades successfully, sends an upgrade instruction to the instrument, and the upgrade instruction carries a third upgrade package in the storage partition; The instrument upgrades a third original version program in a third running partition based on the third upgrade package in response to the upgrade instruction to obtain a third upgraded version program; If the SOC determines that the instrument upgrades successfully, a restart instruction is sent to the instrument, the SOC is controlled to restart, and the first upgraded version program in the first upgrade running partition is run after the SOC restarts; The instrument restarts in response to the restart instruction, and the third upgraded version program in the third upgrade running partition is run after the instrument restarts.

9. The method of claim 8, wherein, After the instrument upgrades the third original version program in the third running partition based on the third upgrade package to obtain a third upgraded version program, the method further includes: If the SOC determines that the instrument upgrades unsuccessfully, a rollback instruction is sent to the instrument, and the rollback instruction carries a third rollback package in the storage partition; The instrument rolls back the third upgraded version program in the third running partition based on the third rollback package in response to the rollback instruction; If the SOC determines that the instrument rolls back successfully, a restart instruction is sent to the instrument, the SOC is controlled to restart, and the first original version program in the first initial running partition is run after the SOC restarts; The instrument restarts in response to the restart instruction, and the third original version program in the third running partition is run after the instrument restarts.

10. An in-vehicle system characterized by comprising: The vehicle-mounted system comprises a system on chip (SOC) and a micro control unit (MCU), the SOC has two first running partitions and a storage partition, a plurality of upgrade packages are stored in the storage partition, and the MCU has a second running partition; The SOC is configured to upgrade a first original version program in an upgrade running partition according to a first upgrade package in the storage partition of the SOC, to obtain a first upgraded version program, and the upgrade running partition is a running partition other than a currently used initial running partition among the two first running partitions; The SOC is further configured to send an upgrade instruction to the MCU if it is determined that the upgrade is successful, and the upgrade instruction carries a second upgrade package in the storage partition; The MCU is configured to upgrade a second original version program in the second running partition based on the second upgrade package in response to the upgrade instruction, to obtain a second upgraded version program; The MCU is further configured to determine that the upgrade is successful, send a restart instruction to the SOC, control itself to restart, and run the second upgraded version program in the second running partition after the restart; The SOC is further configured to restart in response to the restart instruction if it is determined that the upgrade of the MCU is successful, and run the first upgraded version program in the upgrade running partition after the restart.

11. A vehicle characterized by comprising: The vehicle-mounted system of claim 10 is included.

Images