Whole vehicle OTA upgrading method and whole vehicle OTA upgrading module for UDS diagnosis and firmware flashing transmission

Abstract

The invention discloses a UDS diagnosis flash firmware transmission whole vehicle OTA upgrade method, which comprises the following steps: pre-programming flash is carried out, the stage is network preparation work before flash, and the main content comprises the steps of checking upgrade preconditions, improving the flash network speed, forbidding network messages of other ECUs and closing the setting of fault diagnosis codes; the main program flashing step is used for programming one or more logic blocks, and a request message in the step adopts physical addressing; a post-programming flashing step for recovering the CAN network and DTC recording function of the whole vehicle, and a request message in the step adopts physical addressing and functional addressing; and an OTA upgrade data sharing function library in which a multifunctional software interface function is packaged for finishing the OTA flash of the whole vehicle. According to the technical scheme, the common interface is used, module functions are clear in distinguishing, layered design and clear in logic, interface packaging and dynamic library calling modes are adopted, transplantation is convenient, and vehicle model reusability is improved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle networking, and in particular to a UDS diagnostic flash firmware transmission whole vehicle OTA upgrade method and a whole vehicle OTA upgrade module. Background Art

[0002] The whole vehicle OTA upgrade technology is an upgrade of the system firmware. Without changing the vehicle hardware, the vehicle's driving assistance functions, body control, etc. can be remotely upgraded. The UDS flashing is a controller software upgrade based on the application layer protocol and other network layer protocol definitions, such as DOIP flashing under Ethernet communication and diagnostic instrument flashing.

[0003] At present, the firmware transmission protocol is complex, and the interaction is very different, with poor versatility, and different models cannot be reused. The structure is chaotic, the hierarchy is low, and the readability and maintainability are poor. The download, flash, and transmission interactions are unclear, and there is no policy protection for abnormal situations, resulting in a low success rate for flashing. For example, car factory A uses USB communication transmission, and the data format is transmitted according to the CAN communication format. The preconditions are collected and monitored through CAN signals, and some conditions rely on the active reporting of ECU data. For the pre-preparation of OTA upgrades, multiple communication methods have been used, and the transmission protocols are inconsistent, so other models cannot be universal. The overall upgrade process is adapted according to different models. For example, ET models support dual-partition rollback, while BT models do not support dual-partition rollback. The flashing process needs to integrate two sets, and the overall exception handling is not perfect, resulting in flashing failure and the whole vehicle becoming bricked. The flashing process does not have abnormal protection, because the communication method has a small probability of unstable data transmission and data loss. When the data is lost, the main flashing process directly exits without retrying or timeout waiting, resulting in ECU flashing failure and unsafe flashing. When some ECUs do not support USB communication, middleware is required for secondary data transmission, which increases the risk of flash failure. Problem location also requires confirmation of the middleware, which seriously affects the development efficiency and progress of the project. Summary of the invention

[0004] In view of the above-mentioned defects of the prior art, the technical problem to be solved by the present invention is to provide an automobile OTA firmware upgrade method and module with a simple protocol, clear transmission interaction, clear hierarchy, and strong readability and maintainability, so as to improve the success rate of flashing and ensure the handling of abnormal situations.

[0005] To achieve the above object, the present invention provides a UDS diagnostic flash firmware transmission vehicle OTA upgrade method, comprising: Pre-programming flashing: This stage is the network preparation work before flashing. The main contents include checking the upgrade preconditions, improving the flashing network speed, prohibiting network messages from other ECUs and turning off the settings of diagnostic fault codes; The main programming flashing step is used to program one or more logic blocks. The request message of this step adopts physical addressing; The post-programming flashing step is used to restore the vehicle's CAN network and DTC recording functions. The request message of this step uses physical addressing and functional addressing.

[0006] Furthermore, the pre-programming flashing further comprises the following steps: 1) The target ECU enters the default session. The diagnostic device sends a default session request to make the target ECU enter the default session. 2) Read data information. The diagnostic equipment reads the target ECU data information, including but not limited to the hardware version number, ECU part number and software version number. Whether this step is executed or the response content of the target ECU after the reading is executed does not affect the continued execution of the process. 3) The vehicle ECU enters the extended session. The diagnostic device sends an extended session request to make the vehicle ECU enter the extended session. After the message is sent, it needs to be delayed for 1s before executing the subsequent steps. 4) Unlock the security level, and the diagnostic equipment will have secure access to the target ECU. Before this security level is unlocked, the flashing condition detection will not be executed; 5) Flashing condition detection, diagnostic equipment, sending routine control services, and checking whether the target ECU meets the flashing conditions; 6) Prohibit recording of DTCs. The diagnostic device uses functional addressing and DTC setting services to prohibit ECUs in the CAN network from recording DTC functions. 7) Turn off communication. The diagnostic device uses the communication control service to prohibit the ECU in the CAN network from sending and receiving non-diagnostic messages.

[0007] Furthermore, the main programming step includes: 1) The target ECU enters the programming session. The diagnostic device sends a programming session request through physical addressing, so that the target ECU enters the programming session; 2) Unlock the security level. The diagnostic device securely accesses the target ECU through physical addressing. Before the security level is unlocked, the subsequent steps cannot be executed. 3) Write fingerprint information. The diagnostic device writes fingerprint information to the target ECU through physical addressing. The fingerprint information must be stored in the non-volatile memory of the target ECU that is independent of the application program; 4) Flashing Flashdriver, Flashdriver is flashed to the RAM area specified by the target ECU. The flashing sequence consists of three services: request download, data transfer and request transfer exit. The request and positive response of request transfer exit both contain a check value parameter, which is used to verify the integrity of the data. 5) Flashdriver detection: After Flashdriver is flashed, the diagnostic device sends a routine control service through physical addressing to detect whether the downloaded Flashdriver matches the target ECU; 6) Flash the application program. The application program is flashed to the non-volatile memory area specified by the target ECU. The flash sequence consists of four services: erase content, request download, data transfer, and request transfer exit. 7) Application compatibility detection. After the application is flashed, the diagnostic device sends routine control services through physical addressing to detect the integrity and dependencies of the application.

[0008] Furthermore, the post-programming flashing step includes: 1) Enable communication: The diagnostic device uses the communication control service to enable the ECU in the CAN network to send and receive non-diagnostic messages; 2) Restart the target ECU: The diagnostic device uses the reset service through physical addressing to restart the target ECU and jump to the application; 3) Delay: After the target ECU responds positively to the reset service, the diagnostic device should start a 5-second delay timer. When the timer counts up, execute post-programming step 4; 4) Clear the target ECU fault code: The diagnostic device uses the clear fault code service to clear the fault code of the target ECU; 5) Enable DTC recording: The diagnostic device uses the DTC setting service through functional addressing to enable the ECU DTC recording function in the CAN network; 6) The vehicle ECU enters the default session: The diagnostic device sends an extended session request to make the vehicle ECU enter the default session.

[0009] To achieve the above object, the present invention further provides a vehicle OTA upgrade module, which is characterized by comprising: OTA upgrade data sharing function library, in which multifunctional software interface functions are encapsulated to complete the OTA flashing of the entire vehicle; The download module uses TCP communication mode to establish a connection with the OTA server and then downloads the upgrade package from the directory specified by the function library for client authentication and message encryption and decryption; The flashing module controls the ECU end through the main control Tester end, and the communication method adopts a question-and-answer approach. After the upgrade package is successfully downloaded, the upgrade program interface function is provided. Other modules notify the Tester end of the ECU information that needs to be upgraded by calling a unified interface. After the Tester end receives the ECU information, it verifies and processes the information. After the processing is completed, the flashing begins. For the ECU that needs to be flashed, the Tester end controls the ECU end to implement the firmware upgrade through the diagnostic service, and the diagnosis adopts a unified service. The version verification module is used to query the version number in a diagnostic manner after the flashing is completed. The Tester side sends a query command, the ECU side replies with the current version number, and the Tester side performs version verification. After the verification is successful, the Terter side replies with the flashing result, and other modules only need to judge the final result to complete the OTA upgrade of the entire vehicle.

[0010] In this way, the overall flashing success rate is greatly improved, and it is also safer and more reliable.

[0011] Furthermore, when the flashing module does not respond or responds abnormally to the ECU, the Tester performs exception processing.

[0012] Furthermore, the Tester end can proceed to the next step of the process based on the return result of the final judgment interface.

[0013] The technical solution of the present invention provides an automotive OTA firmware upgrade method and module with a simple protocol, clear hierarchy, strong readability and maintainability, thereby improving the success rate of flashing. The technical solution of the present invention uses a public interface, that is, a unified dynamic library is used, and the software interface functions of the required functions are integrated in the dynamic library. The interface functions are provided to other modules as a public interface, so that the module functions can be clearly distinguished, the layered design, and the logic are clear. The interface encapsulation and dynamic library calling methods are adopted to facilitate transplantation and improve the reusability of vehicle models. Exception protection and retry strategies for flashing failures are added to increase the flashing safety performance and the flashing success rate. The diagnostic data flashing method is adopted to facilitate the adaptability of ECUs from different manufacturers.

[0014] The concept, specific structure and technical effects of the present invention will be further described below in conjunction with the accompanying drawings to fully understand the purpose, characteristics and effects of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a flow chart of the pre-programmed flashing steps of a preferred embodiment of the present invention; Figure 2 It is a flow chart of the main programming flashing steps of a preferred embodiment of the present invention; Figure 3It is a flow chart of the post-programming flashing steps of a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0016] The following describes several preferred embodiments of the present invention with reference to the drawings in the specification, so that the technical content is clearer and easier to understand. The present invention can be embodied in many different forms of embodiments, and the protection scope of the present invention is not limited to the embodiments mentioned in the text.

[0017] In the drawings, components with the same structure are indicated by the same numerical reference numerals, and components with similar structures or functions are indicated by similar numerical reference numerals. The size and thickness of each component shown in the drawings are arbitrarily shown, and the present invention does not limit the size and thickness of each component. In order to make the illustration clearer, the thickness of the components is appropriately exaggerated in some places in the drawings.

[0018] The whole vehicle OTA upgrade includes three main modules: download, flash, and version verification. The entire flash task can be completed. The flash method provides the same unified dynamic library, which is a way for Microsoft to implement the concept of shared function library in the Microsoft Windows operating system. The dynamic library encapsulates software interface functions with different functions. Different projects and software only need to integrate the dynamic library to use the required functions. In this way, the flash of the whole vehicle OTA only needs to maintain and develop the same protocol and software. The following is a detailed introduction: 1) Download: The download of the upgrade package of the whole vehicle OTA mainly involves interaction with the server. The interactive method uniformly adopts the TCP communication method. After establishing a connection with the server, the upgrade package is downloaded from the specified directory. TCP communication is a universal and highly secure communication method, and the existing technology is relatively mature, which can achieve compatibility and unification of different models. As long as the server does not change, the function of the download module can be reused all the time. The download module must first establish a connection with the server. We only provide a soft server and client authentication for the module that needs this function. The encryption and decryption of the message do not need to be considered by the other end. The communication connection during the process is uniformly handled by the OTA module, and the other end directly calls the interface and determines whether the returned result is successful, and then proceeds to the next step. This processing makes the OTA function more unified. The download-related program interface is uniformly integrated into a download dynamic library by OTA. No matter what project or module, as long as the relevant interface of the dynamic library needs to be called, the required function can be implemented. This greatly facilitates the portability of the code.

[0019] 2) Flashing: The flashing stage requires a Tester end (main control end) and an ECU end (controlled end). As the number of ECUs required on the vehicle side increases, the Tester end needs to establish communication. The communication method is question-and-answer. The bus of the entire vehicle uniformly uses the CAN bus communication method. Because the CAN bus can interact with all ECUs, a unified method is implemented in terms of communication protocol. The interaction method between the OTA function and the vehicle ECU only requires the development of this program software interface, which greatly reduces the problems that need to be handled separately due to different communication methods between the control end and the controlled end.

[0020] After the upgrade package is downloaded successfully, the OTA module provides the upgrade program interface function. Other modules notify the Tester of the ECU information that needs to be upgraded by calling a unified interface. After the Tester receives the ECU information, it verifies and processes the information. After the processing is completed, the flashing begins.

[0021] For the ECU that needs to be flashed, the Tester side controls the ECU side to implement the firmware upgrade through the diagnostic service, and the diagnosis adopts a unified service. For example, before flashing, it is necessary to switch to the flashing mode. The Tester side only needs to send 10 03 to the ECU side, the flashing switch command. After receiving the command, the ECU side switches the running mode and waits for the flashing action. When it is ready, it replies to the Terster side with a positive response 50 03. After Terster receives the affirmative answer, it continues the security access verification and sends the 27 01 command. The ECU side verifies the information and replies with a positive answer 67 01 after the verification is successful. The secure access ensures the uniqueness of the flashing. Through the well-defined authentication method, it can accurately identify that the flashing is initiated by the Tester side, thus preventing other modules or other ECUs from sending the wrong message, resulting in abnormalities such as tampering of ECU information or misoperation. After the secure access is passed, the Tester starts to send 36 data transmission instructions, 37 data transmission is completed, the ECU side receives the received data, verifies the data integrity, and completes the upgrade flashing action.

[0022] Because the overall communication method adopts the form of question and answer, when the other party does not respond or replies abnormally, Terster performs exception handling. The processing during the flashing process does not need to be considered by the module that calls this interface. OTA handles it uniformly, so that all flashing processes and exception handling are integrated in the OTA module, which greatly improves the stability of flashing. The ECU that needs to be upgraded only needs to call the interface function provided by OTA to complete the flashing. The calling end finally determines the return result of the interface and proceeds to the next step.

[0023] 3) Version verification: After the flashing is completed, the version number is still queried in a diagnostic manner. The Tester sends a 22 query command, the ECU replies with the current version number, and the Tester performs version verification. After the verification is successful, the Terter replies with the flashing result, and other modules only need to judge the final result to complete the OTA upgrade of the entire vehicle.

[0024] In this way, the overall flashing success rate is greatly improved, and it is also safer and more reliable.

[0025] like Figure 1 Pre-programming flashing steps shown: This stage is the network preparation work before flashing, which mainly includes checking the upgrade prerequisites, increasing the flashing network speed, prohibiting network messages from other ECUs and turning off the DTC (Diagnostic Trouble Code) diagnostic fault code settings.

[0026] 1) The target ECU enters the default session: The diagnostic device sends a default session request ($10 01) to make the target ECU enter the default session.

[0027] 2) Read data information: The diagnostic device reads the target ECU data information ($22), including but not limited to: hardware version number, ECU part number, software version number; whether this step is executed or not, or the response content of the target ECU after the reading (affirmative response or negative response), does not affect the continued execution of the process.

[0028] 3) The vehicle ECU enters the extended session: The diagnostic device sends an extended session request ($10 83) to make the vehicle ECU enter the extended session. After the message is sent, it takes 1 second to execute the subsequent steps.

[0029] 4) Unlock security level: The diagnostic equipment has secure access to the target ECU ($27 01 / 02). Before this security level is unlocked, Flash condition detection will not be performed; 5) Flashing condition detection: Diagnostic equipment, send routine control service ($31 01 02 03) to check whether the target ECU meets the flashing conditions.

[0030] 6) Disable DTC recording: The diagnostic device uses functional addressing and the DTC setting service ($85 82) to disable the ECU in the CAN network from recording the DTC function.

[0031] 7) Turn off communication: The diagnostic device uses the communication control service ($28 83 01 and $28 83 03) to prohibit the ECU in the CAN network from sending and receiving non-diagnostic messages.

[0032] Add abnormal protection and retry strategy for flash failure to increase flash safety performance and flash success rate. Use diagnostic data flashing method to facilitate the adaptability of ECUs from different manufacturers.

[0033] like Figure 2 As shown, the main programming steps are: The main programming step is used to program one or more logic blocks. The request message of this step uses physical addressing (P: physical addressing). Process step description 1) The target ECU enters the programming session: The diagnostic device sends a programming session request ($10 02) through physical addressing to make the target ECU enter the programming session; 2) Unlock security level: The diagnostic device securely accesses the target ECU through physical addressing ($27 09 / 0A). Subsequent steps cannot be performed before this security level is unlocked; 3) Write fingerprint information: The diagnostic device writes fingerprint information to the target ECU ($2E F1 84) through physical addressing. The fingerprint information must be stored in the non-volatile memory of the target ECU that is independent of the application program; 4) Flashing Flashdriver (driver): Flashdriver is flashed to the RAM area specified by the target ECU. The flashing sequence consists of three services: request download ($34), data transfer ($36) and request transfer exit ($37); the request and positive response of request transfer exit ($37) both contain a checksum parameter. The checksum is used to verify the integrity of the data. 5) Flashdriver detection: After Flashdriver flashing is completed, the diagnostic device sends a routine control service ($31 01 02 02) through physical addressing to detect whether the downloaded Flashdriver matches the target ECU; 6) Flashing application: The application is flashed to the non-volatile memory area specified by the target ECU; the flashing sequence consists of four services: erase content ($31 01 FF 00), request download ($34), data transfer ($36) and request transfer exit ($37).

[0034] 7) Application compatibility detection: After the application is flashed, the diagnostic device sends a routine control service ($31 01 FF 01) through physical addressing to detect the integrity and dependencies of the application.

[0035] Add abnormal protection and retry strategy for flash failure to increase flash safety performance and flash success rate. Use diagnostic data flashing method to facilitate the adaptability of ECUs from different manufacturers.

[0036] like Figure 3 As shown, the post-programming flash process The post-programming step is mainly used to restore the vehicle CAN network and DTC (Diagnostic Trouble Code) recording function. The request message of this step uses physical addressing and functional addressing (P: physical addressing, F: functional addressing).

[0037] Enable communication: The diagnostic device uses the communication control services ($28 80 01 and $28 80 03) to enable the ECU in the CAN network to send and receive non-diagnostic messages.

[0038] 2) Restart the target ECU: The diagnostic device uses the reset service ($11 01) through physical addressing to restart the target ECU and jump to the application.

[0039] 3) Delay: After the target ECU feedbacks a positive response to the reset service, the diagnostic equipment should start a 5-second delay timer. When the timer counts up, execute post-programming step 4.

[0040] 4) Clear the target ECU fault code: The diagnostic equipment uses the Clear Fault Code service ($14) to clear the fault code of the target ECU.

[0041] 5) Enable DTC recording: The diagnostic device uses functional addressing and the DTC setting service ($85 81) to enable the ECU in the CAN network to record DTCs.

[0042] 6) The vehicle ECU enters the default session: The diagnostic device sends an extended session request ($10 81) to make the vehicle ECU enter the default session.

[0043] Physical addressing is a point-to-point communication method that allows diagnostic equipment to communicate directly with a specific ECU (electronic control unit). This method is direct and fast, and is suitable for situations where detailed diagnosis or data exchange with a specific ECU is required. For example, when the fault code of a specific ECU needs to be read or cleared, physical addressing can ensure that only the target ECU responds to the request.

[0044] Functional addressing is a one-to-many communication method that allows diagnostic equipment to broadcast requests and have all ECUs that support specific functions or services respond. This method is suitable for scenarios where communication with multiple ECUs is required, such as requesting all ECUs to report their status or perform the same diagnostic tasks. Functional addressing can improve diagnostic efficiency because it can send requests to multiple ECUs at one time and collect their responses.

[0045] The benefits of using both physical and functional addressing include: the ability to select the most appropriate addressing method based on diagnostic needs, whether it is detailed diagnosis of a single ECU or batch operations on multiple ECUs. When the same operation needs to be performed on multiple ECUs, functional addressing can reduce the number of communications and improve the efficiency of the diagnostic process. Physical addressing ensures that only the target ECU responds to the request, reducing the possibility of misoperation and improving the accuracy of diagnosis. Different ECUs may support different addressing methods, and using both addressing methods can ensure compatibility with a variety of ECUs. In a complex automotive network, there may be multiple ECUs and different network levels, and the combined use of physical and functional addressing can better adapt to this complexity.

[0046] In general, the combined use of physical addressing and functional addressing can improve the flexibility, efficiency and accuracy of automobile diagnosis, and is an indispensable part of automobile diagnostic communication protocol.

[0047] The technical solution of the present invention uses a common interface, that is, a unified dynamic library as a common interface, so that the module functions are clearly distinguished, the layered design is clear, and the logic is clear. The unified interface encapsulation and dynamic library calling method are adopted to facilitate transplantation and improve vehicle model reusability. Exception protection and retry strategies for flash failure are added to increase flash safety performance and flash success rate. The diagnostic data flashing method is adopted to facilitate the adaptability of ECUs from different manufacturers.

[0048] The preferred specific embodiments of the present invention are described in detail above. It should be understood that ordinary technicians in the field can make many modifications and changes based on the concept of the present invention without creative work. Therefore, all technical solutions that can be obtained by technicians in the technical field based on the concept of the present invention through logical analysis, reasoning or limited experiments on the basis of the prior art should be within the scope of protection determined by the claims.

Claims

1. A UDS diagnostic flash firmware transmission vehicle OTA upgrade method, characterized in that: include: Pre-programming flashing: This stage is the network preparation work before flashing. The main contents include checking the upgrade preconditions, improving the flashing network speed, prohibiting network messages from other ECUs and turning off the settings of diagnostic fault codes; The main programming flashing step is used to program one or more logic blocks. The request message of this step adopts physical addressing; The post-programming flashing step is used to restore the vehicle's CAN network and DTC recording functions. The request message of this step uses physical addressing and functional addressing.

2. The method according to claim 1, characterized in that: The pre-programming flashing also includes the following steps: 1) The target ECU enters the default session. The diagnostic device sends a default session request to make the target ECU enter the default session. 2) Read data information. The diagnostic equipment reads the target ECU data information, including but not limited to the hardware version number, ECU part number and software version number. Whether this step is executed or the response content of the target ECU after the reading is executed does not affect the continued execution of the process. 3) The vehicle ECU enters the extended session. The diagnostic device sends an extended session request to make the vehicle ECU enter the extended session. After the message is sent, it needs to be delayed for 1s before executing the subsequent steps. 4) Unlock the security level, and the diagnostic equipment will have secure access to the target ECU. Before this security level is unlocked, the flashing condition detection will not be executed; 5) Flashing condition detection, diagnostic equipment, sending routine control services, and checking whether the target ECU meets the flashing conditions; 6) Prohibit recording of DTCs. The diagnostic device uses functional addressing and DTC setting services to prohibit ECUs in the CAN network from recording DTC functions. 7) Turn off communication. The diagnostic device uses the communication control service to prohibit the ECU in the CAN network from sending and receiving non-diagnostic messages.

3. The method according to claim 1, wherein: The main programming steps include: 1) The target ECU enters the programming session. The diagnostic device sends a programming session request through physical addressing, so that the target ECU enters the programming session; 2) Unlock the security level. The diagnostic device securely accesses the target ECU through physical addressing. Before the security level is unlocked, the subsequent steps cannot be executed. 3) Write fingerprint information. The diagnostic device writes fingerprint information to the target ECU through physical addressing. The fingerprint information must be stored in the non-volatile memory of the target ECU that is independent of the application program; 4) Flashing Flashdriver, Flashdriver is flashed to the RAM area specified by the target ECU; the flashing sequence consists of three services: request download, data transfer and request transfer exit; the request and positive response of request transfer exit both contain a check value parameter, which is used to verify the integrity of the data; 5) Flashdriver detection: After Flashdriver is flashed, the diagnostic device sends a routine control service through physical addressing to detect whether the downloaded Flashdriver matches the target ECU; 6) Flash the application program. The application program is flashed to the non-volatile memory area specified by the target ECU. The flash sequence consists of four services: erase content, request download, data transfer, and request transfer exit. 7) Application compatibility detection. After the application is flashed, the diagnostic device sends routine control services through physical addressing to detect the integrity and dependencies of the application.

4. The method according to claim 1, wherein: The post-programming flashing step includes: 1) Enable communication: The diagnostic device uses the communication control service to enable the ECU in the CAN network to send and receive non-diagnostic messages; 2) Restart the target ECU: The diagnostic device uses the reset service through physical addressing to restart the target ECU and jump to the application; 3) Delay: After the target ECU responds positively to the reset service, the diagnostic device should start a 5-second delay timer. When the timer counts up, execute post-programming step 4; 4) Clear the target ECU fault code: The diagnostic device uses the clear fault code service to clear the fault code of the target ECU; 5) Enable DTC recording: The diagnostic device uses DTC setting service through functional addressing to enable the ECU DTC recording function in the CAN network; 6) The vehicle ECU enters the default session: The diagnostic device sends an extended session request to make the vehicle ECU enter the default session.

5. A vehicle OTA upgrade module, characterized in that: include: OTA upgrade data sharing function library, in which multifunctional software interface functions are encapsulated to complete the OTA flashing of the entire vehicle; The download module uses TCP communication mode to establish a connection with the OTA server and then downloads the upgrade package from the directory specified by the function library for client authentication and message encryption and decryption; The flashing module controls the ECU end through the main control Tester end, and the communication method adopts a question-and-answer approach. After the upgrade package is successfully downloaded, the upgrade program interface function is provided. Other modules notify the Tester end of the ECU information that needs to be upgraded by calling a unified interface. After the Tester end receives the ECU information, it verifies and processes the information. After the processing is completed, the flashing begins. For the ECU that needs to be flashed, the Tester end controls the ECU end to implement the firmware upgrade through the diagnostic service, and the diagnosis adopts a unified service. The version verification module is used to query the version number in a diagnostic manner after the flashing is completed. The Tester sends a query command, the ECU replies with the current version number, and the Tester performs version verification. After the verification is successful, the Terter replies with the flashing result, while other modules only need to judge the final result to complete the OTA upgrade of the entire vehicle; In this way, the overall flashing success rate is greatly improved, and it is also safer and more reliable.

6. The module according to claim 5, characterized in that The flashing module performs exception handling on the Tester side when the ECU side does not respond or responds abnormally.

7. The module according to claim 6, characterized in that The Tester end finally determines the return result of the interface and can proceed to the next step.

Images