Automobile multi-ECU (Electronic Control Unit)-oriented software flashing control method and corresponding system

Abstract

The invention discloses an automobile multi-ECU (Electronic Control Unit) oriented software flashing control method and a corresponding system. The method comprises the steps that an upper computer sends a software flashing instruction to a plurality of ECUs according to a set distribution mechanism, after the ECUs receive the software flashing instruction, a current flashing task is executed, a flashing result is returned to the upper computer, if the upper computer receives that the flashing results returned by all the ECUs are successful, it is determined that current software flashing is successful, and if the flashing results returned by all the ECUs are not successful, the upper computer does not execute the software flashing task. If the received flashing result of at least one ECU is failure, determining that the current software flashing fails, sending a flashing failure mark to all the ECUs, judging the own flashing state by each ECU receiving the flashing failure mark, if the ECU is in any one of flashing success, flashing failure or flashing task execution, rolling back to the original version, and if the ECU is in any one of flashing success, flashing failure or flashing task execution, returning to the original version. And if the flash task is not entered, keeping the original version. Therefore, software flashing synchronization of all the ECUs is guaranteed, the situation that software versions of the whole vehicle ECU are inconsistent due to flashing failure of part of the ECUs is avoided, and the system stability and driving safety of the whole vehicle are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle electronic control technology, specifically to the fields of automatic software flashing and batch upgrades, and particularly to a software flashing control method and corresponding system for multiple ECUs in automobiles. Background Technology

[0002] As automotive electronic and electrical architectures become increasingly complex, the number of Electronic Control Units (ECUs) in modern vehicles is growing daily, leading to a surge in the complexity of vehicle functions. These ECUs perform numerous critical functions, encompassing chassis control, infotainment system regulation, and autonomous driving capabilities. Under increasingly stringent emission standards and fierce market competition, the pace of ECU software updates has accelerated significantly. This not only demands that ECUs be capable of rapid and frequent upgrades but also requires the entire vehicle to maintain stable and reliable operation during the upgrade process.

[0003] Traditional ICP (In-Circuit Programming) or ISP (In-System Programming) methods are no longer sufficient to meet the current needs of ECU software updates. In contrast, IAP (In-Application Programming) stands out due to its high flexibility and freedom, and can seamlessly integrate with remote OTA (Over-The-Air) upgrades. However, current IAP technologies mostly focus on updating individual ECUs. When adjusting a function of the entire vehicle, it is often necessary to update the software of multiple ECUs simultaneously. Due to the complex communication and dependencies between these ECUs, if it is not possible to ensure that all relevant ECUs complete consistent updates synchronously, the system will become unstable, leading to the vehicle's inability to operate normally. Summary of the Invention

[0004] This application provides a software flashing control method and corresponding system for multiple ECUs in automobiles, in order to solve the problem that when flashing a single ECU fails, it cannot be updated synchronously with other related ECUs, resulting in an unstable state of the vehicle system.

[0005] The technical solution is as follows: Firstly, a software flashing control method for multiple ECUs in automobiles is provided, including: The host computer identifies multiple Electronic Control Units (ECUs) to be flashed in this task and sends software flashing instructions to these ECUs according to a set distribution mechanism. After the ECU receives the software flashing instruction, it executes the flashing task and returns the flashing result to the host computer. If all ECU flashing results received by the host computer are successful, then the software flashing is considered successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Each ECU that receives the flashing failure flag determines its own flashing status. If it meets any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it remains in the original version.

[0006] In one possible implementation, the distribution mechanism is a serial, sequential distribution; then the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, specifically including: The host computer sends a software flashing instruction to one of the ECUs, so that the current ECU can perform the flashing task. When the host computer receives a successful flashing result from the current ECU, it sends a software flashing instruction to the next ECU so that the next ECU can execute the flashing task. Repeat the above steps until all ECUs receive the software flashing instruction.

[0007] In one possible implementation, the distribution mechanism is parallel distribution; then the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, specifically including: The host computer simultaneously sends software flashing instructions to all ECUs, so that all ECUs can execute the flashing task in parallel.

[0008] In one possible implementation, the ECU cancels the flashing task and returns a flashing result of failure to the host computer if some or all of the following conditions occur: ECU backup of original version data failed; ECU failed to download new version data; ECU fails to verify new version data; Failed to write new version data to ECU.

[0009] In one possible implementation, ECU backup of the original version of data may fail due to: the target location being occupied, or sector erasure failure. Failure to download new version data to the ECU may be due to external interference with the signal of the new version data, or an error in the host computer program. Errors in ECU verification of new version data include: data tampering; Failure to write new version data to the ECU includes: the new version data exceeds the predetermined sector storage space.

[0010] Secondly, a software flashing control system for multiple ECUs in automobiles is provided, including: a host computer and multiple electronic control units (ECUs); wherein... The host computer determines the multiple ECUs to be flashed in this task and sends software flashing instructions to the multiple ECUs according to the set distribution mechanism. After the ECU receives the software flashing instruction, it executes the flashing task and returns the flashing result to the host computer. If all ECU flashing results received by the host computer are successful, then the software flashing is considered successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Each ECU that receives the flashing failure flag determines its own flashing status. If it meets any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it remains in the original version.

[0011] Thirdly, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0012] Fourthly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the aspects described above and any possible implementation thereof.

[0013] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aspects and any possible implementations described above.

[0014] In a sixth aspect, a host computer device is provided, including an electronic device that performs the host computer-side method as described above.

[0015] The beneficial effects of the technical solution provided in this application include at least the following: As can be seen from the above technical solution, in this embodiment, the host computer sends software flashing instructions to multiple ECUs according to a set distribution mechanism. After receiving the software flashing instructions, the ECU executes the flashing task and returns the flashing result to the host computer. If the host computer receives successful flashing results from all ECUs, it determines that the software flashing is successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Then, each ECU that receives the flashing failure flag determines its own flashing status. If it is in any of the following states: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it retains the original version. This solution can ensure that the software flashing of all ECUs is synchronized and consistent, avoiding inconsistencies in the software versions of the entire vehicle's ECUs due to the failure of some ECUs to flash, thus improving the stability of the entire vehicle system and driving safety.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating the steps of the software flashing control method for multiple ECUs in a vehicle provided in this application embodiment.

[0019] Figure 2 This is a flowchart illustrating the process of controlling the writing process using a serial method.

[0020] Figure 3 This is a flowchart illustrating the process of writing data in a parallel manner.

[0021] Figure 4 This is a structural block diagram of a software flashing control system for multiple ECUs in a vehicle provided in one embodiment of this application.

[0022] Figure 5 This is a block diagram of an electronic device used to implement the software flashing control method for multiple ECUs in automobiles according to the embodiments of this application. Detailed Implementation

[0023] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0024] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that the terminal devices involved in the embodiments of this application may include, but are not limited to, smart devices such as mobile phones, personal digital assistants (PDAs), wireless handheld devices, and tablet computers; the display devices may include, but are not limited to, personal computers, televisions, and other devices with display functions.

[0026] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0027] In view of the problem in existing software flashing schemes where the failure of a single ECU flashing leads to the inability to synchronize with other related ECUs, resulting in vehicle system instability, this application proposes a software flashing control scheme for multiple ECUs in automobiles. The main inventive concept is as follows: the host computer sends software flashing instructions to multiple ECUs according to a set distribution mechanism. After receiving the software flashing instructions, the ECU executes the flashing task and returns the flashing result to the host computer. If the host computer receives flashing results from all ECUs that are successful, it determines that the software flashing is successful. If the host computer receives flashing results from at least one ECU that are unsuccessful, it determines that the software flashing is unsuccessful and sends a flashing failure flag to all ECUs. Then, each ECU that receives the flashing failure flag determines its own flashing status. If it is in any of the following states: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it retains the original version. This application solution can ensure that the software flashing of all ECUs is synchronized and consistent, avoiding inconsistencies in the software versions of the entire vehicle's ECUs due to flashing failures of some ECUs, thereby improving the stability of the entire vehicle system and driving safety.

[0028] Reference Figure 1 The diagram illustrates the steps of a software flashing control method for multiple ECUs in a vehicle, as provided in an embodiment of this application. It should be understood that the software flashing control scheme of this application is based on the interaction between a host computer and multiple ECUs in the target vehicle. The host computer can be a cloud server or a regular server, used to provide software upgrade and update services for the vehicle's ECUs.

[0029] like Figure 1 The software flashing control method may include the following steps: Step 102: The host computer identifies the multiple Electronic Control Units (ECUs) to be flashed in this task and sends software flashing instructions to the multiple ECUs according to the set distribution mechanism.

[0030] In this application's scheme, firstly, the host computer needs to identify all ECUs related to this flashing task. In other words, even if the operation of a certain ECU does not involve the new function, its operation result may affect the new function. Therefore, all ECUs related to this flashing task (the function corresponding to the version to be upgraded) are identified as ECUs to be flashed. Then, software flashing instructions are sent to multiple ECUs according to a set distribution mechanism. These software flashing instructions can carry a flag bit for software flashing; for example, 0 represents no flashing, and 1 represents flashing.

[0031] One possible implementation is that the distribution mechanism is a serial, sequential distribution; when the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, it can specifically send a software flashing instruction to one of the ECUs so that the current ECU can perform the flashing task; when the host computer receives a successful flashing result from the current ECU, it sends a software flashing instruction to the next ECU so that the next ECU can perform the flashing task; the above operation is repeated until all ECUs receive the software flashing instructions.

[0032] Another possible implementation is a parallel distribution mechanism; in this case, when the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, it can specifically send software flashing instructions to all ECUs simultaneously, so that all ECUs can execute the flashing task in parallel.

[0033] Step 104: After the ECU receives the software flashing instruction, it executes the flashing task and returns the flashing result to the host computer.

[0034] In this application's scheme, each ECU executes the flashing task upon receiving a software flashing instruction. It should be noted that, initially, the Flash memory of all ECUs is allocated to accommodate the code of two applications, thus dividing it into Area A and Area B. Area A is for the primary running application, and Area B is for backup applications. The specific flashing task process is as follows: Step 1: Trigger the ECU to enter the Boot program: Send the flashing program flag to the ECU. Normally, the ECU will run the APP program, but it needs to be triggered externally to enter the Boot program, preparing for flashing.

[0035] Step 2: Wait for the ECU to back up the APP data: The ECU's Flash storage area is divided into Area A and Area B, both of which can have the same storage size to achieve redundant protection of APP data. During normal operation, the APP resides in Area A. Simultaneously, the data in Area A is completely copied to Area B so that in the event of a flashing failure, the correct and complete data in Area B can be used for a rollback operation, ensuring stable system operation.

[0036] Step 3: Data transmission to the ECU: During data transmission, many uncontrollable factors may be encountered, such as signal interference, insufficient ECU receiving capability, and interruption of transmission from the host computer. Therefore, the ECU performs strict verification and processing when receiving data to ensure the accuracy and integrity of the data.

[0037] Step 4: Wait for the ECU to return the flashing result: After the data is transmitted to the ECU, it needs to be verified to confirm correct reception. Due to limitations and security considerations of the CAN protocol, the complete APP code is usually divided into reasonably sized data blocks and transmitted one by one. A verification is performed after each data segment is transmitted; after all data transmissions are complete, a final overall verification is performed to ensure the stability and reliability of the transmission process. After the overall verification passes, the flashing result is returned to the host computer.

[0038] As can be seen from steps 1 to 4 above, the ECU that receives the software flashing instruction will execute the flashing task according to the above process. The subsequent flashing tasks will not be described in detail, but will be referred to as flashing tasks or flashing task processes instead.

[0039] Optionally, the ECU will cancel the flashing task and return a flashing result of failure to the host computer if some or all of the following situations occur: ECU fails to back up the original version data; ECU fails to download the new version data; ECU fails to verify the new version data; ECU fails to write the new version data. Specifically, failure to back up the original version data includes: the target location is occupied, or sector erasure fails; failure to download the new version data includes: the signal of the new version data is interfered with externally, or the host computer program malfunctions; failure to verify the new version data includes: the data has been tampered with; and failure to write the new version data includes: the new version data exceeds the predetermined sector storage space.

[0040] When writing to the ECU's Flash memory, it is necessary to first determine whether the target location has already been written to (i.e., check if it is not in a 0xFF state) and ensure that the sector erasure process is successfully completed. If any step in the backup process fails, such as the target location being occupied or the sector erasure failing, the backup data will fail, which will trigger the generation of a flash failure flag.

[0041] At the same time, it is also necessary to consider that external interference factors may damage the integrity of the data during the data transmission process between the host computer and the ECU. Even if the transmission process seems smooth, the transmitted data itself may contain errors. Once the ECU finds that the data integrity is damaged or there are other problems when receiving and verifying the data, it will determine that the verification has failed and send a flashing failure flag; or, if the interruption of the transmission network causes the download of the new version to fail, a flashing failure flag will also be generated.

[0042] Step 106: If all ECU flashing results received by the host computer are successful, then the software flashing is considered successful.

[0043] Based on the distribution mechanism mentioned in step 102, if the host computer sends software flashing instructions to multiple ECUs sequentially in a serial distribution manner, then if the first ECU is successfully flashed, the second ECU is triggered to execute the flashing task; if the second ECU is successfully flashed, the third ECU is triggered to execute the flashing task. Furthermore, assuming that each ECU is successfully flashed, the flashing can be performed in the manner described in steps 102-104 above. When all ECUs are successfully flashed, the software flashing is considered successful.

[0044] If the host computer sends software flashing instructions to multiple ECUs simultaneously in a parallel distribution manner, then considering that the flashing time of each ECU may be different, assuming that the flashing result received from each ECU at different times is successful, then the software flashing is determined to be successful.

[0045] Step 108: If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs.

[0046] When the host computer receives a failed flashing result from one or more ECUs, it determines that the software flashing has failed and can return a flashing failure flag to all ECUs. It should be understood that this application involves two flashing result identifiers. First, there is the flashing result sent to the host computer after each ECU has completed the flashing process; this result can be either a flashing failure flag or a flashing success flag. Second, there is the flashing failure flag sent to all ECUs by the host computer after determining that the software flashing has failed. This flashing failure flag can be distinguished from the flashing failure flag in the flashing result; for example, the flashing failure flag can be the character "failed" or "x," and the flashing failure flag bit can be the English letter "F."

[0047] Step 110: Each ECU that receives the flashing failure flag determines its own flashing status. If it meets any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing; if it has not entered the flashing task, it remains in the original version.

[0048] If the host computer sends software flashing instructions to multiple ECUs sequentially using a serial distribution method, then after the first ECU is successfully flashed, the second ECU will be triggered to execute the flashing task. If the second ECU fails to flash, no subsequent ECUs will be triggered to execute the flashing task. Simultaneously, a flashing failure flag will be sent to all ECUs. Even if the first ECU flashes successfully, it will still roll back to the original version before the flash. Similarly, if the second ECU fails to flash, it will also roll back to the original version before the flash. Subsequent ECUs will not enter the flashing task and will remain on their original versions.

[0049] If the host computer sends software flashing instructions to multiple ECUs in a parallel distribution manner, assuming the first ECU flash is successful, the second ECU flash is successful, and the third ECU flash fails, then regardless of whether subsequent ECU flashes are successful, once a flash failure is received, a flash failure flag is sent to all ECUs. Upon receiving the flash failure flag, each ECU will choose to roll back to its original version or remain at its original version based on its own status. For example, the first ECU that successfully flashed will still roll back to its original version to maintain the same software version as the ECU that failed; the same applies to the second ECU. The third ECU, due to the flash failure, must also roll back to its original version. As for the other ECUs, considering that the software flashing instructions are distributed in parallel, it can be anticipated that all ECUs have entered the flashing task, but due to different execution capabilities, the processes are not synchronized, resulting in different completion progresses. Therefore, the other ECUs also need to roll back to their original versions.

[0050] In this way, regardless of the distribution method used by the host computer to send software flashing instructions to multiple ECUs, and regardless of whether the software flashing task is successfully completed, all ECUs will be at the same version level, i.e., the original version or the new version. There will be no situation where some are the original version and some are the new version. This avoids the system from being unable to function properly due to different versions, thus improving the stability and safety of the vehicle system.

[0051] The following section uses two ECUs, ECU1 and ECU2, as examples to briefly describe the software flashing control scheme of this application.

[0052] Reference Figure 2 The diagram shown is a flowchart illustrating the process of controlling the write operation using a serial method.

[0053] After the software flashing process begins, the host computer sends a flashing flag (e.g., 1) to ECU1. Upon receiving the flashing flag as 1, ECU1 begins backing up the original version of the application. If the backup fails, the process jumps to the termination procedure: a flashing failure flag is sent to all ECUs, and the flashing task ends after all ECUs have rolled back or canceled the flashing. If the backup succeeds, data (i.e., the new version of the application) is transferred from the host computer to ECU1. The host computer then waits for ECU1 to return the flashing result. If the returned flashing result is a failure, the process jumps to the termination procedure. If the returned flashing result is a success, the host computer sends a flashing flag to ECU2. Upon receiving the flashing flag as 1, ECU2 begins backing up the original version of the application. Similarly, if the backup fails, the process jumps to the termination procedure, and the flashing task ends after all ECUs have rolled back or canceled the flashing. If the backup is successful, data transmission (i.e., the new version of the APP) will begin from the host computer to ECU2. The host computer will then wait for ECU2 to return the flashing result. If the returned flashing result is a failure, the process will terminate. If the returned flashing result is a success, the flashing task is confirmed to have been successfully completed.

[0054] Reference Figure 3 The diagram shown is a flowchart illustrating the process of writing data in a parallel manner.

[0055] After the software flashing process begins, the host computer simultaneously sends a flashing flag (e.g., 1) to ECU1 and ECU2. Upon receiving the flashing flag as 1, ECU1 and ECU2 begin backing up the original version of the application. If the backup fails, the process jumps to the termination phase: a flashing failure flag is sent to all ECUs, and the flashing task ends after all ECUs have rolled back or canceled the flashing. If the backup is successful, data (i.e., the new version of the application) is transferred from the host computer to ECU1. The host computer then waits for ECU1 to return the flashing result. If the returned flashing result is a failure, the process jumps to the termination phase. If all returned flashing results are successes, the flashing task is considered successfully completed. In other words, if even one ECU returns a flashing failure result, the successfully flashed ECU software is not recognized; instead, all ECU software is rolled back to the original version, ensuring all ECUs are on the same software version, guaranteeing system stability and driving control safety.

[0056] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0057] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0058] Figure 4 This application provides a structural block diagram of a software flashing control system for multiple ECUs in an automobile, as shown in one embodiment. Figure 4 As shown. The software flashing control system 400 for multiple ECUs in a car in this embodiment may include a host computer 401 and multiple electronic control units (ECUs) 402. Figure 4 The diagram shows multiple target vehicles, each equipped with multiple ECUs 402. A host computer 401 identifies the multiple ECUs to be flashed and sends software flashing instructions to them according to a pre-defined distribution mechanism. Upon receiving the instructions, each ECU 402 executes the flashing task and returns the flashing result to the host computer 401. If all flashing results received by the host computer 401 from all ECUs 402 are successful, the software flashing is considered successful. If at least one ECU 402 receives a failed flashing result, the software flashing is considered a failure, and a flashing failure flag is sent to all ECUs 402. Each ECU 402 receiving the failure flag determines its flashing status. If it satisfies any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the flashing. If it has not yet entered the flashing task phase, it remains in the original version.

[0059] Optionally, in one possible implementation of this embodiment, the distribution mechanism is a serial sequential distribution; when the host computer 401 sends a software flashing instruction to the plurality of ECUs 402 according to the set distribution mechanism, it is specifically used to send a software flashing instruction to one of the ECUs so that the current ECU 402 performs the flashing task; when the host computer 401 receives a successful flashing result returned by the current ECU 402, it sends a software flashing instruction to the next ECU 402 so that the next ECU 402 performs the flashing task; the above operation is repeated until all ECUs 402 receive the software flashing instruction.

[0060] Optionally, in one possible implementation of this embodiment, the distribution mechanism is parallel distribution; then when the host computer 401 sends the software flashing instruction to the multiple ECUs according to the set distribution mechanism, it is specifically used to send the software flashing instruction to all ECUs 402 at the same time, so that all ECUs 402 execute the flashing task in parallel.

[0061] Optionally, in one possible implementation of this embodiment, the ECU402 cancels the current flashing task and returns a flashing result of failure to the host computer 401 when some or all of the following situations occur: ECU402 fails to back up the original version data; ECU402 fails to download the new version data; ECU402 fails to verify the new version data; ECU402 fails to write the new version data.

[0062] Optionally, in one possible implementation of this embodiment, the failure of ECU402 to back up the original version data includes: the target location is occupied, or the sector erasure fails; the failure of ECU402 to download the new version data includes: the signal of the new version data is interfered with by external factors, or the host computer program malfunctions; the failure of ECU402 to verify the new version data includes: the data is tampered with; the failure of ECU402 to write the new version data includes: the new version data exceeds the predetermined sector storage space.

[0063] In this embodiment, the host computer sends software flashing instructions to multiple ECUs according to a set distribution mechanism. After receiving the software flashing instructions, each ECU executes the flashing task and returns the flashing result to the host computer. If the host computer receives successful flashing results from all ECUs, it determines that the software flashing is successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Subsequently, each ECU that receives the flashing failure flag determines its own flashing status. If it is in any of the following states—failed flashing, successful flashing, or in the process of flashing—it rolls back to the original version before the software flashing. If it has not entered the flashing task, it retains the original version. This application solution can ensure that the software flashing of all ECUs is synchronized and consistent, avoiding inconsistencies in the software versions of all vehicle ECUs due to the failure of some ECUs, thereby improving the stability of the entire vehicle system and driving safety.

[0064] One embodiment of this application provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the software flashing control method for multiple ECUs in a vehicle as described above.

[0065] One embodiment of this application provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction, which is loaded and executed by the processor to implement the software flashing control method for multiple ECUs in a vehicle as described above.

[0066] One embodiment of this application provides a host computer device, including an electronic device for performing the host computer-side method as described above.

[0067] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0068] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0069] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0070] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0071] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as host computer devices, including electronic device methods for performing host computer-side methods as described above. For example, in some embodiments, the host computer device, including electronic device methods for performing host computer-side methods as described above, can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the host computer device described above, including electronic device methods for performing host computer-side methods as described above, can be performed. Alternatively, in other embodiments, the computing unit 501 may be configured by any other suitable means (e.g., by means of firmware) to perform a host computer device, including an electronic device method for performing a host computer-side method as described above.

[0072] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, at least one input device, and at least one output device.

[0073] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0074] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0075] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0076] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0077] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0078] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0079] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A software flashing control method for multiple ECUs in automobiles, characterized in that, include: The host computer identifies multiple Electronic Control Units (ECUs) to be flashed in this task and sends software flashing instructions to these ECUs according to a set distribution mechanism. After the ECU receives the software flashing instruction, it executes the flashing task and returns the flashing result to the host computer. If all ECU flashing results received by the host computer are successful, then the software flashing is considered successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Each ECU that receives the flashing failure flag determines its own flashing status. If it meets any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it remains in the original version.

2. The method as described in claim 1, characterized in that, The distribution mechanism is a serial, sequential distribution; therefore, the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, specifically including: The host computer sends a software flashing instruction to one of the ECUs, so that the current ECU can perform the flashing task. When the host computer receives a successful flashing result from the current ECU, it sends a software flashing instruction to the next ECU so that the next ECU can execute the flashing task. Repeat the above steps until all ECUs receive the software flashing instruction.

3. The method as described in claim 1, characterized in that, The distribution mechanism is a parallel distribution; therefore, the host computer sends software flashing instructions to the multiple ECUs according to the set distribution mechanism, specifically including: The host computer simultaneously sends software flashing instructions to all ECUs, so that all ECUs can execute the flashing task in parallel.

4. The method according to any one of claims 1-3, characterized in that, The ECU will cancel the flashing task and return a flashing result of failure to the host computer if some or all of the following conditions occur: ECU backup of original version data failed; ECU failed to download new version data; ECU fails to verify new version data; Failed to write new version data to ECU.

5. The method as described in claim 4, characterized in that, ECU backup failure to back up original data may include: the target location is occupied, or sector erasure failed; Failure to download new version data to the ECU may be due to external interference with the signal of the new version data, or an error in the host computer program. Errors in ECU verification of new version data include: data tampering; Failure to write new version data to the ECU includes: the new version data exceeds the predetermined sector storage space.

6. A software flashing control system for multiple ECUs in automobiles, characterized in that, include: The host computer and multiple electronic control units (ECUs); in The host computer determines the multiple ECUs to be flashed in this task and sends software flashing instructions to the multiple ECUs according to the set distribution mechanism. After the ECU receives the software flashing instruction, it executes the flashing task and returns the flashing result to the host computer. If all ECU flashing results received by the host computer are successful, then the software flashing is considered successful. If the host computer receives a failed flashing result from at least one ECU, it determines that the software flashing has failed and sends a flashing failure flag to all ECUs. Each ECU that receives the flashing failure flag determines its own flashing status. If it meets any of the following conditions: flashing successful, flashing failed, or flashing task in progress, it rolls back to the original version before the software flashing. If it has not entered the flashing task, it remains in the original version.

7. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-5.

8. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-5.

9. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-5.

10. A host computer device, comprising an electronic device for performing the host computer method as described in claim 7.

Images