Software upgrading system, method and equipment and vehicle

Abstract

The invention provides a software upgrading system, method and equipment and a vehicle. The software upgrading system comprises a control device and M control units, wherein M is a positive integer. The M control units comprise a first control unit, the control device comprises a first partition and a second partition, the first control unit comprises a first storage area, a second software version is deployed in the first partition, and a first software version is deployed in the second partition. The control device is used for receiving a third software version and updating the first software version in the second partition into the third software version; and sending the third software version to the first control unit. The first control unit is used for updating the second software version deployed in the first storage area into a third software version; the first software version, the second software version and the third software version are different versions of software corresponding to the first control unit. Therefore, the software upgrading reliability of the vehicle-mounted equipment is improved.

Description

Software upgrade system, method, device and vehicle Technical Field

[0001] The present application relates to the field of smart cars, and in particular to a software upgrade system, method, device and vehicle. Background Art

[0002] During vehicle software upgrades using over-the-air (OTA) technology, interruptions due to external factors are unavoidable. For example, an interruption in the vehicle's electronic control unit (ECU) upgrade can cause the ECU to become inoperable due to a software failure. Therefore, improving the reliability of vehicle-mounted device software upgrades is a pressing issue.

[0003] Summary of the Invention

[0004] The present application provides a software upgrade system, method, device and vehicle to improve the reliability of software upgrades of vehicle-mounted equipment.

[0005] In a first aspect, the present application provides a software upgrade system, comprising a control device and M control units, where M is a positive integer, the M control units including a first control unit, the control device including a first partition and a second partition, the first control unit including a first storage area, the first partition being deployed with the second software version, and the second partition being deployed with the first software version; the control device being used to: receive the third software version; update the first software version in the second partition to the third software version; and send the third software version to the first control unit; the first control unit being used to: update the second software version deployed in the first storage area to the third software version; the first software version, the second software version, and the third software version being different versions of the software corresponding to the first control unit.

[0006] Through the software upgrade system provided by the first aspect, the control device updates the first software version deployed in the second partition to the third software version, and sends the third software version to the first control unit. During the process of the first control unit updating the second software version deployed in the first storage area to the third software version, the second software version is still maintained in the first partition of the control device to ensure that the first control unit can quickly roll back to the second software version after the upgrade fails or the upgrade is abandoned, thereby improving the reliability of the software upgrade.

[0007] In a possible implementation, when sending the third software version to the first control unit, the control device is specifically configured to send the third software version and information of the first storage area to the first control unit.

[0008] Through the software upgrade system provided by this embodiment, the first control unit can determine the flashing location of the third software version based on the information in the first storage area, thereby improving the efficiency of software upgrade.

[0009] In one possible embodiment, the first control unit also includes a second storage area, and the first control unit is further used to: update the first software version deployed in the second storage area to the third software version; switch the roles of the first storage area and the second storage area, which roles include the main storage area or the backup storage area.

[0010] Through the software upgrade system provided by this embodiment, the first control unit deploys the first storage area and the second storage area, realizing dual partitioning, improving the reliability of software upgrades, and the two storage areas correspond to the two partitions of the control device respectively, which facilitates the control device to synchronize the software version with the first control unit, thereby improving processing efficiency.

[0011] In one possible embodiment, after sending the third software version to the first control unit, the control device is further used to: detect whether there is a trigger event, the trigger event is used to trigger the third software version deployed in the first storage area to roll back to the second software version; when the trigger event exists, send the second software version to the first control unit; the first control unit is further used to: receive the second software version; and roll back the third software version deployed in the first storage area to the second software version.

[0012] With the software upgrade system provided by this embodiment, when a triggering event occurs, the control device sends the second software version to the first control unit, so that the first control unit quickly rolls back the third software version to the second software version.

[0013] In one possible embodiment, after sending the third software version to the first control unit, the control device is further used to: detect whether there is a trigger event, the trigger event is used to trigger the third software version deployed in the first storage area to roll back to the second software version; when the trigger event exists, send indication information to the first control unit, the indication information is used to instruct the third software version deployed in the first storage area to roll back to the second software version; the first control unit is also used to switch the roles of the first storage area and the second storage area.

[0014] Through the software upgrade system provided by this embodiment, the first control unit can implement rapid rollback of the software version by switching between the first storage area and the second storage area.

[0015] In a possible implementation, the triggering event includes one of the following:

[0016] The third software version has an anomaly;

[0017] Cancel the upgrade;

[0018] The third software version update failed.

[0019] Through the software upgrade system provided by this embodiment, the control device triggers software version rollback under abnormal circumstances, thereby ensuring the reliability of software upgrades.

[0020] In one possible embodiment, the trigger event includes an abnormality in the third software version. When the control device detects whether the trigger event exists, the control device is specifically used to: detect whether the third software version belongs to a version set, the version set includes N matching software versions, and the N matching software versions are software versions corresponding to N control units; or, when the N control units respectively run the corresponding software, detect whether there is a control unit with abnormal operation among the N control units; wherein the N control units include the first control unit, the N control units are coupled to each other, N is less than or equal to M, and N is an integer greater than 1.

[0021] The software upgrade system provided by this embodiment detects that the software versions running after the software version upgrade of N control units with a coupling relationship are all mutually complementary software versions, so as to ensure that the N control units operate normally and stably, thereby improving the reliability of the software upgrade.

[0022] In a possible implementation manner, the control device is further configured to: obtain association information between the M control units; and determine the N control units from the M control units based on the association information.

[0023] Through the software upgrade system provided by this embodiment, the control device is based on the association information between M control units. For example, the association information may include the business interaction relationship between the M control units. The control device can identify N control units with a coupling relationship from the M control units, thereby ensuring that the N control units run the matching software version after the software upgrade, thereby improving the reliability of the software upgrade.

[0024] In one possible implementation, the control device is specifically used to: determine the orchestration information of the M control units based on the association information, the orchestration information indicating the order in which the M control units perform software version upgrades; and send the third software version to the first control unit based on the orchestration information.

[0025] Through the software upgrade system provided by this embodiment, the control device determines the arrangement information of M control units, which can ensure that each control unit is upgraded in the order of software version upgrade during the software upgrade process, ensure that all control units with dependent relationships can complete the software version upgrade, reduce the possibility of upgrade anomalies, and improve the reliability of software upgrades.

[0026] In a possible implementation, the arrangement information further instructs the M control units to perform software version upgrades in a serial and / or parallel manner.

[0027] The software upgrade system provided by this implementation, on the one hand, can upgrade the software version of control units with dependencies in a serial manner, thereby improving upgrade reliability; on the other hand, for control units without dependencies, can upgrade the software version in a parallel manner, thereby improving upgrade efficiency.

[0028] In a possible implementation, the control device is further configured to store a mapping relationship, where the mapping relationship indicates a correspondence between partitions of the control device and storage areas of the first control unit.

[0029] Through the software upgrade system provided by this embodiment, the control device saves the mapping relationship between the partitions of the control device and the storage areas of the first control unit, which facilitates the control device to synchronize the software version with the first control unit.

[0030] In one possible implementation, the first partition is a logical partition or a physical partition; and / or the second partition is a logical partition or a physical partition; wherein the physical partition is a physical storage area of ​​the memory of the control device, and the logical partition is a mapping area of ​​the physical storage area of ​​the memory.

[0031] Through the software upgrade system provided by this embodiment, when the partition of the control device is a logical partition, the storage area overhead can be saved; when the partition of the control device is a physical partition, the reliability of the software upgrade can be improved. For example, when the storage space of the first control unit is limited, the memory of the control device stores the currently running software version and the previous software version to facilitate version rollback of the first control unit.

[0032] In a possible implementation, the first storage area corresponds to the first mirror area, and the software version deployed in the first mirror area is the same as the software version deployed in the first storage area.

[0033] The software upgrade system provided by this embodiment sets a mirror area corresponding to the storage area in the first control unit, so that when a data abnormality occurs in the storage area, the software version in the mirror area is switched to be executed, thereby further improving the reliability of the software system.

[0034] In a possible implementation, the control device is further configured to: after the first control unit switches the roles of the first storage area and the second storage area, establish a corresponding relationship between the first mirror partition and the switched primary storage area.

[0035] The software upgrade system provided by this embodiment ensures that the main storage area of ​​the first control unit has a corresponding first mirror partition, so that the software version in the main storage area can be synchronized to the first mirror partition. When a data abnormality occurs in the main storage area, the software version in the mirror area is switched to be executed, thereby improving the reliability of the software system.

[0036] In a possible implementation, the second storage area corresponds to the second mirror area, and the software version deployed in the second mirror area is the same as the software version deployed in the second storage area.

[0037] Through the software upgrade system provided by this embodiment, the main storage area and the backup storage area of ​​the first control unit are respectively bound to the corresponding mirror area, and there is no need to modify the binding relationship between the mirror area and the storage area, thereby improving the processing efficiency of the software system.

[0038] In a possible embodiment, the control device is further used to: when there is a data abnormality in the first storage area, send a switching instruction to the first control unit, the switching instruction is used to instruct to switch the first mirror partition to the main storage area; the first control unit is used to switch the first mirror partition to the main storage area according to the switching instruction.

[0039] Through the software upgrade system provided by this embodiment, when there is a data abnormality in the first storage area, the first control unit switches the first mirror partition to the main storage area, so that the first control unit continues to run the software version backed up in the first mirror partition, avoiding version rollback of the first control unit.

[0040] In one possible embodiment, the control device is further used to: send a pause instruction to the first control unit, the pause instruction is used to instruct to pause the software upgrade task, the software upgrade task is to upgrade the second software version to the third software version; the first control unit is further used to: pause the software upgrade task according to the pause instruction and save breakpoint information; send the breakpoint information to the control device; wherein the breakpoint information includes at least one of the following: task parameters, task progress, or orchestration information.

[0041] Through the software upgrade system provided by this embodiment, the software upgrade task of the first control unit can be suspended during the software upgrade process to avoid the upgrade time being long and affecting the use of the vehicle.

[0042] In one possible embodiment, the control device is also used to: detect whether there is a suspended software upgrade task, which is to upgrade the second version of the software to the third version of the software; when there is a suspended software upgrade task, obtain the breakpoint information of the software upgrade task; according to the breakpoint information, send a continue upgrade instruction to the first control unit, and the continue upgrade instruction is used to instruct to continue executing the software upgrade task; the first control unit is also used to continue executing the software upgrade task according to the breakpoint information and the continue upgrade instruction.

[0043] Through the software upgrade system provided by this embodiment, when the control device determines that there is a suspended software upgrade task, it can continue to execute the software upgrade task and realize breakpoint resumption during the upgrade process to improve the convenience of users in using the car.

[0044] In a second aspect, the present application provides a software upgrade control method, which is applied to a control device, wherein the control device includes a first partition and a second partition, the first partition is deployed with a second software version, and the second partition is deployed with a first software version. The method includes: receiving a third software version; updating the first software version in the second partition to the third software version; and sending the third software version to the first control unit.

[0045] In a possible implementation, when the third software version of the software is sent to the first control unit, the third software version and information of the first storage area are sent to the first control unit, and the first control unit includes the first storage area.

[0046] In a possible implementation, after sending the third version of the software to the first control unit, the method further includes: detecting whether there is a trigger event, the trigger event being used to trigger the rollback of the third software version to the second software version; when the trigger event exists, sending the second software version to the first control unit, or sending indication information to the first control unit, the indication information instructing the rollback of the third software version to the second software version.

[0047] In a possible implementation, the triggering event includes one of the following:

[0048] The third software version has an anomaly;

[0049] Cancel the upgrade;

[0050] The third software version update failed.

[0051] In one possible embodiment, the trigger event includes an abnormality in the third software version, and the detection of whether the trigger event exists includes: detecting whether the third software version belongs to a version set, the version set includes N matching software versions, and the N matching software versions are software versions corresponding to N control units respectively; or, when the N control units respectively run the corresponding software, detecting whether there is a control unit with an abnormal operation among the N control units; wherein the N control units include the first control unit, the N control units are coupled to each other, N is less than or equal to M, and N and M are both integers greater than 1.

[0052] In a possible implementation, the method further includes: acquiring association information between the M control units; and determining the N control units from the M control units based on the association information.

[0053] In one possible implementation, sending the third software version to the first control unit includes: determining, based on the association information, the orchestration information of the M control units, the orchestration information indicating the order in which the M control units perform software version upgrades; and sending the third software version to the first control unit based on the orchestration information.

[0054] In a possible implementation, the arrangement information further instructs the M control units to perform software version upgrades in a serial and / or parallel manner.

[0055] In a possible implementation, the method further includes: storing a mapping relationship, where the mapping relationship indicates a correspondence between the partitions of the control device and the storage areas of the first control unit.

[0056] In one possible implementation, the first partition is a logical partition or a physical partition; and / or the second partition is a logical partition or a physical partition; wherein the physical partition is a physical storage area of ​​the memory of the control device, and the logical partition is a mapping area of ​​the physical storage area of ​​the memory.

[0057] In a possible implementation, the first storage area corresponds to the first mirror area, and the version of the software deployed in the first mirror area is the same as the version of the software deployed in the first storage area.

[0058] In a possible implementation, after sending the third software version to the first control unit, the method further includes: establishing a corresponding relationship between the first mirror partition and the switched primary storage area.

[0059] In a possible implementation, the method further includes: when data abnormality exists in the first storage area, sending a switching instruction to the first control unit, where the switching instruction is used to instruct to switch the first mirror partition to the primary storage area.

[0060] In a possible implementation, the method further includes: sending a pause instruction to the first control unit, where the pause instruction is used to instruct to pause a software upgrade task, where the software upgrade task is to upgrade the second software version to the third software version.

[0061] In a possible implementation, the method further includes: acquiring breakpoint information of the first control unit; wherein the breakpoint information includes at least one of the following: task parameters, task progress, or scheduling information.

[0062] In a possible implementation, the method further includes: detecting whether there is a suspended software upgrade task, where the software upgrade task is to upgrade the running first software from the second software version to the third software version; when there is a suspended software upgrade task, sending a continue upgrade instruction to the first control unit based on the breakpoint information, where the continue upgrade instruction is used to instruct to continue executing the software upgrade task.

[0063] The beneficial effects of the control device provided by the second aspect and its possible implementation methods can be found in the beneficial effects brought about by the first aspect and its possible implementation methods, and will not be repeated here.

[0064] In a third aspect, the present application provides a control device, comprising: a module for executing the method in the second aspect or each possible implementation manner.

[0065] In a fourth aspect, the present application provides a vehicle comprising: a control device, the control device comprising a first partition and a second partition, the first partition being deployed with a second software version, the second partition being deployed with a first software version, the control device being used to execute the method as in the second aspect or each possible implementation.

[0066] In a possible implementation manner, M control units are further included, where M is a positive integer, and the M control units include the first control unit.

[0067] In a fifth aspect, the present application provides a chip, comprising: a processor for calling and executing computer instructions from a memory, so that a device equipped with the chip executes the method in the second aspect or each possible implementation.

[0068] In a sixth aspect, the present application provides a computer-readable storage medium for storing computer program instructions, wherein the computer program enables a computer to execute the method in the second aspect or each possible implementation manner.

[0069] In a seventh aspect, the present application provides a computer program product, comprising computer program instructions, which enable a computer to execute the method in the second aspect or each possible implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0071] FIG2 is a schematic diagram of another application scenario provided by an embodiment of the present application;

[0072] FIG3 is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of the present application;

[0073] FIG4a is a schematic diagram of a partition mapping provided in an embodiment of the present application;

[0074] FIG4 b is a schematic diagram of partition binding provided in an embodiment of the present application;

[0075] FIG5 is a schematic diagram of a gateway topology relationship provided in an embodiment of the present application;

[0076] FIG6 is a schematic diagram of a control unit group provided in an embodiment of the present application;

[0077] FIG7a is a schematic diagram of another partition mapping provided in an embodiment of the present application;

[0078] FIG7 b is a schematic diagram of another partition binding provided in an embodiment of the present application;

[0079] FIG7c is a schematic diagram of another partition binding provided in an embodiment of the present application;

[0080] FIG8 is a schematic diagram of a software upgrade control process according to an embodiment of the present application;

[0081] FIG9 is a schematic diagram of a partition switching process provided by an embodiment of the present application;

[0082] FIG10 is a schematic diagram of an execution sequence of a control unit provided in an embodiment of the present application;

[0083] Figures 11a and 11b are schematic diagrams of a process of breakpoint upgrade recovery provided by an embodiment of the present application;

[0084] FIG12 is a schematic diagram of a software upgrade state machine of a control unit provided in an embodiment of the present application;

[0085] FIG13 is a flow chart of a software upgrade control method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0086] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0087] The technical solution of the embodiment of the present application can be applied to an electronic device.

[0088] The electronic device may be a mobile device or a device deployed in a mobile device. The mobile device may have any appearance, such as an intelligent vehicle, an intelligent robot, etc. The intelligent vehicle may be an autonomous vehicle that automatically controls all functions, or an assisted driving vehicle that automatically controls some functions to provide driving assistance. Hereinafter, both autonomous vehicles and assisted driving vehicles are referred to as vehicles.

[0089] The electronic device may be a terminal device. For example, a handheld device, an in-vehicle device, etc. Currently, some examples of terminal devices may include: a mobile phone, a tablet computer (pad), a computer (such as a laptop, a PDA, etc.), a mobile Internet device (MID), a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, an in-vehicle device, a wearable device, etc.

[0090] For ease of understanding, the following description will be given by taking the application of the technical solution of the present application in a vehicle as an example.

[0091] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of the present application. As shown in Figure 1, a vehicle-side software upgrade system 100 is wirelessly connected to a cloud-based service platform 200. Software upgrade system 100 and service platform 200 can enable remote vehicle management via an over-the-air (OTA) mobile communications interface.

[0092] OTA (Over-the-Air) is a technology that updates vehicle systems by downloading upgrade data packages over wireless networks. Compared to traditional vehicle recalls to repair system defects, OTA is widely used due to its low cost and high efficiency. OTA also helps add new features to vehicles and enhance the user experience.

[0093] Vehicle OTA can include the following two categories:

[0094] 1) Firmware-over-the-air (FOTA): This allows the vehicle to download a firmware image from the cloud via wireless or mobile networks to upgrade the vehicle's cockpit, powertrain, chassis, body, intelligent driving, and other ECU nodes. For example, the vehicle's steering system can be upgraded, as can the accelerator pedal's response.

[0095] 2) Software-over-the-air (SOTA): Also known as application online upgrade, it mainly focuses on user-perceived in-vehicle application software upgrades, including applications, human-machine interfaces, in-vehicle maps, voice library updates, etc.

[0096] For example, the service platform 200 includes an OTA server 210, which manages and controls the entire vehicle's OTA upgrade process, including vehicle management, upgrade package management, upgrade strategies, and upgrade maintenance and testing capabilities. The service platform 200 can send software upgrade packages and / or upgrade instructions to the software upgrade system 100, and the service platform 200 and the software upgrade system 100 can also exchange upgrade status.

[0097] Exemplarily, a control device 110 and at least one control unit 120 are deployed in the software upgrade system 100. The control device 110 may include an OTA manager 111, an update agent 112, and an upgrade control device 113. The OTA manager 111 is used to connect to the OTA server 210 and is responsible for downloading software upgrade packages and controlling the upgrade process for multiple control units 120 (such as 120-a to 120-n) in the vehicle. The update agent 112 is used to provide a unified interface to be compatible with different in-vehicle communication networks and communication protocols, thereby adapting to the interface differences of different vehicles.

[0098] The upgrade control device 113 is used to implement software upgrade control for at least one control unit (e.g., 120-a to 120-n). Exemplarily, the upgrade control device 113 includes an installation management module 113-1, an inventory management module 113-2, an update mode management module 113-3, an installer execution module 113-4, and an upgrade partition management module 113-5.

[0099] Among them, the installation management module 113-1, or installer manager, is used to provide a unified northbound service interface for the update agent 112 to call, and to arrange the upgrade sequence (including but not limited to serial and / or parallel) of multiple control units (such as 120-a to 120-n), and manage the upgrade progress and / or upgrade status.

[0100] The asset management module 113-2 is used to provide asset management and asset information collection functions. The assets of the control unit may include the version, supplier number, serial number, etc. of the control unit.

[0101] The upgrade mode management module 113 - 3 is used to provide an upgrade mode switching function, such as controlling the control unit to enter and exit the upgrade mode.

[0102] The installation execution module 113 - 4 is used to control the installation, activation, rollback (ie, version rollback), upgrade suspension, upgrade resumption, upgrade stop, etc. of the control unit software.

[0103] The upgrade partition management module 113-5 is used to manage the physical partitions and / or logical partitions of the upgrade control device 113 itself, as well as the physical storage partitions of the control unit (such as the primary storage area, backup storage area, and mirror area, etc., as described below). For example, the upgrade partition management module 113-5 can perform at least one of the following: partition failure detection; mapping management between the logical partitions of the upgrade control device 113 and the physical storage partitions of each control unit; binding management between the primary storage area and mirror partitions of the control unit; binding management between the backup storage area and mirror partitions of the control unit, etc.

[0104] The control unit (e.g., 120 - a to 120 - n ) may be an ECU, also known as a "driving computer," "on-board computer," etc. For example, the ECU may include a microcontroller unit (MCU), memory (e.g., read-only memory (ROM) or random access memory (RAM)), input / output (I / O) interfaces, an analog-to-digital (A / D) converter, and large-scale integrated circuits such as those for shaping and driving.

[0105] ECUs can be used to implement vehicle-side functional units, such as advanced driving assistance systems (ADAS), in-vehicle infotainment systems (IVI), vehicle control units (VCU), body control modules (BCM), thermal management systems (TMS), and more.

[0106] For example, the control device 110 can be interconnected with the ECUs (such as 120 - a to 120 - n) via a gateway. The control device 110 and the gateway can communicate based on the ETH protocol, and the gateway and the ECUs can communicate based on the Controller Area Network (CAN) protocol.

[0107] In some scenarios, in order to improve the management capabilities of each control unit (such as 120-a to 120-n), the vehicle system can be divided into multiple domains (such as vehicle control domain, intelligent driving domain, cockpit domain, etc.). A control device performs software upgrade management on the control units in a domain. For example, referring to Figure 2, the control device 110-1 in the cockpit domain performs software upgrade management on ECUs 120-a to 120-g, the control device 110-2 in the intelligent driving domain performs software upgrade management on ECUs 120-h to 120-k, and the control device 110-3 in the vehicle control domain performs software upgrade management on ECUs 120-l to 120-n.

[0108] When the control device is deployed within a domain, the upgrade control device in the control device (such as at least one of 110-1 to 110-3) can be implemented as a domain upgrade manager (DUM). It should be understood that this application does not limit the naming of the control device deployed within the domain, and DUM is an example.

[0109] During the software upgrade process, in order to improve upgrade performance and reliability, a dual-partition design is considered for the ECU to quickly implement version rollback after a software upgrade fails. For example, the upgrade process can be: when software version v2 stored in primary partition A is running normally, software version v1 stored in backup partition B is in standby mode. After receiving the upgrade task, update agent 112 upgrades the software version in backup partition B to v3 without affecting the operation of software version v2 in primary partition A. After the upgrade is complete, partition switching is performed, with partition A serving as the backup partition and partition B as the primary partition, and a reset is implemented. After the system starts, software version v3 in primary partition B runs.

[0110] However, some ECUs with limited memory space cannot support dual-partition designs. Single-partition designs can cause ECU functionality to fail if a partition is damaged, and they don't support fast rollback, reducing the reliability of software upgrades. This application addresses this issue by mapping dual partitions in an external device to internal partitions in the ECU, enabling dual-partition management for ECUs with limited memory space and improving the reliability of ECU software upgrades.

[0111] It should be understood that this application only uses ECU as an example for illustration and is not limited to this. The software upgrade method provided in this application is also applicable to other devices with smaller memory space.

[0112] The control device 110 in the software upgrade system 100 can be implemented in hardware as an electronic device 300 as shown in FIG3 . The electronic device 300 may include a processor 310 and a memory 320. The processor 310 and the memory 320 communicate with each other via an internal connection path. The memory 320 is used to store instructions, and the processor 310 is used to execute the instructions stored in the memory 320. In some embodiments, the memory 320 includes storage partitions, such as the first partition and the second partition described below.

[0113] Optionally, the memory 320 may include a read-only memory and a random access memory, and provide instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. The memory 320 may be a separate device or integrated into the processor 310.

[0114] In some embodiments, the electronic device 300 may further include an input interface 330. The processor 310 may control the input interface 330 to communicate with other devices or chips, and specifically, may obtain information or data sent by other devices or chips.

[0115] In some embodiments, the electronic device 300 may further include an output interface 340. The processor 310 may control the output interface 340 to communicate with other devices or chips, and specifically, may output information or data to other devices or chips.

[0116] The division of the units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.

[0117] It should be understood that the processor in the embodiments of the present application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiment can be completed by an integrated logic circuit of the hardware in the processor or by instructions in the form of software. The above processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or performed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as a hardware decoding processor for completion, or can be completed using a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0118] It is understood that the memory in the embodiment of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory.

[0119] The volatile memory may be a random access memory (RAM), which is used as an external cache memory. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0120] The embodiments of the present application do not limit the number of control devices and control units. Both the control device and the control unit can be one or more, and one control device can control the software upgrade of one control unit, and can also control the software upgrade of multiple control units.

[0121] Figure 4a is a schematic diagram of a partition mapping provided in an embodiment of the present application. In conjunction with Figure 4a, the present embodiment is described using a control device 410a and a first control unit 420a as an example. The first control unit is any one of the M control units, and the M control units are some or all of the storage units attached to the control device (such as control units 120-a to 120-n in Figures 1 or 2), where M is a positive integer.

[0122] The control device 410a includes a first partition and a second partition. The first partition can be a physical partition or a logical partition. When the first partition is a physical partition, the first partition can be a physical storage area of ​​the memory of the control device 410a (such as 320 in Figure 3); when the first partition is a logical partition, the first partition can be a mapping area of ​​the physical storage area of ​​the memory of the control device 410a, or the first partition can be a mapping area of ​​the physical storage area of ​​the memory of the first control unit 420a. Similarly, the second partition can also be a physical partition or a logical partition. Generally speaking, the first partition and the second partition are two different partitions, that is, the physical storage areas occupied by the first partition and the second partition are different, or the physical storage areas mapped by the first partition and the second partition are different.

[0123] The first and second partitions of the control device 410a are each deployed with two different software versions. For example, the first partition is deployed with the second software version corresponding to the first control unit, and the second partition is deployed with the first software version corresponding to the first control unit. Generally speaking, the first and second software versions are different versions of the same software, such as the second software version being an upgraded version of the first software version, but this application is not limited to this.

[0124] The first control unit 420a includes a first storage area. The first storage area can be a physical storage area of ​​the memory of the first control unit 420a. Exemplarily, the first control unit 420a runs the software version deployed in the first storage area. If a second software version is deployed in the first storage area, the first control unit 420a runs the second software version.

[0125] The first partition and the second partition of the control device 410a can be mapped to the first storage area of ​​the first control unit 420a respectively. The mapping relationship between the first partition and the second partition and the first storage area can be stored by the control device 410a. This mapping relationship can be set on the control device 410a side during the initialization phase.

[0126] For example, the control device 410a may receive a third software version. For example, during an OTA upgrade, the control device 410a receives a third software version sent by a cloud service platform (such as 200 in FIG. 1 or FIG. 2 ). The third software version may be an upgraded version of the second software version, but this application is not limited thereto.

[0127] To ensure that the second software version is not affected by the first control unit, the control device 410a can update the first software version in the second partition to the third software version, and then send the third software version to the first control unit 420a. The first control unit 420a updates the second software version deployed in the first storage area to the third software version to implement the software upgrade.

[0128] When the control device 410a updates the first software version in the second partition to the third software version, the update can be implemented by performing a write operation based on a write-back mode. In the write-back mode, the control device 410a first writes to the second partition and does not actually write to the first storage area of ​​the first control unit 420a, thereby avoiding re-writing the first storage area during the software rollback process.

[0129] Furthermore, when the upgrade activation takes effect, the control device 410a performs data synchronization between the second partition and the first storage area to ensure that the flashing of the first storage area is successful, that is, the third software version is written to the first storage area. In another expression, the data synchronization between the second partition and the first storage area can be that the control device 410a sends the third software version to the first control unit 420a, and the first control unit 420a performs the write operation.

[0130] For example, when the control device 410a sends the third software version to the first control unit 420a, the control device 410a also sends information about the first storage area, such as the address or identifier of the first storage area, to the first control unit 420a, so that the first control unit 420a can determine the write location of the third software version.

[0131] Optionally, when the upgrade activation takes effect, the control device 410a compares whether the software versions in the second partition and the first storage area are consistent after the system is started. If they are inconsistent, the third software version in the second partition is synchronized to the first storage area.

[0132] In the embodiment shown in Figure 4a, the control device updates the first software version deployed in the second partition to the third software version, and synchronizes the third software version to the first storage area of ​​the first control unit. During the process of the first control unit updating the second software version deployed in the first storage area to the third software version, the second software version is still maintained in the first partition of the control device to ensure that the first control unit can quickly roll back to the second software version after the upgrade fails or the upgrade is abandoned, thereby improving the reliability of the software upgrade.

[0133] In some embodiments, the control device 410a can detect whether a trigger event exists, which triggers the rollback of the third software version deployed in the first storage area to the second software version. When the trigger event occurs, the control device 410a can send the second software version to the first control unit 420a. The first control unit 420a can receive the second software version and, based on the received second software version, roll back the third software version deployed in the first storage area to the second software version. This enables the first control unit 420a to quickly roll back the software version.

[0134] Optionally, when the control device 410a sends the second software version to the first control unit 420a, it may also send the information of the first storage area to the first control unit 420a.

[0135] For example, the control device 410a may perform data synchronization between the first partition and the first storage area to write the second software version in the first partition into the first storage area, thereby achieving transmission of the second software version.

[0136] Exemplarily, the triggering event may include at least one of the following:

[0137] 1. The third software version has an anomaly. For example, the anomaly is caused by a vulnerability in the third software version, or an anomaly caused by incompatibility with the first control unit 420a, or an anomaly caused by the third software version not belonging to the version set (detailed below).

[0138] 2. Canceling the upgrade: For example, the control device 410a cancels the upgrade in response to a user's upgrade cancellation operation; the upgrade is canceled when the control device 410a is powered off or restarted.

[0139] 3. Third-party software version update failure. This refers to an update failure caused by an exception during the update (or upgrade) process. This includes update failures during the initial upgrade of the third-party software version, or during a breakpoint recovery process for the third-party software version. Breakpoint recovery refers to resuming the upgrade after pausing the third-party software version.

[0140] In some embodiments, N of the M control units connected to the control device 410a are coupled to each other. The software versions running on these N coupled control units should be compatible with each other. Generally, control units with a business interaction relationship are coupled to each other, such as a cockpit control unit and an air conditioning control unit.

[0141] As shown in Figure 5 , ECU 6 is a control device, with ECUs 1 to 5 connected to the CAN channel and ECU 7 connected to the ETH channel. For example, ECUs 1 to 4 are coupled to each other, and ECU 5 and ECU 6 are coupled to each other. In this case, the software versions of each ECU in ECUs 1 to 4 should be compatible. For example, if ECUs 1 to 3 are upgraded to a new version during an upgrade, and ECU 4 has an upgraded software version or the software upgrade fails, resulting in a mismatch between the software versions of ECU 4 and ECUs 1 to 3, this can cause abnormal or unstable vehicle system operation. The software versions of ECUs 5 and 6 should be compatible. Similarly, if the software versions of ECUs 5 and 6 do not match due to the upgrade, this can cause abnormal or unstable vehicle system operation. As shown in Figure 6 , coupled ECUs can be grouped and managed, such as group 0 including ECUs 1 to 4 and group 1 including ECUs 5 and 6.

[0142] When the abnormality of the third software version is used as a trigger event for rolling back the third software version deployed in the first storage area to the second software version, the control device 410a can detect the trigger event based on the following two example events:

[0143] In Example 1, control device 410a detects whether the third software version belongs to a version set, which includes N matching software versions, where the N matching software versions are software versions corresponding to N control units. For example, if first control device 420a is ECU 1 shown in Figure 5, the third software version should be a matching software version with the software versions deployed by ECU 2 to ECU 4, that is, the version set includes the matching software versions corresponding to ECU 1 to ECU 4. If control device 410a detects that the third software version does not belong to the version set, it indicates that the upgrade process is likely to cause vehicle system abnormalities or instability. Control device 410a can control each ECU to perform a software version rollback to ensure that the versions running between ECU 1 to ECU 4 are compatible.

[0144] Optionally, the step of the control device 410a detecting whether the third software version belongs to the version set may be performed before or after sending the third software version to the first control unit 420a, for example, after the upgrade activation of the first control unit 420a takes effect. This application is not limited to this.

[0145] It should be understood that when the M control units include multiple groups of control units in a coupled relationship, the above software version detection and rollback process is performed on each group of control units in a coupled relationship.

[0146] In a second example, when N control units are each running corresponding software, the control device 410a detects whether any of the N control units are operating abnormally. If any of the N control units are operating abnormally, this indicates that a non-compatible software version is deployed in the N control units, or that an upgrade failed in the N control units. This upgrade process is likely to cause vehicle system abnormalities or instability. The control device 410a can control each control unit to perform a software version rollback to ensure that the versions running in the N control units are compatible.

[0147] In the above-mentioned Example 1 or Example 2, on the one hand, the control device 410a determines that there are N control units with a coupling relationship in the group, and there are control units that have not been successfully upgraded, or there are control units whose upgraded software versions are not matching software versions. Then, the N control units in the control group all roll back to the corresponding previous software version, thereby ensuring the reliability of the software upgrade; on the other hand, if the upgrade of other groups fails, it will not affect the upgrade results of the control units in this group, thereby avoiding the rollback of the software versions of all control units when the upgrade of some control units fails, thereby improving the efficiency of the software upgrade.

[0148] For example, the control device 410a may obtain association information between M control units and, based on the association information, determine the N control units from the M control units. The association information may include a service interaction relationship between the control units. The control device 410a may obtain asset information of the M control units and, based on the asset information of the M control units, determine the association relationship between the M control units, thereby determining the N control units that have a coupling relationship.

[0149] Figure 7a is another partition mapping schematic diagram provided in an embodiment of the present application. In conjunction with Figure 7a, the embodiment of the present application is described by taking the control device 510a and the first control unit 520a as an example. The control device 510a shown in Figure 7a is similar to the control device 410a in the embodiment shown in Figure 4a, and both include a first partition and a second partition. The difference is that the first control unit 520a in Figure 7a includes a first storage area and a second storage area. The second storage area can be a physical storage area of ​​the memory of the first control unit 520a, and the second storage area stores the first software version. Generally speaking, the first storage area and the second storage area are different storage areas in the memory. The first partition of the control device 510a can be mapped to the first storage area, and the second partition can be mapped to the second storage area.

[0150] The first storage area and the second storage area can be the primary storage area and the backup storage area of ​​the first control unit 520a, respectively. For example, when the first control unit 520a is running the software version deployed in the primary storage area, the software version in the backup storage area can be upgraded without affecting the software operation of the first control unit 520a. For example, when the first control unit 520a is running the second software version, the first storage area is the primary storage area and the second storage area is the backup storage area.

[0151] Exemplarily, after receiving the third software version, the control device 510a may update the first software version in the second partition to the third software version, and then send the third software version to the first control unit 520a. The first control unit 520a updates the first software version deployed in the second storage area to the third software version and switches the roles of the first storage area and the second storage area, which roles include primary storage area and stored area. In other words, after the first control unit 520a updates the first software version in the second storage area to the third software version, it uses the second storage area as the primary storage area and the first storage area as the backup storage area.

[0152] When the control device 510a updates the first software version in the second partition to the third software version, the writing operation may be performed based on a write-back mode or a write-through mode.

[0153] In write-back mode, the control device 510a first writes to the second partition without actually writing to the second storage area of ​​the first control unit 520a. During the upgrade activation process, the control device 510a can synchronize data between the second partition and the second storage area to send the third software version to the first control unit 520a. In write-back mode, both the first partition and the second partition can be physical or logical partitions.

[0154] In write-through mode, when the control device 510a flashes the second partition, it directly flashes the third software version to the second storage area, thereby simultaneously updating the software of the second partition and sending the third software version to the first control unit 520a. In write-through mode, the first partition and the second partition are generally logical partitions.

[0155] For example, when the control device 510a sends the third software version to the first control unit 520a, the control device 510a also sends information about the second storage area, such as the address or identifier of the second storage area, to the first control unit 520a, so that the first control unit 520a can determine the write location of the third software version.

[0156] Exemplarily, when the upgrade activation takes effect, the control device 510a switches the role of the second storage area to the primary storage area.

[0157] Optionally, when the upgrade activation takes effect, the control device 410a compares whether the software versions in the second partition and the second storage area are consistent after the system is started. If they are inconsistent, the third software version in the second partition is synchronized to the second storage area.

[0158] In some embodiments, the control device 510a can detect whether there is a trigger event. The trigger event has been described in the aforementioned embodiment and will not be repeated here. When there is a trigger event, the control device 510a can send an indication message to the first control unit 520a, and the indication message is used to instruct the third software version deployed in the first storage area to roll back to the second software version. The first control unit 520a can switch the roles of the first storage area and the second storage area. In other words, the first storage area is used as the main storage area and the second storage area is used as the backup storage area. Since the second software version is still stored in the first storage area, a rapid rollback of the software version can be achieved.

[0159] In some embodiments, the first control unit 520a may set the software version in the backup storage area after the role switch to an invalid state.

[0160] In some embodiments, the control device 510a may store a correspondence between the partitions of the control device and the storage areas of the first control unit.

[0161] As shown in FIG8 , after the upgrade begins, the first partition of the control device 510a stores software version v2 as a logical primary partition, and the second partition stores software version v1 as a logical backup partition. The control device 510a updates the software version v1 in the second partition to software version v3. The control device 510a detects whether a trigger event exists. If a trigger event exists, the software version rollback is performed. During the version rollback process, the software version in the second partition is set to an invalid state (NA), and the vehicle system is restarted to end the upgrade process. If no trigger event exists, the first control unit 520a switches the role of the second storage area corresponding to the second partition to the primary backup area and restarts the vehicle system. In this case, the first partition and the first storage area store software version v2, and the first partition serves as a logical backup partition and the first storage area serves as a backup storage area. The second partition and the second storage area store software version v3, and the second partition serves as a logical primary partition and the second storage area serves as a primary storage area, ending the upgrade process.

[0162] In order to further improve the reliability of the software system, the embodiment of the present application can set a mirror area corresponding to the storage area in the first control unit, so as to switch to executing the software version in the mirror area when a data abnormality occurs in the storage area.

[0163] Figure 4b is a schematic diagram of partition binding provided in an embodiment of the present application. As shown in Figure 4b , the difference from Figure 4a is that the first control unit 420b includes a first storage area and a first mirror area. The first storage area corresponds to the first mirror area, and the software version deployed in the first mirror area is the same as the software version deployed in the first storage area.

[0164] The control device 410b may bind the first storage area and the first mirror area during initialization, that is, establish a corresponding relationship between the first storage area and the first mirror area.

[0165] Exemplarily, after the upgrade verification passes, control device 410b triggers data synchronization between the first storage area and the first mirror area. The upgrade verification can be performed by running the software version of each control unit after the upgrade activation takes effect. This upgrade verification process can be implemented in the same process as the aforementioned embodiment, in which the corresponding software is run in each of the N control units to detect whether any of the N control units are operating abnormally.

[0166] Exemplarily, when there is a data anomaly in the first storage area, the control device 410b can send a switching instruction to the first control unit 420b, where the switching instruction is used to instruct the first mirror partition to be switched to the main storage area. The first control unit 420b switches the first mirror partition to the main storage area according to the switching instruction to run the software version stored in the first mirror partition.

[0167] Figure 7b is a schematic diagram of another partition binding method provided by an embodiment of the present application. As shown in Figure 7b , this embodiment differs from Figure 7a in that the first control unit 520b includes a first storage area, a second storage area, and a first mirror area. The first mirror area corresponds to the primary storage area, and the software version deployed in the first mirror area is the same as the software version deployed in the primary storage area.

[0168] The control device 510b may bind the main storage area (eg, the first storage area) to the first mirror area during initialization, that is, establish a corresponding relationship between the main storage area and the first mirror area.

[0169] Exemplarily, after the first control unit switches the roles of the first storage area and the second storage area, the control device 510b establishes a corresponding relationship between the first mirror partition and the primary storage area after the switch (such as the second storage area). In some embodiments, the control device 510b may establish a corresponding relationship between the first mirror partition and the primary storage area after the switch (such as the second storage area) after the upgrade verification passes. Optionally, the control device 510b establishes a mapping relationship between the first mirror partition and the second partition. Ensure that in the event of a data failure in the primary storage area, the software version in the first control unit 520b does not roll back to the old version.

[0170] Figure 7c is a schematic diagram of another partition binding provided by an embodiment of the present application. In conjunction with Figure 7c, this embodiment differs from Figure 7b above in that the first control unit 520c also includes a second mirror area. The second mirror area corresponds to the backup storage area (e.g., the second storage area), and the software version deployed in the second mirror area is the same as the software version deployed in the backup storage area.

[0171] The control device 510c can bind the main storage area (such as the first storage area) with the first mirror area during initialization, that is, establish a corresponding relationship between the main storage area and the first mirror area; and bind the backup storage area (such as the second storage area) with the second mirror area, that is, establish a corresponding relationship between the backup storage area and the second mirror area.

[0172] Exemplarily, after the first control unit of the control device 510c switches the roles of the first storage area and the second storage area, the corresponding relationship between the mirror partition and the storage area remains unchanged.

[0173] Optionally, the control device 510c establishes a mapping relationship between the first mirror partition and the first partition, and a mapping relationship between the second mirror partition and the second partition.

[0174] Compared with the embodiment shown in FIG7b , the embodiment shown in FIG7c does not need to modify the binding relationship between the mirror area and the storage area, thereby improving processing efficiency; compared with the embodiment shown in FIG7c , the embodiment shown in FIG7b saves physical storage space.

[0175] Optionally, based on any of the embodiments shown in Figures 7a to 7c above, the storage area with data anomalies in the first control unit performs self-healing, for example, the software version stored in the corresponding mirror area is rewritten to the storage area with data anomalies.

[0176] It should be noted that, in any of the above embodiments, the control device includes a first partition and a second partition corresponding to each control unit.

[0177] Based on any of the embodiments shown in Figures 4b, 7b, and 7c, the control device performs fault detection on the storage area of ​​the first control unit, as shown in the flowchart shown in Figure 9. After the vehicle system is started, the primary storage area is detected for faults. If an abnormality is detected in the primary storage area and the mirrored area corresponding to the primary storage area is normal, the control device switches the mirrored area to the primary storage area and runs the software version in the mirrored area. Furthermore, the abnormal storage area sets a fault flag and attempts self-healing.

[0178] In some embodiments, the control device can determine the scheduling information of the M control units based on the association information, where the scheduling information indicates the order in which the M control units perform software version upgrades. The control device sends the third software version to the first control unit based on the scheduling information.

[0179] Optionally, the arrangement information further instructs the M control units to perform software version upgrades in a serial and / or parallel manner.

[0180] For example, some of the M control units may have dependencies during the upgrade process. Still referring to FIG6 , ECU 4 depends on ECU 3, and ECU 5 depends on ECU 6. This dependency can be determined based on the control unit's gateway topology. Specifically, the association information includes the gateway topology of the M control units.

[0181] For control units with dependencies, the software version can be upgraded in a serial manner, and the upgrade order of each control unit with dependencies can be determined; for control units without dependencies, the software version can be upgraded in a parallel manner.

[0182] As shown in FIG10 , the software version upgrade process may include a software version installation phase (e.g., STAGE 0) and an upgrade activation phase (e.g., STAGE 1). The software version installation phase and the upgrade activation phase may be executed serially. For example, after the control device installs the software version on ECUs 1 to 7 in STAGE 1, it activates ECUs 1 to 7 in STAGE 1. During the software version installation phase, the control device may install the software version on ECUs 1 to 7 in parallel. During the upgrade activation phase, the control device may serially activate ECUs 1 to 4, which have a dependent relationship, and concurrently activate ECUs 5 to 7, which do not have a dependent relationship, with ECU 4.

[0183] For example, in parallel mode, the installation management module may notify the installation execution module to create a thread to execute the installation of ECU 1; and at the same time, notify the installation execution module to create another concurrent thread to execute the installation of ECU 2, and so on.

[0184] For example, in serial mode, the installation management module may notify the installation execution module to create a thread to activate ECU4, ECU3, ECU2, and ECU1 in sequence, and wait if the installation of the corresponding ECU is not completed.

[0185] Generally speaking, the entire vehicle contains a large number of control units, and the upgrade and flashing of each control unit takes time. The more control units that are upgraded, the longer the total time consumed, often reaching the hour level. During the upgrade process, some equipment and functions of the vehicle cannot be used. For example, during the upgrade process, the vehicle cannot be driven, the doors cannot be opened or closed, etc., which brings great inconvenience to the user. Therefore, the embodiment of the present application considers implementing breakpoint resume during the upgrade process to improve the convenience of the user's use of the vehicle. For ease of understanding, the following is an example of the control device implementing breakpoint resume of the software version for the first control unit.

[0186] When it is necessary to suspend the upgrade task, the control device can send a pause instruction to the first control unit, and the pause instruction is used to instruct to suspend the software upgrade task, and the software upgrade task is a task of upgrading the second software version to the third software version; the first control unit can suspend the software upgrade task according to the pause instruction and save the breakpoint information. Further, the first control unit can send the breakpoint information to the control device.

[0187] The breakpoint information includes at least one of the following: task parameters, task progress, or scheduling information. Task parameters may include a software upgrade task ID, upgrade status information, and the like.

[0188] Exemplarily, the control device detects whether there is a suspended software upgrade task, and when there is a suspended software upgrade task, obtains the breakpoint information of the software upgrade task, and then sends a continue upgrade instruction to the first control unit based on the breakpoint information. The continue upgrade instruction is used to instruct to continue executing the software upgrade task; the first control unit continues to execute the software upgrade task based on the breakpoint information and the continue upgrade instruction.

[0189] 11a and 11b , the breakpoint upgrade recovery is exemplarily described below by taking the interaction between the modules in the control device into consideration.

[0190] The breakpoint upgrade recovery process provided in FIG11 a includes steps S1 to S13 , which are described in detail below.

[0191] S1: The installation management module initializes the software upgrade system and determines whether there are any previous upgrade tasks. If so, the upgrade can proceed with the previous upgrade task, as illustrated in Figure 11b. If no previous upgrade task exists, the current software upgrade task can proceed, such as upgrading the second software version to the third software version.

[0192] S2, the installation management module interacts with the asset management module to obtain the association information of the M control units. For example, the installation management module sends a request to the asset management module to obtain the association information, and the asset management module sends the association information to the installation management module in response to the request to obtain the association information. It should be noted that the association information of the M control units can be determined after the asset management module collects the asset information of the M control units. In another implementation method, the asset management module can directly send the asset information of the M control units to the installation management module. The installation management module determines the association information based on the asset information of the M control units.

[0193] S3: The installation management module interacts with the upgrade mode management module to enter the upgrade mode. For example, the installation management module sends a software upgrade task request to the upgrade mode management module. In response to the request, the upgrade mode management module determines that the vehicle system enters the upgrade mode and sends a response to the installation management module indicating that the vehicle system has entered the upgrade mode.

[0194] S4. The installation management module determines arrangement information of the M control units according to the association information of the M control units.

[0195] S5: The installation management module sends the arrangement information to the installation execution module.

[0196] S6, the installation execution module installs the software version corresponding to each control unit in the corresponding backup area according to the arrangement information. The backup area may be a backup partition of the control device and / or a backup storage area of ​​the control unit.

[0197] S7: The installation management module may send a query request to the installation execution module to inquire about the software upgrade progress and / or software upgrade status of each control unit. Exemplarily, the software upgrade status may include upgrade success, upgrade failure, etc. In response to the query request, the installation execution module sends the software upgrade progress and / or software upgrade status to the installation management module.

[0198] S8: The installation management module receives a user's operation to pause the upgrade. The installation management module may generate a pause instruction in response to the user's operation to pause the upgrade. In another implementation, the installation management module may generate the pause instruction in response to a pause triggering event. For example, the pause triggering event may be the vehicle starting to move during the software upgrade process.

[0199] S9, the installation management module sends a pause instruction to the installation execution module.

[0200] S10 , the installation execution module obtains breakpoint information corresponding to the M control units respectively in response to the pause instruction, and sends the breakpoint information to the installation management module.

[0201] S11, the installation management module saves the breakpoint information corresponding to the M control units respectively.

[0202] S12: The installation management module sends a request to exit the upgrade mode to the upgrade mode management module.

[0203] S13, the upgrade mode management module suspends the current software upgrade task in response to the request to exit the upgrade mode.

[0204] The breakpoint upgrade recovery process shown in FIG11b includes steps S01 to S012, wherein S02, S03 and S010 are similar to S2, S3 and S7 in the embodiment shown in FIG11a, and are not described again for the sake of brevity.

[0205] S01, the installation management module initializes the vehicle system and detects that there is a suspended software upgrade task.

[0206] S04, the installation management module resumes the suspended upgrade site according to the breakpoint information of the software upgrade task, such as determining at least one of the software upgrade task ID, the arrangement information of the M control units, the upgrade status information corresponding to the M control units, the upgrade parameters, and the upgrade progress.

[0207] In scenario 1, the control device will continue to execute the software upgrade task according to the restored upgrade site; in scenario 2, the control device may cancel the software upgrade task in response to the user's operation of canceling the upgrade.

[0208] In one implementation, the control device defaults to continuing the paused software upgrade task, and is able to cancel the software upgrade task in response to the user's operation of canceling the upgrade; in another implementation, the control device can push an interactive interface to the user to confirm continuing the software upgrade task, and in response to the user's operation of confirming to continue upgrading the software upgrade task, continue upgrading the software upgrade task, and cancel upgrading the software upgrade task in response to the user's operation of canceling continuing to upgrade the software upgrade task.

[0209] In the above scenario 1, the control device continues to execute S08 to S012 in Figure 11b. In the above scenario 2, the control device executes S06 and S07.

[0210] S06, the installation management module generates a software version rollback request based on the arrangement information of the M control units, and sends the rollback request to the installation execution module. At the same time, the installation management module cleans up unfinished software upgrade tasks, such as deleting the downloaded software version, deleting the breakpoint information of the software upgrade task, etc.

[0211] S07 , the installation execution module responds to the software version rollback request and performs software version rollback on the M control units respectively.

[0212] S08: The installation management module generates a software version recovery and upgrade request based on the arrangement information of the M control units, and sends the recovery and upgrade request to the installation execution module.

[0213] S09 , the installation execution module continues to upgrade the software versions of the M control units in response to the recovery upgrade request.

[0214] S011, the installation management module cleans up the software upgrade task after the upgrade is completed, such as deleting the breakpoint information of the software upgrade task.

[0215] S012: The installation management module interacts with the upgrade mode management module to exit the upgrade mode after the upgrade is completed. For example, after the upgrade is completed, the installation management module sends a request to exit the upgrade mode to the upgrade mode management module, and the upgrade mode management module exits the upgrade mode in response to the request.

[0216] The division of the units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.

[0217] Figure 12 is a schematic diagram of a software upgrade state machine of a control unit provided by an embodiment of the present application. In conjunction with Figure 12, when the control unit is installing a software version, if the control device sends a pause instruction, such as calling a pause module: call pause(), the control unit changes from the installation state to the installation completion state; when the control unit receives a pause instruction in the installation completion state, the state of the control unit in the state machine remains unchanged; when the control unit is activating the software version, if it receives a pause instruction sent by the control device, the control unit changes from the activation state to the version rollback completion state; when the control unit receives a pause instruction in the version rollback state, the control unit changes from the version rollback state to the version rollback completion state. In summary, when the control unit needs to suspend the upgrade of the software version, if it is in an unstable state (such as installation, activation, version rollback), it is adjusted to a relatively stable state (such as installation completion, activation completion, version rollback completion) to facilitate saving the upgrade scene, that is, obtaining stable breakpoint information.

[0218] FIG13 is a flow chart of a software upgrade control method provided in an embodiment of the present application. The execution subject of the method may be the control device in any of the aforementioned embodiments. As shown in FIG13 , the method includes:

[0219] S610, the control device receives a third software version;

[0220] S620, the control device updates the first software version in the second partition to a third software version;

[0221] S630: The control device sends the third software version to the first control unit.

[0222] The specific implementation method of the software upgrade control method in the embodiment of the present application has been described in detail in the above-mentioned device embodiment, and will not be repeated here for the sake of brevity.

[0223] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program.

[0224] In some embodiments, the computer-readable storage medium can be applied to the control device of the vehicle in the embodiments of the present application, and the computer program enables the computer to execute the corresponding processes in the various methods in the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0225] An embodiment of the present application also provides a computer program product, including computer program instructions.

[0226] In some embodiments, the computer program product can be applied to the control device in the embodiments of the present application, and the computer program instructions enable the computer to execute the corresponding processes in the various methods in the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0227] The embodiment of the present application also provides a computer program.

[0228] In some embodiments, the computer program can be applied to the control device in the embodiments of the present application. When the computer program runs on a computer, the computer executes the corresponding processes in the various methods in the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0229] An embodiment of the present application also provides a smart vehicle.

[0230] In some embodiments, the vehicle includes a control device according to the embodiments of the present application, and the control device is used to execute corresponding processes in various methods according to the embodiments of the present application.

[0231] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0232] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A software upgrade system, characterized in that, It includes a control device and M control units, where M is a positive integer. The M control units include a first control unit. The control device includes a first partition and a second partition. The first control unit includes a first storage area. The first partition deploys a second software version, and the second partition deploys a first software version; The control device is configured to: Receive a third software version; Update the first software version in the second partition to the third software version; Send the third software version to the first control unit; The first control unit is configured to: Update the second software version deployed in the first storage area to the third software version; The first software version, the second software version, and the third software version are different versions of the software corresponding to the first control unit.

2. The software upgrade system according to claim 1, characterized in that, When sending the third software version to the first control unit, the control device is specifically configured to send the third software version and the information of the first storage area to the first control unit.

3. The software upgrade system according to claim 2, characterized in that The first control unit further includes a second storage area, and the first control unit is further configured to: Update the first software version deployed in the second storage area to the third software version; Switch the roles of the first storage area and the second storage area, where the roles include a main storage area or a backup storage area.

4. The software upgrade system according to claim 1 or 2, characterized in that, After sending the third software version to the first control unit, The control device is further configured to: Detect whether there is a trigger event, where the trigger event is used to trigger rolling back the third software version deployed in the first storage area to the second software version; When there is the trigger event, send the second software version to the first control unit; The first control unit is further configured to: Receive the second software version; Roll back the third software version deployed in the first storage area to the second software version.

5. The software upgrade system according to claim 3, wherein After sending the third software version to the first control unit, The control device is further configured to: Detect whether there is a trigger event, where the trigger event is used to trigger rolling back the third software version deployed in the first storage area to the second software version; When there is the trigger event, send indication information to the first control unit, where the indication information is used to indicate rolling back the third software version deployed in the first storage area to the second software version; The first control unit is further configured to switch the roles of the first storage area and the second storage area.

6. The software upgrade system according to claim 4 or 5, characterized in that, The trigger event includes one of the following: The third software version is abnormal; Upgrade cancellation; or The update of the third software version fails.

7. The software upgrade system according to claim 6, wherein The trigger event includes that the third software version is abnormal. When the control device detects whether there is the trigger event, the control device is specifically configured to: Detect whether the third software version belongs to a version set, where the version set includes N supporting software versions, and the N supporting software versions are the software versions corresponding to N control units respectively; or, When the N control units are running their corresponding software respectively, detect whether there is a control unit with abnormal operation among the N control units; Among them, the N control units include the first control unit, the N control units are coupled to each other, N is less than or equal to M, and N is an integer greater than 1.

8. The software upgrade system according to claim 7, wherein The control device is further configured to: Obtain the association information between the M control units; Determine the N control units from the M control units according to the association information.

9. The software upgrade system according to claim 8, wherein Specifically, the control device is configured to: Determine the arrangement information of the M control units according to the association information, where the arrangement information indicates the order of software version upgrade of the M control units; Send the third software version to the first control unit according to the arrangement information.

10. The software upgrade system according to claim 9, characterized in that, The arrangement information further indicates that the M control units perform software version upgrade in a serial and / or parallel manner.

11. The software upgrade system according to any one of claims 1 to 10, characterized in that, The control device is further configured to store a mapping relationship, where the mapping relationship indicates the correspondence between the partition of the control device and the storage area of the first control unit.

12. The software upgrade system according to any one of claims 1 to 11, characterized in that, The first partition is a logical partition or a physical partition; and / or, the second partition is a logical partition or a physical partition; where The physical partition is a physical storage area of the memory of the control device, and the logical partition is a mapped area of the physical storage area of the memory.

13. The software upgrade system according to any one of claims 1 to 12, characterized in that, The first storage area corresponds to the first mirror area, and the software version deployed in the first mirror area is the same as the software version deployed in the first storage area.

14. The software upgrade system according to claim 13, wherein The control device is further configured to: After the first control unit switches the roles of the first storage area and the second storage area, establish the correspondence between the first mirror partition and the switched main storage area.

15. The software upgrade system according to claim 3 or 5, characterized in that The second storage area corresponds to the second mirror area, and the software version deployed in the second mirror area is the same as the software version deployed in the second storage area.

16. The software upgrade system according to claim 14, wherein The control device is further configured to: When there is data abnormality in the first storage area, send a switching instruction to the first control unit, where the switching instruction is used to indicate switching the first mirror partition to the main storage area; The first control unit is configured to switch the first mirror partition to the main storage area according to the switching instruction.

17. The software upgrade system according to any one of claims 1 to 16, characterized in that, The control device is further configured to: Send a pause instruction to the first control unit, where the pause instruction is used to indicate pausing the software upgrade task, and the software upgrade task is to upgrade the second software version to the third software version; The first control unit is further configured to: Pause the software upgrade task according to the pause instruction and save the breakpoint information; Send the breakpoint information to the control device; Among them, the breakpoint information includes at least one of the following: task parameters, task progress, or arrangement information.

18. The software upgrade system according to any one of claims 1 to 17, characterized in that, The control device is further configured to: Detect whether there is a paused software upgrade task, where the software upgrade task is to upgrade the second software version to the third software version; When there is a paused software upgrade task, obtain the breakpoint information of the software upgrade task; Send a continue upgrade instruction to the first control unit according to the breakpoint information, where the continue upgrade instruction is used to indicate continuing to execute the software upgrade task; The first control unit is further configured to continue to execute the software upgrade task according to the breakpoint information and the continue upgrade instruction.

19. A software upgrade control method, characterized in that Applied to a control device, the control device includes a first partition and a second partition. The second software version is deployed in the first partition, and the first software version is deployed in the second partition. The method includes: Receiving a third software version; Updating the first software version in the second partition to the third software version; Sending the third software version to a first control unit; The first software version, the second software version, and the third software version are different versions of the software corresponding to the first control unit.

20. The method according to claim 19, wherein The sending the third software version to the first control unit includes: sending the third software version and information of a first storage area to the first control unit, and the first control unit includes the first storage area.

21. The method according to claim 19 or 20, characterized in that, After the sending the third software version to the first control unit, the method further includes: Detecting whether there is a trigger event for triggering the rollback of the third software version to the second software version; When there is the trigger event, sending the second software version to the first control unit, or sending indication information to the first control unit, where the indication information indicates rolling back the third software version to the second software version.

22. The method according to claim 21, wherein The trigger event includes one of the following: The third software version is abnormal; Canceling the upgrade; or The update of the third software version fails.

23. The method according to claim 22, wherein The trigger event includes that the third software version is abnormal. The detecting whether there is the trigger event includes: Detecting whether the third software version belongs to a version set, the version set includes N supporting software versions, and the N supporting software versions are software versions corresponding to N control units respectively; or, When the N control units are respectively running corresponding software, detecting that there is a control unit with abnormal operation among the N control units; Wherein, the N control units include the first control unit, the N control units are coupled to each other, N is less than or equal to M, and both N and M are integers greater than 1.

24. The method according to claim 23, wherein It further includes: Obtaining association information between M control units; Determining the N control units from the M control units according to the association information.

25. The method according to claim 24, wherein The sending the third software version to the first control unit includes: Determining the scheduling information of the M control units according to the association information, where the scheduling information indicates the order of software version upgrade of the M control units; Sending the third software version to the first control unit according to the scheduling information.

26. The method according to claim 25, wherein The scheduling information further indicates that the M control units perform software version upgrade in a serial and / or parallel manner.

27. The method according to any one of claims 19 to 26, characterized in that, The method further includes: Storing a mapping relationship, where the mapping relationship indicates the corresponding relationship between the partition of the control device and the storage area of the first control unit.

28. The method according to any one of claims 19 to 27, characterized in that The first partition is a logical partition or a physical partition; and / or, the second partition is a logical partition or a physical partition; wherein, The physical partition is a physical storage area of the memory of the control device, and the logical partition is a mapped area of the physical storage area of the memory.

29. The method according to any one of claims 19 to 28, characterized in that, The first storage area of the first control unit corresponds to the first mirror area, and the software version deployed in the first mirror area is the same as the software version deployed in the first storage area.

30. The method according to claim 29, wherein After sending the third software version to the first control unit, the method further includes: Establishing a correspondence between the first mirror partition and the switched main storage area.

31. The method according to claim 29 or 30, characterized in that, The method further includes: When there is a data anomaly in the first storage area, sending a switching instruction to the first control unit, where the switching instruction is used to instruct to switch the first mirror partition to the main storage area.

32. The method according to any one of claims 19 to 31, characterized in that The method further includes: Sending a pause instruction to the first control unit, where the pause instruction is used to instruct to pause the software upgrade task, The software upgrade task is to upgrade the second software version to the third software version.

33. The method according to claim 32, wherein The method further includes: Obtaining breakpoint information of the first control unit; where the breakpoint information includes at least one of the following: task parameters, task progress, or orchestration information.

34. The method according to any one of claims 19 to 33, characterized in that, The method further includes: Detecting whether there is a paused software upgrade task, where the software upgrade task is to upgrade the second software version to the third software version; When there is a paused software upgrade task, obtaining the breakpoint information of the software upgrade task; According to the breakpoint information, sending a continue upgrade instruction to the first control unit, where the continue upgrade instruction is used to instruct to continue executing the software upgrade task.

35. A control device, characterized in that, Includes: A module for executing the method according to any one of claims 19 to 34.

36. A vehicle, characterized in that, Includes: A control device, the control device includes a first partition and a second partition, the second software version is deployed in the first partition, the first software version is deployed in the second partition, the control device is used to execute the method according to any one of claims 19 to 34 to control the software upgrade of the first control unit, and the first software version and the second software version are different versions of the software corresponding to the first control unit.

37. The vehicle according to claim 36, characterized in that, It further includes M control units, M is a positive integer, and the M control units include the first control unit.

38. A chip, characterized in that, Includes: A processor for calling and running computer instructions from a memory, so that the device installed with the chip executes the method according to any one of claims 19 to 34.

39. A computer-readable storage medium, characterized in that, For storing computer program instructions, the computer program causes the computer to execute the method according to any one of claims 19 to 34.

40. A computer program product, characterized in that, Includes computer program instructions, and the computer program instructions cause the computer to execute the method according to any one of claims 19 to 34.

Images