Vehicle-mounted ECU software flashing method and device and vehicle

Abstract

The embodiment of the invention relates to the technical field of configuration updating of vehicle electronic control units, and discloses a vehicle-mounted ECU software flashing method and device and a vehicle. The method comprises the steps that in response to a received ECU software flashing request instruction, an execution module obtained based on Stateflow conversion is called, and an ECU software flashing process is executed according to the execution module; the execution module comprises a plurality of diagnosis units connected in series, each diagnosis unit corresponds to one diagnosis service in the ECU flashing process, and the diagnosis units output first identification information or second identification information after executing the corresponding diagnosis service; responding to the diagnosis units to output the first identification information, and controlling the ECU software flashing process to flow from the current diagnosis unit to the next diagnosis unit connected in series; and in response to the second identification information output by the diagnosis unit, controlling the ECU software flashing process to jump to a preset abnormal termination state, and terminating the ECU software flashing process. By applying the technical scheme of the invention, an application scene of rapid software program flashing can be better adapted.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle electronic control unit configuration updates, specifically to a method, apparatus, and vehicle for flashing vehicle ECU software. Background Technology

[0002] Currently, with the increasing prevalence of in-vehicle communication technology, the demand for flashing in-vehicle ECU software programs is becoming more frequent. However, traditional flashing script-based process control methods have significant limitations and are no longer suitable for the industry's development needs. In practical applications, in-vehicle ECU software program flashing mainly relies on manually controlling state machines or using TTB or SDB scripts for process control. However, these methods have obvious drawbacks: on the one hand, pre-processing such as script planning, compilation, and execution must be completed in advance, and files need to be reloaded during application-level implementation. If file reading fails, it will directly lead to flashing failure; on the other hand, file reading efficiency is low and loading speed is slow in script control mode, resulting in low overall flashing efficiency, which cannot meet the actual needs of rapid industrial software program flashing in high-transmission-rate scenarios. Summary of the Invention

[0003] In view of the shortcomings of the prior art, the purpose of this application is to provide a method, device and vehicle for flashing vehicle ECU software, which can better adapt to the application scenarios of fast software program flashing.

[0004] In a first aspect, embodiments of this application provide a method for flashing vehicle ECU software, comprising: responding to receiving an ECU software flashing request instruction, invoking an execution module obtained based on Stateflow transformation, and executing an ECU software flashing process according to the execution module; the execution module includes a plurality of serially connected diagnostic units, each diagnostic unit corresponding to a diagnostic service in the ECU flashing process, and the diagnostic unit outputting first identification information or second identification information after executing the corresponding diagnostic service; responding to the diagnostic unit outputting the first identification information, controlling the ECU software flashing process to flow from the current diagnostic unit to the next serially connected diagnostic unit; responding to the diagnostic unit outputting the second identification information, controlling the ECU software flashing process to jump to a preset abnormal termination state, and terminating the ECU software flashing process.

[0005] In the above technical solution, the execution module, transformed by Stateflow, directly calls and executes the ECU software flashing process, eliminating the pre-planning, compilation, and file reloading steps of traditional script control, shortening the flashing process startup cycle, and reducing operational complexity. Furthermore, the execution module, generated based on Stateflow modeling, ensures a high degree of consistency between the flashing process logic design and execution code, standardizing the calling order and execution criteria of various diagnostic services, and reducing the risk of process chaos. The execution module integrates and connects several diagnostic units, each corresponding to a diagnostic service in the ECU flashing process. No additional service calling logic configuration is required, achieving automated progress of the flashing process and reducing manual intervention costs. The modular design of the diagnostic units facilitates adjustments to service configurations based on different ECU models and flashing scenarios without refactoring the overall process, improving the method's adaptability to various flashing needs and simplifying subsequent process optimization and maintenance. Simultaneously, the diagnostic units output first or second identification information to provide real-time feedback on the execution results of individual diagnostic services, ensuring that the process only proceeds to the next diagnostic unit when the current service is successful, avoiding error accumulation that could lead to flashing failure.

[0006] In one embodiment, the diagnostic unit is configured with service diagnostic identifier parameters, process step index parameters, and process execution status parameters; the diagnostic service identifier and diagnostic object identifier are obtained through the service diagnostic identifier parameters; the process step index parameters are used to monitor the operation of the ECU software flashing process, monitor abnormal interruptions, monitor step jumps, and implement step jumps; and the process execution status parameters are used to characterize the status result of the diagnostic service execution.

[0007] In the above technical solution, the service diagnostic identifier parameter is associated with both the diagnostic service identifier and the diagnostic object identifier, clearly specifying which service is being executed and which object it is being executed on. This avoids service call confusion or mis-applying to non-target objects, ensuring the accuracy of the flushing operation. The process step index parameter covers multi-dimensional monitoring of running status, abnormal interruptions, and step jumps, tracking the flushing process progress and node status in real time. This allows operators to intuitively grasp the process dynamics and quickly locate bottlenecks or anomalies. The process execution status parameter intuitively represents the execution result of the diagnostic service, such as success / failure, providing a clear basis for process flow decisions. This ensures that the next stage is only entered when the current service is completed normally, avoiding error accumulation.

[0008] In one embodiment, the execution module is configured with a diagnostic response processing and status feedback function. In response to receiving an ECU software flashing request instruction, the module calls the diagnostic response processing and status feedback function to perform an initial check and returns the initial check result. In response to the initial check passing, the module enters the first diagnostic unit to perform the corresponding diagnostic service. In response to the initial check failing, the module controls the ECU software flashing process to jump to a preset abnormal termination state and terminates the ECU software flashing process.

[0009] In the above technical solution, by configuring diagnostic response processing and status feedback functions, an initial check is performed immediately after the flashing request is triggered. This checks the basic conditions such as the online status of the ECU, the stability of the communication link, and the legality of permissions in advance, avoiding the initiation of subsequent flashing operations if the initial conditions are not met, thus reducing the risk of flashing failure from the source.

[0010] In one embodiment, in response to the ECU software flashing process jumping to a preset abnormal termination state, a preset abnormal handling strategy is executed.

[0011] In the above technical solution, after abnormal termination, a preset processing strategy is triggered, which can quickly perform operations such as ECU reset and exiting the flashing mode, so as to avoid the ECU being in a semi-working state for a long time due to process interruption and prevent irreversible failures such as firmware damage and hardware lock-up.

[0012] In one embodiment, the diagnostic unit includes a pre-programming stage diagnostic unit, a main programming stage diagnostic unit, and a post-programming stage diagnostic unit; the pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification diagnostics; the main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics; the post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and flashing record archiving diagnostics.

[0013] In the above technical solution, diagnostic units are broken down into preparation, execution, and completion stages. Each diagnostic unit focuses on the core tasks of its corresponding stage, avoiding task confusion between stages and ensuring that the flashing process proceeds in a standardized order. Furthermore, each stage's diagnostic unit performs dedicated diagnostic services, such as pre-programmed secure access and main-programmed integrity verification, adapting to the technical requirements of different stages, reducing cross-stage interference, and lowering the risk of flashing failure due to task mixing.

[0014] In one embodiment, the pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification diagnostics, specifically including: In response to receiving an ECU software flashing request command, the ECU wake-up function is called, a wake-up message is sent, and the ECU is woken up. If the ECU wake-up is successful, the process jumps to the extended session entry state. If the ECU wake-up fails, the process jumps to the preset abnormal termination state. In response to entering the extended session entry state, the ECU is switched to extended session mode, and the fault code storage function is disabled. If both switching the ECU to extended session mode and disabling the fault code storage function are successful, the system jumps to the secure access and flashing condition verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the secure access and flashing condition verification state, identity authentication and vehicle status checks are performed. If both identity authentication and vehicle status checks pass, the system jumps to the main programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

[0015] In the above technical solution, the step-by-step progressive diagnostic design of the pre-programming stage diagnostic unit realizes closed-loop control of the entire process of ECU flashing, including environmental preparation, mode adaptation, and safety verification. This intercepts the risks of invalid startup and unsafe flashing from the source, providing a foundation for subsequent core flashing processes and improving the safety and reliability of the overall flashing process.

[0016] In one embodiment, the main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics, specifically including: In response to the output of the first identification information by the pre-programming stage diagnostic unit, the ECU is switched to the programming session mode. If the switch to the programming session mode is successful, the system jumps to the Flash memory erase state; otherwise, it jumps to the preset abnormal termination state. In response to entering the Flash memory erase state, the Flash memory erase is performed. If the Flash memory erase is successful, the process jumps to the firmware data block download state; otherwise, it jumps to the preset abnormal termination state. In response to entering the firmware data chunk download state, the flashing tool is deployed and the application is downloaded. If the application download is completed, the process jumps to the integrity verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the integrity verification state, compatibility verification, version accuracy verification, and legality verification are performed. If the verification passes, the process jumps to the post-programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

[0017] In the aforementioned technical solution, a progressive diagnostic design—including programming session switching, Flash memory erasure, firmware data block download, and integrity verification—is implemented in the main programming phase diagnostic unit. This design achieves precise, secure, and reliable control over the core aspects of ECU software updates, ensuring a defect-free process from deployment to verification and providing core assurance for successful flashing. Furthermore, each step proceeds according to a rigid logic where the next step can only proceed after the previous one is successful, forming a full-link risk interception system to prevent the accumulation and expansion of errors and ensure that every operation complies with flashing standards.

[0018] In one embodiment, the post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and flash record archiving diagnostics, specifically including: In response to the first identification information output by the diagnostic unit in the main programming stage, an ECU reset is performed. If the reset is successful, the system configuration recovery state is entered; otherwise, the system is entered into a preset abnormal termination state. In response to entering the system configuration recovery state, the ECU's communication function and fault code storage function are restored. If the recovery operation is completed, it jumps to the flash record archiving state; otherwise, it jumps to the preset abnormal termination state. In response to entering the flashing record archiving state, a flashing report is generated and stored, including the execution results and response messages of the ECU flashing process.

[0019] In the above technical solution, the entire process of ECU reset, system configuration restoration and flashing record archiving by the diagnostic unit in the post-programming stage is handled to achieve safe ECU activation, system function restoration and operation traceability after flashing, ensuring the standardization and integrity of the flashing completion stage, and further improving the reliability and maintenance convenience of the overall ECU flashing process.

[0020] Secondly, embodiments of this application provide an in-vehicle ECU software flashing device, including a processor and a memory. The processor is used to execute computer programs or instructions stored in the memory, so that the in-vehicle ECU software flashing device implements the above-described in-vehicle ECU software flashing method.

[0021] Thirdly, embodiments of this application provide a vehicle including the aforementioned vehicle ECU software flashing device.

[0022] This application offers the following advantages: It employs an execution module derived from Stateflow, which executes the ECU software flashing process. This eliminates the need for pre-planning, compilation, and file reloading required by traditional script control, shortening the flashing process startup cycle and reducing operational complexity. Furthermore, generating the execution module based on Stateflow modeling ensures a high degree of consistency between the flashing process logic design and execution code, standardizing the call order and execution criteria of various diagnostic services and reducing the risk of process chaos. The execution module comprises several serially connected diagnostic units, each corresponding to a diagnostic service in the ECU flashing process. No additional service call logic configuration is required, enabling automated flashing process execution and reducing manual intervention costs. The modular diagnostic unit design facilitates service configuration adjustments based on different ECU models and flashing scenarios without requiring overall process refactoring, improving the method's adaptability to various flashing needs and simplifying subsequent process optimization and maintenance. Simultaneously, after executing the corresponding diagnostic service, each diagnostic unit outputs first or second identification information, providing real-time feedback on the execution result of a single diagnostic service. This ensures the process only proceeds to the next diagnostic unit upon successful execution of the current service, preventing error accumulation that could lead to flashing failure. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.

[0024] Figure 1 This is a schematic diagram of the vehicle structure disclosed in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the vehicle ECU software flashing device disclosed in the embodiments of this application; Figure 3 This is a flowchart illustrating the vehicle ECU software flashing method disclosed in an embodiment of this application.

[0025] Explanation of reference numerals in the attached figures: 10-Vehicle, 20-On-board ECU software flashing device, 21-Processor, 22-Memory, 23-Communication interface, 24-Bus. Detailed Implementation

[0026] The terms "first," "second," etc., are used for descriptive purposes only and have no sequential or technical meaning, nor should they be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Additionally, the character " / " in this document generally indicates that the preceding and following objects are in an "or" relationship.

[0027] The embodiments of this application are described below with reference to the accompanying drawings.

[0028] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the structure of a vehicle disclosed in an embodiment of this application. The vehicle 10 includes an on-board ECU software flashing device 20. The vehicle can be, but is not limited to, a pure electric vehicle / battery electric vehicle (PEV / BEV), a hybrid electric vehicle (HEV), a range-extended electric vehicle (REEV), a plug-in hybrid electric vehicle (PHEV), a new energy vehicle, or a gasoline-powered vehicle.

[0029] Please refer to Figure 2 , Figure 2 This is a schematic diagram of the structure of an on-board ECU software flashing device provided in an embodiment of this application. The on-board ECU software flashing device 20 includes a processor 21 and a memory 22. The processor 21 executes computer programs or instructions stored in the memory 22 to enable the on-board ECU software flashing device 20 to implement the following on-board ECU software flashing method. Exemplarily, the processor 21 typically controls the overall operation of the on-board ECU software flashing device 20, and the memory 22 is configured to store instructions and applications executable by the processor 21.

[0030] In some embodiments, please refer to Figure 2 The vehicle ECU software flashing device 20 also includes a communication interface 23, which enables the vehicle ECU software flashing device 20 to communicate with other terminals or servers via a network. Data can be transmitted between the processor 21, memory 22, and communication interface 23 via bus 24.

[0031] Currently, with the rapid development of automotive electronics technology, the demand for software updates of automotive ECUs (Electronic Control Units) is becoming increasingly frequent. The efficiency, reliability, and compatibility of software programming have become core issues of concern in the industry. In practical applications, automotive ECU software programming mainly relies on manually controlling state machines or using TTB scripts and SDB scripts for process control. These traditional control methods are no longer suitable for the needs of industry development and have many significant drawbacks.

[0032] On the one hand, the pre-processing of the control flow is cumbersome and has extremely low fault tolerance. When using script control, a series of pre-processing operations such as script planning, compilation, and execution must be completed in advance, which not only prolongs the flashing preparation cycle but also raises the operational threshold, requiring a high level of professional skills from the operators. At the same time, the flashing file needs to be reloaded during the application layer implementation, making the file reading stage a critical risk point in the entire flashing process. Once abnormal situations such as file corruption, path errors, or read timeouts occur, the flashing process will be directly interrupted and fail, and there is a lack of effective exception recovery mechanisms, requiring the entire process to be restarted, further increasing the flashing time and failure probability. In addition, the manual control of the state machine is susceptible to human error and non-standard operation, further reducing the stability of the flashing process.

[0033] On the other hand, the flashing efficiency is low and cannot meet the needs of industrial-scale batch flashing. In script control mode, due to the limitations of script parsing mechanism and file transfer logic, file reading efficiency is low and loading speed is slow, resulting in a long overall flashing process and difficulty in improving flashing efficiency. Moreover, the existing method is not optimized for high transmission rate scenarios and cannot fully utilize the transmission capabilities of vehicle communication technology. It is difficult to meet the actual needs of large-scale and rapid ECU software program flashing in industrial production, which restricts the improvement of industrial application efficiency and cannot adapt to the high-efficiency execution requirements of emerging flashing scenarios such as OTA remote flashing and multi-ECU parallel flashing.

[0034] In summary, existing methods for flashing automotive ECU software have significant shortcomings in terms of process stability, execution efficiency, and scenario adaptability. There is an urgent need for a new method for flashing automotive ECU software to address the inherent defects of traditional methods and meet the industry's pressing needs for efficient, reliable, and flexible flashing.

[0035] In one embodiment, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the vehicle ECU software flashing method disclosed in this application. The vehicle ECU software flashing method provided in this application includes: in response to receiving an ECU software flashing request instruction, calling an execution module obtained based on Stateflow transformation, and executing the ECU software flashing process according to the execution module; the execution module includes several serially connected diagnostic units, each diagnostic unit corresponding to a diagnostic service in the ECU flashing process, and the diagnostic unit outputting first identification information or second identification information after executing the corresponding diagnostic service; in response to the diagnostic unit outputting the first identification information, controlling the ECU software flashing process to flow from the current diagnostic unit to the next serially connected diagnostic unit; in response to the diagnostic unit outputting the second identification information, controlling the ECU software flashing process to jump to a preset abnormal termination state and terminating the ECU software flashing process.

[0036] This embodiment directly calls the ECU software flashing process through the execution module transformed by Stateflow, eliminating the pre-planning, compilation, and file reloading steps of traditional script control, shortening the flashing process startup cycle and reducing operational complexity. Furthermore, the execution module is generated based on Stateflow modeling, ensuring a high degree of consistency between the flashing process logic design and execution code, standardizing the calling order and execution criteria of various diagnostic services, and reducing the risk of process chaos. The execution module integrates and connects several diagnostic units, each corresponding to a diagnostic service in the ECU flashing process. No additional service calling logic configuration is required, achieving automated progress of the flashing process and reducing manual intervention costs. The modular design of the diagnostic units facilitates adjustments to service configurations based on different ECU models and flashing scenarios without refactoring the overall process, improving the method's adaptability to various flashing needs and simplifying subsequent process optimization and maintenance. Simultaneously, the diagnostic units output first or second identification information to provide real-time feedback on the execution results of individual diagnostic services, ensuring that the process only proceeds to the next diagnostic unit when the current service is successful, avoiding error accumulation that could lead to flashing failure.

[0037] In some embodiments, the diagnostic unit is configured with service diagnostic identifier parameters, process step index parameters, and process execution status parameters; the service diagnostic identifier parameters are used to obtain the diagnostic service identifier and the diagnostic object identifier; the process step index parameters are used to monitor the operation of the ECU software flashing process, monitor abnormal interruptions, monitor step jumps, and implement step jumps; and the process execution status parameters are used to characterize the status result of the diagnostic service execution.

[0038] The service diagnostic identifier parameter is associated with both the diagnostic service identifier and the diagnostic object identifier, clearly specifying which service to execute and which object to execute it on. This avoids service call confusion or mis-applying to non-target objects, ensuring the accuracy of the flashing operation. By parameterizing the service and object identifiers, no hard-coded logic modifications are required, allowing for flexible adaptation to flashing needs of different diagnostic service types and ECU models, improving the solution's versatility and configuration flexibility. For example, the `en` parameter is used as the service diagnostic identifier parameter. The `en` parameter is used to obtain the `service id` (service ID) and `diagnosisid` (diagnosis ID) of the specific diagnostic service implementation, corresponding to the service type and diagnostic object, respectively. It should be noted that the `en` parameter can be obtained from the Stateflow generation library or directly filled in through the flowchart, improving the overall process operability.

[0039] The process step index parameter covers multi-dimensional monitoring such as running status, abnormal interruption, and step jump, and tracks the progress and node status of the flashing process in real time, making it easy for operators to intuitively grasp the process dynamics and quickly locate the stuck or abnormal position. For example, the du parameter is used as the process step index parameter, that is, the du parameter provides a step index in the process control of vehicle ECU software flashing. This parameter can be used for overall process monitoring, abnormal interruption monitoring, step jump monitoring and implementation, etc. Specifically, starting from step_index[0], the Stateflow process is entered. If the current process conforms to the expected process, a negative or positive response will be received when sending each diagnostic service. The response is used to determine whether to proceed to the next service. If the correct response process that conforms to the expectation is found, step_index is incremented by 1, and the process flows to the subsequent service. Each service is sent based on the correctness of the previous service response. For example, after executing the 0x34 request service, a positive judgment is made. If it conforms, the 0x36 transmission is performed. Furthermore, in the 0x36 file transfer, a file transfer sub-process can be performed, which supports parsing s19, hex, and bin files and transferring them in blocks according to the controller's memory space.

[0040] Process execution status parameters intuitively represent the execution results of diagnostic services, such as success / failure, providing a clear basis for process flow decisions and ensuring that the next stage is only initiated when the current service is completed normally, thus avoiding error accumulation. Standardized status parameter output makes process control logic simpler and clearer, reduces the risk of status judgment errors, and provides precise triggering conditions for abnormal termination mechanisms, further ensuring the safety of the ECU flashing process. For example, the `out_data` parameter is used as the process execution status parameter. The `out_data` parameter provides a basis for process judgment; if the process conforms to the original design goals, the `out_data` parameter is TRUE; otherwise, it is FALSE.

[0041] In addition, the fail_flag parameter provides a way to determine the correctness of the overall process exit. If the ECU software flashing process jumps to a preset abnormal termination state, the fail_flag parameter value is 1, otherwise the fail_flag parameter value is 0. The failure_flag parameter is used to monitor the integrity of the overall process.

[0042] In some embodiments, the execution module is configured with a diagnostic response processing and status feedback function. In response to receiving an ECU software flashing request instruction, the module calls the diagnostic response processing and status feedback function to perform an initial check and returns the initial check result. In response to the initial check passing, the module enters the first diagnostic unit to perform the corresponding diagnostic service. In response to the initial check failing, the module controls the ECU software flashing process to jump to a preset abnormal termination state and terminates the ECU software flashing process.

[0043] In this embodiment, by configuring diagnostic response processing and status feedback functions, an initial check is performed immediately after the flashing request is triggered. This checks basic conditions such as the ECU's online status, communication link stability, and authorization validity in advance, avoiding the initiation of subsequent flashing operations if the initial conditions are not met, thus reducing the risk of flashing failure from the source.

[0044] Furthermore, the initial check logic is encapsulated in a preset function, forming a standardized pre-verification specification. This effectively avoids confusion in the initial check process for different ECU models and flashing scenarios, improving the solution's adaptability to various flashing requirements. The function-based design also makes adjusting the initial check rules more convenient. When new check items need to be added later (such as power supply voltage verification or software version compatibility pre-judgment), only the internal logic of the function needs to be optimized, without refactoring the execution module or diagnostic unit, reducing the solution's iteration and maintenance costs.

[0045] In some embodiments, in response to the ECU software flashing process jumping to a preset abnormal termination state, a preset abnormal handling strategy is executed.

[0046] In the above technical solution, after abnormal termination, a preset processing strategy is triggered, which can quickly perform operations such as ECU reset and exiting the flashing mode, so as to avoid the ECU being in a semi-working state for a long time due to process interruption and prevent irreversible failures such as firmware damage and hardware lock-up.

[0047] For example, when the `fail_flag` parameter is 1, such as in cases of service timeout, verification failure, or voltage abnormality causing the ECU software flashing process to jump to a preset abnormal termination state, triggering an abnormal transfer. It should be noted that this application does not specifically define the service timeout value; it can be determined by specific requirements. Specifically, the abnormal handling operations include: 1) sending a 0x11 service to reset the ECU, forcibly exiting the programming mode; 2) sending a 0x10 service to switch back to the default session, restoring the ECU's basic functions; 3) if the Flash has been erased but the download has not been completed, performing a rollback operation; 4) recording the abnormal log, including the `step_index` abnormal step and the UDS negative response code NRC, for subsequent troubleshooting. After the abnormal handling is completed, the Stateflow jumps to an idle state and indicates that the flashing failed and needs to be retried.

[0048] In some embodiments, the diagnostic unit includes a pre-programming stage diagnostic unit, a main programming stage diagnostic unit, and a post-programming stage diagnostic unit; the pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification diagnostics; the main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics; the post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and flashing record archiving diagnostics.

[0049] In this embodiment, diagnostic units are divided into preparation, execution, and closing stages, with each unit focusing on the core tasks of its corresponding stage. This avoids task confusion between stages and ensures that the flashing process proceeds in a standardized order. Furthermore, each stage's diagnostic unit performs dedicated diagnostic services, such as pre-programmed secure access and main-programmed integrity verification, adapting to the technical requirements of different stages, reducing cross-stage interference, and lowering the risk of flashing failure due to task mixing.

[0050] In some embodiments, the pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification diagnostics, specifically including: In response to receiving an ECU software flashing request command, the ECU wake-up function is called, a wake-up message is sent, and the ECU is woken up. If the ECU wake-up is successful, the process jumps to the extended session entry state. If the ECU wake-up fails, the process jumps to the preset abnormal termination state. In response to entering the extended session entry state, the ECU is switched to extended session mode, and the fault code storage function is disabled. If both switching the ECU to extended session mode and disabling the fault code storage function are successful, the system jumps to the secure access and flashing condition verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the secure access and flashing condition verification state, identity authentication and vehicle status checks are performed. If both identity authentication and vehicle status checks pass, the system jumps to the main programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

[0051] In this embodiment, the step-by-step progressive diagnostic design of the pre-programmed stage diagnostic unit enables closed-loop control of the entire process of ECU flashing, including environmental preparation, mode adaptation, and safety verification. This intercepts the risks of invalid startup and unsafe flashing from the source, providing a foundation for subsequent core flashing processes and improving the overall safety and reliability of the flashing process.

[0052] In some embodiments, the main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics, specifically including: In response to the output of the first identification information by the pre-programming stage diagnostic unit, the ECU is switched to the programming session mode. If the switch to the programming session mode is successful, the system jumps to the Flash memory erase state; otherwise, it jumps to the preset abnormal termination state. In response to entering the Flash memory erase state, the Flash memory erase is performed. If the Flash memory erase is successful, the process jumps to the firmware data block download state; otherwise, it jumps to the preset abnormal termination state. In response to entering the firmware data chunk download state, the flashing tool is deployed and the application is downloaded. If the application download is completed, the process jumps to the integrity verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the integrity verification state, compatibility verification, version accuracy verification, and legality verification are performed. If the verification passes, the process jumps to the post-programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

[0053] In this embodiment, a progressive diagnostic design—including programming session switching, Flash memory erasure, firmware data block download, and integrity verification—is implemented in the main programming phase diagnostic unit. This design achieves precise, secure, and reliable control over the core aspects of ECU software updates, ensuring a defect-free process from deployment to verification and providing core assurance for successful flashing. Furthermore, each step proceeds according to a rigid logic where the previous step must be successful before moving to the next, forming a full-link risk interception system to prevent the accumulation and expansion of errors, ensuring that every operation complies with flashing standards.

[0054] In some embodiments, the post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and flash record archiving diagnostics, specifically including: In response to the first identification information output by the diagnostic unit in the main programming stage, an ECU reset is performed. If the reset is successful, the system configuration recovery state is entered; otherwise, the system is entered into a preset abnormal termination state. In response to entering the system configuration recovery state, the ECU's communication function and fault code storage function are restored. If the recovery operation is completed, it jumps to the flash record archiving state; otherwise, it jumps to the preset abnormal termination state. In response to entering the flashing record archiving state, a flashing report is generated and stored, including the execution results and response messages of the ECU flashing process.

[0055] In this embodiment, the entire process of ECU reset, system configuration restoration, and flashing record archiving by the diagnostic unit in the post-programming stage enables safe ECU activation, system function restoration, and operation traceability after flashing, ensuring the standardization and integrity of the flashing completion process, and further improving the reliability and ease of operation and maintenance of the overall ECU flashing process.

[0056] This application provides a novel diagnostic ECU software flashing control process. Previous ECU software flashing methods typically involved first generating scripts and configuration files, then controlling the process based on the generated scripts. This application eliminates the intermediate script reading step, directly generating static or dynamic libraries that can be directly referenced during use. These libraries are loaded quickly and efficiently when the app runs, and can be used by multiple apps simultaneously, including but not limited to a single app. Based on this, parallel flashing, diagnostics, and flashing can be easily achieved simultaneously according to different needs. It is also applicable to OTA flashing, near-end flashing, host computer flashing, diagnostic tool flashing, and other applications, including but not limited to the above. On one hand, in embedded systems, libraries can be directly generated to provide interfaces for other modules to call; on the other hand, in Windows systems, corresponding reference libraries can be generated according to host computer requirements, or independent modules can be generated to work as needed, ensuring high reliability and efficiency while maintaining high portability.

[0057] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Furthermore, any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory.

[0058] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A method for flashing vehicle ECU software, characterized in that, include: In response to receiving an ECU software flashing request command, the execution module obtained based on Stateflow is invoked, and the ECU software flashing process is executed according to the execution module. The execution module includes several diagnostic units connected in series. Each diagnostic unit corresponds to a diagnostic service in the ECU flashing process. After performing the corresponding diagnostic service, the diagnostic unit outputs first identification information or second identification information. In response to the diagnostic unit outputting the first identification information, the ECU software flashing process is controlled to flow from the current diagnostic unit to the next serially connected diagnostic unit; In response to the diagnostic unit outputting the second identification information, the ECU software flashing process is controlled to jump to a preset abnormal termination state and terminated.

2. The method for flashing vehicle ECU software according to claim 1, characterized in that: The diagnostic unit is configured with service diagnostic identifier parameters, process step index parameters, and process execution status parameters. The diagnostic service identifier and diagnostic object identifier are obtained through the service diagnostic identifier parameter. The operation monitoring, abnormal interruption monitoring, step jump monitoring and step jump implementation of the ECU software flashing process are realized through the process step index parameter. The status result of the diagnostic service execution is characterized through the process execution status parameter.

3. The method for flashing vehicle ECU software according to claim 1, characterized in that: The execution module is configured with a diagnostic response processing and status feedback function. In response to receiving an ECU software flashing request command, it calls the diagnostic response processing and status feedback function to perform an initial check and returns the initial check result. In response to the initial check passing, it enters the first diagnostic unit to perform the corresponding diagnostic service. In response to the initial check failing, it controls the ECU software flashing process to jump to a preset abnormal termination state and terminates the ECU software flashing process.

4. The method for flashing vehicle ECU software according to claim 1, characterized in that: In response to the ECU software flashing process jumping to a preset abnormal termination state, a preset abnormal handling strategy is executed.

5. The method for flashing vehicle ECU software according to claim 1, characterized in that: The diagnostic unit includes a pre-programming stage diagnostic unit, a main programming stage diagnostic unit, and a post-programming stage diagnostic unit. The pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification and diagnosis. The main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics. The post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and record archiving diagnostics.

6. The method for flashing vehicle ECU software according to claim 5, characterized in that, The pre-programming stage diagnostic unit is used to perform ECU wake-up initialization, extended session entry, secure access, and flashing condition verification diagnostics, specifically including: In response to receiving an ECU software flashing request command, the ECU wake-up function is called, a wake-up message is sent, and the ECU is woken up. If the ECU wake-up is successful, the process jumps to the extended session entry state. If the ECU wake-up fails, the process jumps to the preset abnormal termination state. In response to entering the extended session entry state, the ECU is switched to extended session mode, and the fault code storage function is disabled. If both switching the ECU to extended session mode and disabling the fault code storage function are successful, the system jumps to the secure access and flashing condition verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the secure access and flashing condition verification state, identity authentication and vehicle status checks are performed. If both identity authentication and vehicle status checks pass, the system jumps to the main programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

7. The method for flashing vehicle ECU software according to claim 5, characterized in that, The main programming stage diagnostic unit is used to perform programming session switching, Flash memory erasure, firmware data block download, and integrity verification diagnostics, specifically including: In response to the output of the first identification information by the pre-programming stage diagnostic unit, the ECU is switched to the programming session mode. If the switch to the programming session mode is successful, the system jumps to the Flash memory erase state; otherwise, it jumps to the preset abnormal termination state. In response to entering the Flash memory erase state, the Flash memory erase is performed. If the Flash memory erase is successful, the process jumps to the firmware data block download state; otherwise, it jumps to the preset abnormal termination state. In response to entering the firmware data chunk download state, the flashing tool is deployed and the application is downloaded. If the application download is completed, the process jumps to the integrity verification state; otherwise, it jumps to the preset abnormal termination state. In response to entering the integrity verification state, compatibility verification, version accuracy verification, and legality verification are performed. If the verification passes, the process jumps to the post-programming stage diagnostic unit; otherwise, it jumps to the preset abnormal termination state.

8. The method for flashing vehicle ECU software according to claim 5, characterized in that, The post-programming stage diagnostic unit is used to perform ECU reset, system configuration recovery, and flash record archiving diagnostics, specifically including: In response to the first identification information output by the diagnostic unit in the main programming stage, an ECU reset is performed. If the reset is successful, the system configuration recovery state is entered; otherwise, the system is entered into a preset abnormal termination state. In response to entering the system configuration recovery state, the ECU's communication function and fault code storage function are restored. If the recovery operation is completed, it jumps to the flash record archiving state; otherwise, it jumps to the preset abnormal termination state. In response to entering the flashing record archiving state, a flashing report is generated and stored, including the execution results and response messages of the ECU flashing process.

9. A vehicle ECU software flashing device, characterized in that: It includes a processor and a memory, the processor being used to execute computer programs or instructions stored in the memory, so that the vehicle ECU software flashing device implements the vehicle ECU software flashing method as described in any one of claims 1 to 8.

10. A vehicle, characterized in that: Includes the vehicle ECU software flashing device as described in claim 9.

Images