Software update method, electronic control unit, storage medium and program product

Abstract

The present disclosure relates to a software updating method, an electronic control unit, a computer readable storage medium and a computer program product. The software updating method is performed by a first controller in the electronic control unit, the electronic control unit comprising the first controller and a second controller, the method comprising: obtaining a second software updating file for updating a second software in the second controller; storing the second software updating file to a storage space of the first controller; updating the second software in the second controller based on the second software updating file stored in the storage space of the first controller via a communication link between the first controller and the second controller, and backing up a running file of the second software in the second controller to the storage space of the first controller as a second backup file for rolling back the second software in the second controller to a version before updating.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a software update method, an electronic control unit, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the continuous improvement of intelligence and connectivity, over-the-air (OTA) technology is being increasingly widely used in vehicle software updates. Compared with traditional vehicle software update methods, OTA-based software updates can achieve online updates through communication between the vehicle and external nodes such as cloud servers, without having to send the vehicle to a predetermined location for offline updates, thus helping to improve the efficiency and flexibility of vehicle software updates.

[0003] For reliability reasons, when using OTA (Over-The-Air) updates to update software within structures such as ECUs (electronic control units) in vehicles, software version rollback can be supported by backing up the software files from before the update. However, since backups require additional storage space, software version rollback functionality typically places higher demands on the local storage space of the ECU or other structures where the corresponding software is deployed. Summary of the Invention

[0004] In view of the above, this disclosure provides a software update method, an electronic control unit, a computer-readable storage medium, and a computer program product, as detailed below.

[0005] According to one aspect of this disclosure, a software update method is provided, wherein the method is executed by a first controller in an electronic control unit, the electronic control unit including a first controller and a second controller, the method comprising: acquiring a second software update file for updating second software in the second controller; storing the second software update file in the storage space of the first controller; updating the second software in the second controller based on the second software update file stored in the storage space of the first controller via a communication link between the first controller and the second controller, and backing up the runtime files of the second software in the second controller to the storage space of the first controller as a second backup file for rolling back the second software in the second controller to the version before the update.

[0006] In some embodiments, the method further includes: in response to the need for the second software in the second controller to be rolled back to a previous version, updating the second software in the second controller via a communication link based on a second backup file stored in the storage space of the first controller.

[0007] In some embodiments, the method further includes: obtaining a first software update file for updating the first software in the first controller; storing the first software update file in the storage space of the first controller; updating the first software in the first controller based on the first software update file, and backing up the runtime file of the first software in the first controller to the storage space of the first controller as a first backup file for rolling back the first software to the version before the update.

[0008] In some embodiments, obtaining a second software update file for updating the second software in the second controller includes: receiving a second software update file from the master control device in response to receiving a second software update request from the master control device, wherein the second software update request is used to request an update of the second software in the second controller.

[0009] In some embodiments, updating the second software in the second controller based on a second software update file stored in the storage space of the first controller via a communication link between the second controller and the first controller includes: instructing the second controller to enter a software update state via the communication link; and sending the second software update file stored in the storage space of the first controller to the second controller via the communication link.

[0010] In some embodiments, the communication link is a serial interface-based communication link.

[0011] In some embodiments, the storage space of the first controller is greater than the storage space of the second controller.

[0012] According to another aspect of this disclosure, an electronic control unit is provided, including a first controller and a second controller, wherein the first controller is configured to perform a software update method described in any of the embodiments of the foregoing aspects.

[0013] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed, perform the method described in any of the embodiments of the foregoing aspects.

[0014] According to another aspect of this disclosure, a computer program product is provided, including computer-executable instructions that, when executed, implement the steps of the method described in any of the embodiments of the foregoing aspects.

[0015] The software update scheme provided in this disclosure allows for the following software update process: When performing a software update in an electronic control unit (ECU) comprising two (or more) controllers, the software in a second controller (e.g., a controller in the ECU responsible for a single or limited number of functions) can be updated using the first controller (e.g., a controller in the ECU responsible for a single or limited number of functions). Backup files for the second controller are stored in the storage space of the first controller. This effectively reduces the storage requirements of the second controller and controls its size while ensuring rollback functionality, thereby lowering the overall hardware cost of the ECU.

[0016] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0017] Further details, features, and advantages of this disclosure are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0018] Figure 1 An exemplary OTA update scenario in which the software update scheme of this disclosure can be applied is illustrated;

[0019] Figures 2A to 2D An exemplary software update process for the controller in an electronic control unit is illustrated schematically;

[0020] Figure 3 An exemplary architecture of an electronic control unit comprising two controllers is illustrated schematically according to some embodiments of the present disclosure;

[0021] Figure 4 This illustration schematically shows an example architecture for updating software in a controller, based on relevant technologies;

[0022] Figure 5 An example flowchart illustrating a software update method according to some embodiments of the present disclosure is shown schematically;

[0023] Figure 6 An example architecture for updating software in a controller is illustrated schematically according to some embodiments of this disclosure. Detailed Implementation

[0024] Before detailing the embodiments of this disclosure, some related concepts will first be explained.

[0025] In this disclosure, "software" should be understood to encompass all types of computer programs, including application software, operating system software, and programs embedded in hardware (also known as "firmware"). Accordingly, "software update" can be understood as the process of changing the aforementioned application software, operating system software, or firmware from one version to another, and can encompass various software upgrades, vulnerability patching, and other processes related to software updates.

[0026] In this disclosure, "electronic control unit" may refer to an ECU in a vehicle, but may also encompass other types of control or computing devices. In some embodiments of this disclosure, the electronic control unit may include two or more controllers (such as microcontrollers), wherein each controller may be configured by software deployed thereon to perform one or more specific control functions.

[0027] In this disclosure, "OTA" refers to a technology that enables remote updates of device firmware or software through wireless communication technology. It can be applied to remote updates of firmware or software in many fields such as automobiles, smartphones, IoT devices, and embedded systems, and can include FOTA (Firmware-over-the-air) and SOTA (Software-over-the-air).

[0028] For example, in the automotive industry, Figure 1 The illustration depicts an OTA update scenario 100. For example... Figure 1 As shown, scenario 100 may include a cloud platform 110. Optionally, the cloud platform 110 may include a server or a group of servers and be configured to implement various vehicle-related management functions and data or file storage functions, etc. For example, a supplier or other object with software management authority can prepare a software update file through a terminal device 120 and upload it to the cloud platform 110 via a network. The software update file can be used to update one or more software programs in one or more ECUs deployed in the vehicle. The cloud platform 110 can store the uploaded software update file. For example, the cloud platform 110 can notify a user (such as a driver or other relevant person) of an available update by sending a message to the vehicle 130 or a user device (not shown) related to the vehicle 130. After the user confirms the update, the central control unit (CCU) 131 of the vehicle 130 can download the software update file from the cloud platform 110 via a network and provide it to the OTA master module 132 responsible for OTA updates to implement software updates for one or more ECUs 133-135.

[0029] It should be understood that, although Figure 1 Only three ECUs (133-135) are shown in the diagram; however, depending on application requirements, a vehicle may have other numbers of ECUs. Also, although... Figure 1 Only three terminal devices 120 are shown in the figure. However, in a real-world scenario, there can be any number of terminal devices 120. Furthermore, the terminal devices 120 can be various types of computing devices, such as desktop computers, laptops, tablets, etc.

[0030] As further exemplarily, after the software update file is downloaded and provided to the OTA master control module 132 of vehicle 130, it can be based on Figures 2A to 2D The process shown updates the software within the microcontroller of the corresponding ECU. For example, the OTA master module 132 can notify the ECU or its microcontroller via the vehicle's internal communication network that an update is available. The ECU or its microcontroller can receive the software update file from the OTA master module 132 and update accordingly. Figures 2A to 2D The process shown is for updating the software. During the software update process in the ECU, the vehicle should be in a safe state, which, for example, ensures that the vehicle is completely stopped, the power supply is stable, non-essential systems unrelated to the update are turned off, and / or the driver is notified of the update status. Figure 2A As shown, the internal storage space of the microcontroller in the ECU can include two areas: an execution area 210 and a storage area 220. The execution area 210 can house a Hardware Security Module (HSM) 211, a Flash Boot Loader (FBL) 212, a Boot Manager 213, and version A software. Version A software includes Calibration Data (CALA) and Software Body (SWA). Figure 2B As shown, guided by FBL 213, the microcontroller can receive software update files from the OTA master control module 132 and, in a secure state, write version B software to storage area 220 based on the software update files. Similarly, version B software includes calibration data CAL B and the main software SW B. Subsequently, as... Figure 2CAs shown, guided by FBL 213, software versions A and B can be swapped to activate software version B and store software version A as a backup. Optionally, a caching structure can be used to achieve the swapping of software versions A and B. For example, the swapping can be achieved gradually through multiple swapping steps using a caching structure. In each swapping step, a portion of both can be swapped using the caching structure. For instance, a portion of software version A in the execution area can be stored in the caching structure, and the corresponding portion of software version B in the storage area can be written to the corresponding location in the execution area (the location originally used to store the cached portion of software version A). Then, the cached portion of software version A in the caching structure can be written to the corresponding location in the storage area (the location originally used to store the portion of software version B written to the execution area). Alternatively, the operation can be performed in reverse, that is, the caching structure can be used to cache a portion of software version B instead of software version A. For example, RAM (Random Access Memory) or other types of storage structures can be used as the caching structure described above. Suppose that software version B encounters an error or other problem and needs to be rolled back to a previous version, then as follows: Figure 2D As shown, under the guidance of FBL 213, the backed-up version A software can be rewritten back to execution area 210, so as to roll back the software version to version A.

[0031] It should be understood that the above is for reference only. Figure 1 and Figures 2A-2D The OTA update process described above is merely an example. Depending on the specific application scenario, different OTA update processes may exist. However, regardless of the OTA update process used, in order to achieve the rollback function, it is generally necessary to back up the software version before the update on the ECU side, which will inevitably occupy a certain amount of storage space.

[0032] In some cases, there may be two or more controllers in an ECU. For example, such as... Figure 3As shown, ECU 300 may include microcontrollers 310 and 320. Both microcontrollers 310 and 320 can receive sensing data from sensors 332 related to the target function, and microcontroller 310 also receives sensing data from sensors 331 related to other functions. Accordingly, microcontroller 310 can send a control signal to control circuit 341 based on the sensing data from sensors 332, so as to control actuator 351 to implement the target function. Similarly, microcontroller 320 can send a control signal to control circuit 342 based on the sensing data from sensors 332, so as to control actuator 352 to implement the target function. Optionally, to improve reliability, control circuit 341 can also control actuator 352, or control circuit 342 can also control actuator 351. Thus, microcontroller 320 can serve as redundancy for microcontroller 310 for the target function, thereby improving the reliability of the target function.

[0033] Taking a vehicle's braking system as an example, parking redundancy is typically designed for safety and reliability. In some ROPP41 (Remove of Parking Pawl) type braking systems, such as the IPB (Integrated Power Brake) system, parking redundancy can be implemented using an ECU containing two microcontrollers. One microcontroller supports all control functions within the braking system, while the other microcontroller is used solely for parking redundancy. Such an ECU could, for example, have... Figure 3In the illustrated architecture, microcontroller 310 can receive sensing data from various sensors related to the braking system, such as sensing data from sensors 332 related to the parking function (e.g., wheel speed, pedal travel) and sensing data from sensors 331 related to other functions, while microcontroller 320 only receives sensing data from sensors 332 related to the parking function. Accordingly, microcontroller 310 can send a control signal to parking control circuit 341 based on the sensing data from sensors 332 related to the parking function, so that parking control circuit 341 controls parking brake mechanism 351 to perform corresponding actions, such as controlling a motor to drive brake calipers mounted on the rear axle of the vehicle to achieve parking braking. Similarly, microcontroller 320 can send a control signal to parking control circuit 342 based on the sensing data from sensors 332 related to the parking function, so that parking control circuit 342 controls parking brake mechanism 352 to perform corresponding actions to achieve parking braking (e.g., when the parking brake function of microcontroller 310 fails). Optionally, to implement the control function, the parking control circuits 341 and 342 can also receive feedback signals such as the front and / or rear wheel speeds. Optionally, the parking brake mechanisms 351 and 352 can be an APB-Mi (Automatic Parking Brake-Mechanical Integration) system, and correspondingly, the parking control circuits 341 and 342 can be application-specific integrated circuits (ASICs) related to APB. Furthermore, the microcontroller 310 can also send control signals to one or more other control circuits 344 based on sensing data from sensors 331 related to other functions, in order to control one or more other actuators 354 to perform corresponding functions, such as hydraulic control.

[0034] In ECUs containing two or more controllers, each controller can have corresponding software (such as firmware) deployed to perform its specific function. As mentioned earlier, to support software version rollback, according to relevant technologies, the following methods can be employed: Figure 4 The architecture shown. (As illustrated) Figure 4 As shown, ECU 410 includes two controllers, 411 and 412. Controller 411's internal storage space includes an execution area and a storage area, storing the currently executing software version 4111 and a backup software version 4112, respectively. Controller 412's internal storage space includes an execution area and a storage area, storing the currently executing software version 4121 and a backup software version 4122, respectively. Controllers 411 and 412 can interact with the OTA master control module 420 via communication lines such as a bus, thereby enabling [further details to be added]. Figure 1 and Figures 2A-2D OTA updates are implemented as described.

[0035] However, as mentioned earlier, backups require additional storage space; therefore, supporting version rollback leads to a higher demand on the microcontroller's local storage capacity. In an ECU containing two or more controllers, typically one or more controllers may only perform a single or very limited function. Therefore, without considering rollback functionality, their required local storage capacity may be very low compared to controllers performing more functions within the same ECU. (See reference...) Figure 3 Taking the described architecture as an example, microcontroller 320 is only used to support parking redundancy, and its required local storage space will be much smaller than that of microcontroller 310, which needs to support more braking control functions. For controllers similar to microcontroller 320, to support rollback functionality, their local storage capacity will need to be significantly increased. For example, to support parking redundancy and integrate several related PBC (Parking Brake Control) software, it might only be necessary to use a microcontroller model with 2MB of storage space (e.g., 2MB of ROM) to implement the aforementioned microcontroller 320. However, to store additional backup files to support software version rollback, it might be necessary to use a microcontroller model with 4MB of storage space to implement the aforementioned microcontroller 320. This would not only increase the cost of microcontroller 320 but also increase its size, thereby increasing the cost and size of the overall ECU.

[0036] To avoid the aforementioned problems, this disclosure proposes a new software update scheme. This scheme can be used in electronic control units similar to ECU 300 that contain two or more controllers, and can be implemented by one of the controllers, such as a controller that is responsible for more control functions and already has relatively large storage space.

[0037] Figure 5 An example flowchart of a software update method 500 according to some embodiments of the present disclosure is illustrated. The method 500 can be executed by a first controller in an electronic control unit, wherein the electronic control unit may include the first controller and a second controller. The method 500 may include steps 510 to 530, enabling the update of software in the second controller via the first controller and backing up the software running on the second controller before the update to the storage space of the first controller to support the software version rollback function of the second controller. This helps to reduce the storage space capacity of the second controller, reduce the size and cost of the second controller, and thus reduce the overall size and cost of the electronic control unit, while ensuring the rollback function of the second controller. Details are as follows.

[0038] In step 510, a second software update file for updating the second software in the second controller can be obtained. Taking a vehicle scenario as an example, the first controller can receive the second software update file from other modules via the vehicle's communication bus, such as from the main control device responsible for software updates (e.g., OTA updates).

[0039] For example, the master control device can send the aforementioned second software update file to the first controller based on the identifier of the first controller, wherein the identifier of the first controller can be its address, identifier, or other information that can uniquely identify the first controller. Further exemplarily, when a second software update file for the second controller exists, the master control device can directly send a second software update request to the first controller to request an update to the second software in the second controller. In response to receiving the second software update request from the master control device, the first controller can send an acknowledgment message and begin receiving the second software update file from the master control device.

[0040] In step 520, the second software update file can be stored in the storage space of the first controller. For example, similar to the microcontroller described above, the storage space in the first controller can be divided into an execution area and a storage area. The execution area can be used to store currently running software in the first controller, and the aforementioned second software update file can be stored in the storage area. Here, the storage space of the first controller can be understood as a non-volatile storage structure in the first controller, such as ROM (Read-Only Memory).

[0041] In step 530, the second software in the second controller can be updated via the communication link between the first controller and the second controller, based on the second software update file stored in the storage space of the first controller, and the running file of the second software in the second controller can be backed up to the storage space of the first controller as a second backup file for rolling back the second software in the second controller to the version before the update.

[0042] Optionally, the communication link between the first controller and the second controller can be a serial interface-based communication link, such as an SPI (Serial Peripheral Interface) bus, to enable bidirectional and fast communication between the two, thereby ensuring that the software in the second controller can be updated through the first controller with high efficiency, the software version of the second controller running before the update can be backed up on the first controller, or the software in the second controller can be rolled back to the previous version based on the backup on the first controller.

[0043] For example, upon receiving a second software update file for the second controller, the first controller can store the second software update file and instruct the second controller to enter a software update state via the communication link between the two. For instance, this can be achieved by setting a relevant pin of the second controller to an active level, sending a relevant message (such as an update request), or otherwise instructing the second controller to enter the software update state. Subsequently, the first controller can send the second software update file stored in its storage space to the second controller via the communication link. The second controller can update the second software based on the received second software update file; for example, it can write the received second software update file into the execution area of ​​the second controller under the guidance of its FBL module. Optionally, this can be achieved by referring to... Figure 2C A similar method is used to exchange the second software update file stored in the first controller and the currently running second software file in the second controller. Specifically, the exchange is achieved gradually through multiple exchange steps using a caching structure, where a portion of both can be exchanged in each step. Alternatively, before sending the second software update file to the second controller, the first controller can receive relevant files of the currently running second software (i.e., the version of the second software before the update) from the second controller and store them in the first controller's storage space as backup files for the second software. For example, after receiving and storing the second software update file for the second controller, the first controller can send a backup request to the second controller, causing the second controller to send relevant files to the first controller as backup files in response. After the backup is complete, the first controller can instruct the second controller to enter a software update state and send the second software update file to the second controller to update the second software in the second controller.

[0044] In some embodiments, the method 500 may further include: in response to the need for the second software in the second controller to roll back to a previous version, updating the second software in the second controller via the aforementioned communication link, based on a second backup file stored in the storage space of the first controller. Exemplarily, the software can be rolled back to a previous version when the update fails or is interrupted, the updated software has defects, the updated software has compatibility issues with hardware or conflicts with other software, the user chooses to roll back due to poor experience or other reasons, the supplier requests a rollback due to problems with the new version, or other problems occur. The process of rolling back the second software in the second controller to a previous version based on the second backup file stored in the first controller via the communication link between the two is similar to the aforementioned update process for the second software, except that no backup operation is required; for simplicity, it will not be elaborated further here.

[0045] In addition to performing software updates for the second controller, the first controller can also normally perform software updates for itself. Therefore, in some embodiments, the above method 500 may further include: obtaining a first software update file for updating the first software in the first controller; storing the first software update file in the storage space of the first controller; updating the first software in the first controller based on the first software update file, and backing up the runtime files of the first software in the first controller to the storage space of the first controller as a first backup file for rolling back the first software to the version before the update. Exemplarily, when the first controller performs a software update for itself, it can be compared with the foregoing reference... Figures 2A to 2D The process described above similarly performs updates and optionally rollbacks, or other similar processes can be adopted, which will not be elaborated here.

[0046] Since software updates for both the first and second controllers can be performed via the first controller, in some embodiments, the master control device can communicate only with the first controller without communicating with the second controller. This saves the communication IDs (identifiers) used to identify different devices in the relevant communication network; these identification IDs are typically included in the transmitted messages to identify the sender and receiver.

[0047] In some embodiments, the method 500 described above can be applied to situations where the storage space of the first controller in the first memory is larger than the storage space of the second controller. For example, in reference... Figure 3 In the described ECU for a vehicle braking system, the microcontroller 320 can be updated using the microcontroller 310 according to method 500, and a backup of the microcontroller 320 can be stored on the microcontroller 310. Thus, software rollback functionality can be supported while maintaining the same storage space size for the microcontroller 320 (e.g., still using a microcontroller model with 2MB of storage space required to support parking redundancy and integrate several related PBC libraries). Meanwhile, since the microcontroller 310 already requires a larger storage space to support more complex control functions—for example, it might need to be implemented using a microcontroller model with 8MB of storage space (e.g., 8MB of ROM)—storing an additional backup file for the microcontroller 320 does not significantly increase its storage space requirements and does not lead to an upgrade of the microcontroller model. Therefore, through the above method 500, software rollback functionality can be supported without increasing the size and cost of the microcontroller 320, and consequently, without increasing the size and cost of the ECU 300.

[0048] However, it should be understood that in some cases, the above method 500 may also be implemented in a controller with smaller storage space. For example, in some cases, the function performed by a controller with smaller storage space may be very simple, and although its internal storage space is small, its redundancy is still large, while the redundancy of a controller with larger storage space may be smaller due to its relatively complex function. In this case, the above method 500 may also be implemented by a controller with smaller storage space.

[0049] As a further example, when method 500 is implemented in the ECU, the following can be adopted: Figure 6 The architecture shown is similar. Figure 4 The architecture shown is as follows: Figure 6 As shown, ECU 610 includes two controllers, 611 and 612. The difference lies in that the execution area within controller 611 stores the currently executing software 6111, while the storage area stores both a backup 6112 for controller 611 and a backup 6122 for controller 612. The storage area within controller 612 does not store backup files. Controller 611 can communicate with the OTA master module 620 via a communication line such as a bus to receive software update files for controllers 611 and 612 and to perform other information interactions related to OTA updates. Optionally, controller 612 can also be connected to a bus to meet other communication needs; however, when performing OTA updates according to the method 500 proposed in this disclosure, controller 612 may not need to communicate with the OTA master module 620, but only needs to interact with controller 611. The interaction between controllers 611 and 612 can be implemented, for example, via an SPI bus within ECU 610.

[0050] Furthermore, this disclosure also provides an electronic control unit, which may include a first controller and a second controller, wherein the first controller is configured to execute the software update method 500 described according to the various embodiments above. Exemplarily, the electronic control unit proposed in this disclosure may have similar... Figure 3 or Figure 6 The structure of ECU 300 or ECU 610 shown is illustrated. However, it should be understood that the electronic control unit proposed in this disclosure is not limited to the vehicle braking system ECU described above, and may also be other types of electronic devices with two controllers.

[0051] This disclosure also provides a computer-readable storage medium having computer-executable instructions stored thereon, which, when executed, implement any embodiment of the software update method 500 described above.

[0052] This disclosure also provides a computer program product or computer program including computer-executable instructions. The computer-executable instructions may be stored in a computer-readable storage medium. A processor of a computing device may read the computer-executable instructions from the computer-readable storage medium and execute the computer-executable instructions, causing the computing device to perform the software update method 500 provided in the various embodiments described above.

[0053] By studying the accompanying drawings, the disclosure, and the appended claims, those skilled in the art can understand and implement various variations of the disclosed embodiments in practicing the claimed subject matter. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not imply that a combination of these measures cannot be beneficial.

Claims

1. A software update method, wherein, The method is executed by a first controller in an electronic control unit, the electronic control unit including the first controller and a second controller, the method comprising: Obtain the second software update file used to update the second software in the second controller; The second software update file is stored in the storage space of the first controller; The second software in the second controller is updated via the communication link between the first controller and the second controller, based on the second software update file stored in the storage space of the first controller. The running file of the second software in the second controller is backed up to the storage space of the first controller as a second backup file for rolling back the second software in the second controller to the version before the update.

2. The method according to claim 1, further comprising: In response to the need for the second software in the second controller to be rolled back to a previous version, the second software in the second controller is updated via the communication link based on the second backup file stored in the storage space of the first controller.

3. The method according to claim 1, further comprising: Obtain a first software update file for updating the first software in the first controller; The first software update file is stored in the storage space of the first controller; The first software in the first controller is updated based on the first software update file, and the running files of the first software in the first controller are backed up to the storage space of the first controller as a first backup file for rolling back the first software to the version before the update.

4. The method according to claim 1, wherein, The step of obtaining the second software update file for updating the second software in the second controller includes: In response to receiving a second software update request from the master control device, the second software update file is received from the master control device, wherein the second software update request is used to request an update of the second software in the second controller.

5. The method according to claim 1, wherein, The step of updating the second software in the second controller via the communication link between the second controller and the first controller, based on the second software update file stored in the storage space of the first controller, includes: The second controller is instructed to enter a software update state via the communication link; The second software update file, stored in the storage space of the first controller, is sent to the second controller via the communication link.

6. The method according to any one of claims 1 to 5, wherein, The communication link is a serial interface-based communication link.

7. The method according to any one of claims 1 to 5, wherein, The storage space of the first controller is greater than that of the second controller.

8. An electronic control unit, comprising a first controller and a second controller, wherein, The first controller is configured to perform the software update method according to any one of claims 1-7.

9. A computer-readable storage medium storing computer-executable instructions that, when executed, perform the method according to any one of claims 1 to 7.

10. A computer program product comprising computer-executable instructions that, when executed, implement the steps of the method according to any one of claims 1 to 7.

Images