A method and system for dynamically configuring a UDS diagnosis flashing sequence for vehicle remote OTA upgrading

Abstract

This invention discloses a dynamic configuration design method and system for UDS diagnostic flashing sequences in vehicle remote OTA upgrades. The method includes: Step S1, the OTA server responds to the upgrade request and collects the hardware parameters, software information, communication parameters, and vehicle status of the target electronic control unit (ECU) through an onboard T-BOX; Step S2, a dynamic configuration model is constructed; Step S3, the dynamic configuration model calls a basic step template based on the collected information, matches and fills in the execution parameters, optimizes the transmission parameters, and generates a personalized UDS flashing sequence; Step S4, the onboard T-BOX executes the flashing sequence and monitors for anomalies in real time, dynamically adjusting the flashing parameters or executing a retry process; Step S5, the OTA server collects upgrade logs and optimizes and iterates the dynamic configuration model through big data analysis. This invention solves the problems of poor adaptability, low efficiency, and high failure risk in existing technologies, and can dynamically adjust the flashing sequence according to ECU characteristics, network status, and abnormal conditions.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronics technology, specifically relating to a dynamic configuration design method and system for UDS diagnostic flashing sequence for remote OTA upgrades of vehicles. Background Technology

[0002] With the increasing electrification and intelligence of automobiles, the number of Electronic Control Units (ECUs) in vehicles is constantly increasing, and their functions are becoming increasingly complex. Remote Over-The-Air (OTA) upgrade technology, as a key means to achieve vehicle function iteration and fault repair, has become one of the core technologies of intelligent vehicles. During the OTA upgrade process, communication with the ECU is established through the Unified Diagnostic Service (UDS) to complete software download, verification, flashing, and activation operations. The rationality of the UDS diagnostic flashing sequence directly determines the efficiency and safety of the upgrade.

[0003] Publication No. (CN119960803A) discloses a method and apparatus for remote ECU diagnostic flashing. This solution parses the vehicle-side upgrade package using a pre-set upgrade package parsing tool to obtain an initial diagnostic flashing sequence. It then generates diagnostic flashing instructions using a pre-set diagnostic flashing sequence template and determines the wildcards required for flashing the vehicle-side ECU based on the initial diagnostic flashing sequence and the vehicle-side ECU's flashing requirements, thereby generating a diagnostic flashing sequence file to achieve diagnostic flashing of the vehicle-side ECU. This solution, by introducing a diagnostic flashing sequence template to generate diagnostic instructions, can dynamically generate corresponding flashing sequence information according to the actual upgrade requirements of the vehicle-side ECU. Furthermore, by adding wildcards to the diagnostic flashing sequence file to adapt to different types of diagnostic specifications, it improves the efficiency of remote ECU diagnostic flashing to a certain extent.

[0004] However, the aforementioned existing technologies still have the following shortcomings: First, they lack adaptability. Their dynamic generation mainly relies on preset templates and wildcard replacement, failing to fully consider the differences in ECU hardware parameters such as chip type and memory capacity, making it difficult to meet the personalized needs of ECUs from different manufacturers and models. Second, they lack a dynamic adjustment mechanism for real-time network status, failing to consider the impact of factors such as vehicle network signal strength and CAN bus load rate on data transmission. When network bandwidth is insufficient or bus load is too high, data is still transmitted according to a fixed strategy, which may lead to excessively long upgrade times or failures. Third, the anomaly handling mechanism is relatively simple. Although it has basic flashing process control, it lacks dynamic adjustment strategies for various anomaly scenarios such as communication timeouts, security access failures, and verification errors. It cannot adjust flashing parameters or switch security levels in real time when anomalies occur, posing a risk of ECU bricking. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a dynamic configuration design method and system for UDS diagnostic flashing sequence for remote OTA upgrades of vehicles. It can dynamically generate and adjust the UDS diagnostic flashing sequence according to ECU hardware parameters, software information, vehicle network status and abnormal conditions, thereby improving the compatibility, efficiency and security of OTA upgrades.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A method for dynamically configuring UDS diagnostic flashing sequences for remote OTA upgrades of vehicles includes the following steps: Step S1: In response to the vehicle's upgrade request, the OTA server collects key information of the target electronic control unit (ECU) through the vehicle-mounted telematics processor T-BOX. This key information includes hardware parameters, software information, communication parameters, and vehicle status. Step S2: Construct a dynamic configuration model for UDS writing sequences, including a sequence template library, a parameter matching engine, a dynamic adjustment module, and an exception handling sub-module; Step S3: Based on the key information collected in Step S1, the dynamic configuration model calls the basic step template in the sequence template library, matches and fills the execution parameters of each step through the parameter matching engine, and the dynamic adjustment module optimizes the transmission parameters according to the real-time vehicle status to generate a personalized UDS writing sequence. Step S4: The vehicle-mounted remote information processor T-BOX executes the personalized UDS flashing sequence, and during the execution process, it monitors abnormal situations in real time through the exception handling submodule, dynamically adjusts the flashing parameters or executes the retry process. Step S5: The OTA server collects upgrade logs and optimizes and iterates the dynamic configuration model through big data analysis.

[0007] Furthermore, the key information collected in step S1 specifically includes: hardware parameters such as ECU model, chip type, memory capacity, and Flash storage size; software information such as current software version, software version to be upgraded, and software verification algorithm; communication parameters such as supported UDS session type, security access level, and CAN / LIN bus baud rate; and vehicle status such as current voltage, network signal strength, packet loss rate, and bus load rate.

[0008] Furthermore, the sequence template library pre-stores general UDS flashing step templates, including seven basic step templates: "session switching, secure access, data clearing, software transfer, verification, flashing activation, and session exit." Each step has a reserved parameter configuration interface. The parameter matching engine automatically matches key parameters for each step based on the hardware parameters and software information of the electronic control unit (ECU), including the secure access key algorithm, data block size, and transmission rate. The dynamic adjustment module dynamically adjusts the data transmission rate and retransmission mechanism based on the real-time network signal strength and bus load rate. The exception handling submodule presets exception scenarios and corresponding adjustment strategies, responding to and handling exceptions in real time during the flashing process.

[0009] Furthermore, the matching rules of the parameter matching engine include: configuring the data block size according to the memory capacity; if the memory capacity is less than the first threshold, it is configured as the first data block value; if the memory capacity is greater than or equal to the second threshold, it is configured as the second data block value; and according to the degree of difference between the software version to be upgraded and the current software version, if the difference exceeds the preset number of versions, a "software partition backup" step is added.

[0010] Furthermore, the adjustment rules of the dynamic adjustment module include: when the network signal strength is lower than the first signal threshold or the bus load rate is higher than the first load threshold, reducing the data transmission rate and adding a data retransmission mechanism; when the network signal strength is higher than the second signal threshold and the bus load rate is lower than the second load threshold, increasing the data transmission rate to the preset maximum value.

[0011] Furthermore, the adjustment strategy of the exception handling submodule includes: if multiple consecutive security access requests time out, automatically switch the security access level and extend the waiting time; if software verification fails, trigger the retry process of "data retransmission, secondary verification, and hardware reset".

[0012] Furthermore, the specific process of generating a personalized UDS flashing sequence in step S3 includes: calling a basic step template from the sequence template library and removing steps that are not supported by the ECU; filling specific parameters for each step through the parameter matching engine to generate an operation sequence containing "instruction code, parameter value, execution timeout, and number of retries"; the dynamic adjustment module performs final optimization of the parameters of the data transmission steps based on the real-time vehicle status to generate an executable flashing sequence file, and transmits it to the vehicle remote information processor T-BOX through an encrypted channel.

[0013] Furthermore, the specific execution and monitoring process in step S4 includes: sending a session switching command to the target electronic control unit (ECU) to enter the programming session; executing a secure access process and completing identity authentication through a parameter-matching key algorithm; transmitting software data at a dynamically adjusted rate while simultaneously collecting ECU feedback information in real time; the anomaly handling submodule monitors the execution process in real time, and if an anomaly is detected, immediately triggering a preset adjustment strategy; after completing the software flashing, executing an activation command and switching back to the default session, and sending the upgrade result back to the OTA server.

[0014] Furthermore, the specific process of optimization iteration in step S5 includes: if the failure rate of flashing a certain type of electronic control unit (ECU) exceeds the preset failure rate threshold, analyze the reasons for failure and update the sequence template library or parameter matching rules; optimize the transmission rate threshold of the dynamically adjusted module based on network status data in different regions; and synchronize the optimized model to all OTA server nodes to achieve continuous iteration of flashing sequence configuration capabilities.

[0015] The present invention also provides a UDS diagnostic flashing sequence dynamic configuration system for remote OTA upgrade of vehicles, including: an OTA server, an in-vehicle telematics processor T-BOX, and an electronic control unit (ECU).

[0016] Compared with traditional solutions, the present invention has the following advantages: (1) This invention generates a personalized flashing sequence by dynamically matching ECU hardware parameters and software information, which is compatible with ECUs from different manufacturers and models, thus solving the problem of poor compatibility of fixed sequences.

[0017] (2) The present invention dynamically adjusts the data transmission rate based on real-time network signal strength and bus load rate, thus avoiding resource waste or transmission bottlenecks under fixed rate.

[0018] (3) The system built-in anomaly handling submodule and real-time monitoring mechanism provided by this invention can quickly respond to faults during the flashing process and reduce the risk of ECU bricking. By setting adjustment strategies for abnormal scenarios, such as automatically switching levels when security access times out and triggering retry processes when verification fails, the reliability of the flashing process is ensured. At the same time, the confidentiality and integrity of the upgrade process are ensured through encrypted transmission and secure access.

[0019] (4) The dynamic adjustment module of the present invention optimizes the transmission parameters according to the real-time network status, avoiding data loss and retransmission caused by blindly transmitting at high speed when the network condition is poor, and also avoiding resource waste caused by excessively low transmission rate when the network condition is good. Attached Figure Description

[0020] This manual includes the following figures, which illustrate the following: Figure 1This is an overall flowchart of the UDS diagnostic brushing sequence dynamic configuration method provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the module structure of the UDS brushing sequence dynamic configuration model provided in an embodiment of the present invention. Detailed Implementation

[0021] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, in order to help those skilled in the art to have a more complete, accurate and in-depth understanding of the inventive concept and technical solution of the present invention, and to facilitate its implementation.

[0022] This invention provides a dynamic configuration system for UDS diagnostic flashing sequences in remote OTA (Over-The-Air) upgrades for vehicles, mainly comprising an OTA server, an in-vehicle telematics processor (T-BOX), and electronic control units (ECUs). The OTA server deploys an information acquisition module, a dynamic configuration model construction module, a personalized sequence generation module, and an optimization iteration module. The OTA server establishes a connection with the in-vehicle T-BOX via a mobile communication network, receiving upgrade requests, sending flashing sequence files, and collecting upgrade logs. The in-vehicle T-BOX internally deploys an execution monitoring module. The in-vehicle T-BOX connects to each ECU via the in-vehicle CAN / LIN bus, receiving the flashing sequence files from the OTA server, parsing them, sending UDS diagnostic commands to the target ECU via the bus, and collecting feedback information from the ECU in real time. The ECU receives the UDS commands sent by the T-BOX via the CAN / LIN bus, executes the corresponding flashing operation, and returns the execution result via the bus.

[0023] The information acquisition module communicates with the Electronic Control Unit (ECU) via the vehicle-mounted T-BOX, collecting key information and storing it in the ECU information database. The dynamic configuration model construction module builds a configuration model based on the information in the database, including a sequence template library, a parameter matching engine, a dynamic adjustment unit, and an exception handling unit. The personalized sequence generation module calls the configuration model to generate a personalized flashing sequence file and sends it to the vehicle-mounted T-BOX through an encrypted channel. The execution monitoring module parses and executes the flashing sequence, interacts with the ECU via the bus, and monitors the execution process in real time. When an exception is encountered, the preset strategy of the exception handling unit is triggered. After execution, the vehicle-mounted T-BOX uploads the upgrade log to the OTA server. The optimization iteration module performs big data analysis on the log, optimizes the parameters of the configuration model accordingly, and synchronizes the optimized model to all server nodes.

[0024] like Figure 1 As shown, this invention provides a dynamic configuration design method for UDS diagnostic flashing sequence for remote OTA upgrades of vehicles, which includes the following five core steps.

[0025] Step S1: When the user confirms the upgrade via the in-vehicle central control screen, or when the OTA server actively pushes the upgrade task, the vehicle sends an upgrade request to the OTA server. After receiving the request, the OTA server establishes communication with the target ECU through the in-vehicle T-BOX and collects key information. This information includes: hardware parameters, software information, communication parameters, and vehicle status.

[0026] Hardware parameters include ECU model, chip type, memory capacity, and Flash storage size. These parameters determine key configurations such as data block size and memory partitioning strategy. Software information includes the current software version, the software version to be upgraded, and the software verification algorithm. The degree of version difference determines whether a software partition backup step is required, and the verification algorithm determines the verification method after data transmission is completed. Communication parameters include supported UDS session types, security access levels, and CAN / LIN bus baud rates. These parameters determine the specific implementation of session switching commands and secure access procedures. Vehicle status includes current voltage, network signal strength, packet loss rate, and bus load rate. These real-time status parameters are used to dynamically adjust the transmission strategy.

[0027] The collected information is stored in the Electronic Control Unit (ECU) information database. Each record contains the vehicle VIN code, ECU identifier, collection timestamp, and the above parameters, providing data support for subsequent sequence configuration.

[0028] Step S2: Based on the information collected in Step S1, a dynamic configuration model is constructed on the OTA server. This model consists of four core modules: a sequence template library, a parameter matching engine, a dynamic adjustment module, and an exception handling submodule.

[0029] The sequence template library pre-stores general UDS flashing step templates. In this embodiment, the template includes seven basic steps: "session switching, secure access, data clearing, software transfer, verification, flashing activation, and session exit." Each step template provides a parameter configuration interface; for example, the secure access step can be configured with key algorithm, timeout, and number of retries; the software transfer step can be configured with data block size, transfer rate, and retransmission mechanism. The template library supports dynamic expansion; when new electronic control units (ECUs) have new flashing requirements, new step templates can be added to the template library.

[0030] The parameter matching engine automatically matches key parameters for each step based on the ECU's hardware and software information. The parameter matching engine has a built-in matching rule library, including: Data block size matching rules: If the memory capacity of the Electronic Control Unit (ECU) is less than the first threshold of 512KB, the data block size is configured to 1KB; if the memory capacity is greater than or equal to the second threshold of 1GB, it is configured to 32KB; if the memory capacity is between 512KB and 1GB, the data block size is configured to 4KB. This rule ensures that the data block size does not exceed the processing capacity of the ECU, avoiding memory overflow.

[0031] Security access algorithm matching rules: Match the corresponding key algorithm according to the security access level supported by the ECU. For example, level 2 matches AES-128, and level 3 matches RSA-2048.

[0032] Version difference judgment rule: If the software version to be upgraded differs from the current version by more than 3 iterations, a "software partition backup" step will be automatically added so that the old version can be rolled back in case of flashing failure, preventing the electronic control unit (ECU) from becoming bricked.

[0033] The dynamic adjustment module collects real-time vehicle network status and bus load rate, and dynamically adjusts data transmission parameters. The module has a built-in adjustment rule base. When the network signal strength is below the first signal threshold of -90dBm or the bus load rate is above the first load threshold of 70%, the network condition is considered poor, and the data transmission rate is reduced to 200KB / s. A data retransmission mechanism is added, with each data block retransmitted a maximum of 3 times. When the network signal strength is above the second signal threshold of -70dBm and the bus load rate is below the second load threshold of 30%, the network condition is considered good, and the transmission rate is increased to the maximum value of 1MB / s. When the network signal strength is between the first signal threshold of -90dBm and the second signal threshold of -70dBm, or the bus load rate is between 30% of the second load threshold and 70% of the first load threshold, a medium transmission rate, such as 300KB / s-400KB / s, is used.

[0034] The exception handling submodule pre-defines various exception scenarios and corresponding adjustment strategies. The exception handling submodule has a built-in exception strategy library, including: Communication timeout error: If three consecutive security access requests time out, the security access level will be automatically switched, such as from level 2 to level 3, and the waiting time will be extended from 200ms to 500ms.

[0035] Verification failure exception: If software verification fails, a retry process of "data retransmission, secondary verification, hardware reset" is triggered. That is, the data is retransmitted first, and then verified again. If it still fails, the ECU hardware is reset. After the reset, the session is re-established and continues.

[0036] Abnormal voltage fluctuation: If the vehicle voltage is detected to be below 11V, the flashing process will be paused, the current breakpoint position will be saved, and the transmission will continue from the breakpoint after the voltage is restored.

[0037] ECU Reset Abnormality: If an ECU reset is detected, the communication session will be automatically re-established and transmission will continue from the point of interruption to avoid starting from the beginning.

[0038] Step S3: The dynamic configuration model generates a personalized flashing sequence based on the ECU information collected in Step S1 and the parameter matching results in Step S2. It calls seven basic step templates from the sequence template library: "Session Switching, Secure Access, Data Clearing, Software Transfer, Verification, Flashing Activation, and Session Exit." Based on the ECU information, unsupported steps are removed. For example, if the ECU supports fast flashing without data clearing, the "Data Clearing" step is removed; if the version difference is minor and backup is not required, the "Software Partition Backup" step is not added.

[0039] The parameter matching engine populates specific parameters for each step. For example, the secure access step is populated with "Key Algorithm: AES-128", "Timeout: 200ms", and "Number of Retryes: 3"; the software transmission step is populated with "Block Size: 4KB", "Transmission Rate: 300KB / s", "Timeout per Block: 300ms", and "Number of Retryes per Block: 3". The dynamic adjustment module performs final optimization of the parameters for the data transmission steps based on the real-time vehicle status. For example, if the current signal strength is -85dBm, the transmission rate will be adjusted from 300KB / s to 250KB / s. A flashing sequence file containing detailed instructions is generated, with each instruction including fields such as "UDS Service ID, Instruction Code, Parameter Value, Execution Timeout, and Number of Retryes". The sequence file uses JSON or XML format for easy parsing and expansion. After generation, it is transmitted to the vehicle-mounted T-BOX via an encrypted channel, such as TLS / SSL.

[0040] Step S4: After receiving the flashing sequence file, the vehicle-mounted T-BOX sends the UDS service 0x10 command with parameter 0x02 to the target electronic control unit (ECU) to enter the programming session mode. After the ECU returns a positive response, proceed to the next step.

[0041] Send the UDS service command 0x27 to complete authentication based on the key algorithm configured in the sequence file, such as AES-128. First, send the seed request command 0x27 0x01, and the ECU returns the seed value. The vehicle T-BOX calculates the key according to the key algorithm and sends the key command 0x27 0x02. After the electronic control unit (ECU) verifies the key, it returns a positive response.

[0042] Send the UDS service command 0x31 with parameter 0x01 to clear the specified area in Flash, preparing it for writing new software.

[0043] The UDS service 0x36 command is sent cyclically according to the rate and data block size configured in the sequence file. After each data block is sent, a positive response is awaited from the ECU. If no response is received within a timeout period, the data is retransmitted according to the configured number of retries.

[0044] During execution, the exception handling submodule monitors the ECU feedback information in real time. If an exception is detected, such as consecutive timeouts or verification failures, a preset adjustment strategy is immediately triggered. For example, if the 1200th data transmission times out, a retry process is triggered, and the second retransmission is successful; if the bus load rate rises to 65%, the dynamic adjustment module automatically reduces the transmission rate from 250KB / s to 200KB / s.

[0045] After all data blocks have been transferred, the UDS service command 0x37 is sent for software verification. The electronic control unit (ECU) calculates the verification value and compares it with the verification value on the server, returning the verification result. If the verification passes, the UDS service command 0x31 is sent to activate the software. The new software takes effect after the ECU is reset.

[0046] Finally, the UDS service command 0x10 is sent to switch back to the default session and the upgrade result is reported back to the OTA server.

[0047] Step S5: The OTA server collects upgrade logs from each vehicle, establishes a big data analysis platform, and continuously optimizes the dynamic configuration model. If the failure rate of flashing a certain model of ECU exceeds a preset threshold, such as 5%, the system automatically triggers the analysis process to deeply analyze the reasons for failure, such as unreasonable parameter matching, insufficient anomaly handling strategies, improper threshold settings, etc., and updates the sequence template library or parameter matching rules accordingly.

[0048] The OTA server optimizes and dynamically adjusts the module's transmission rate threshold based on network status statistics for different regions. For example, in mountainous areas where network signals are generally poor, the signal strength threshold for "poor network conditions" is adjusted from -90dBm to -85dBm, allowing the system to enter low-rate protection mode earlier.

[0049] The system will synchronize the optimized model parameters and rule base to all OTA server nodes, enabling continuous iteration of the flashing sequence configuration capability. As upgrade data accumulates, the system's configuration accuracy and flashing success rate will continuously improve.

[0050] Example 1: Remote OTA upgrade of MCU for a certain brand of new energy vehicle This embodiment uses the remote OTA upgrade of the motor controller MCU of a certain brand of new energy vehicle as an example to explain in detail the implementation process of the present invention.

[0051] Step 1: After the vehicle user confirms the upgrade via the in-vehicle central control screen, the vehicle sends an upgrade request to the OTA server. Upon receiving the request, the OTA server obtains key information about the target MCU through the in-vehicle T-BOX. Specifically, the hardware parameters include the model MCU-A100, chip STM32H743, 1MB of memory, and 8MB of Flash storage; the software information includes the current version V1.2.0, the version to be upgraded to V1.3.0, and the verification algorithm CRC32; the communication parameters include support for programming sessions, security access level 2, and CAN bus baud rate of 500kbps; and the vehicle status includes a voltage of 13.5V, a 4G signal strength of -85dBm, and a CAN bus load rate of 40%. The above information is stored in the ECU information database.

[0052] Step 2: After receiving the above information, the dynamic configuration model calls the basic step templates, including session switching, secure access, data clearing, software transmission, verification, activation, and exit. The parameter matching engine configures parameters according to the MCU information. Based on memory 1MB between 512KB and 1GB, the data block size is configured to 4KB. Based on security level 2, the secure access key algorithm is configured as AES-128. Based on the current network status, the initial transmission rate is configured to 300KB / s. The version difference from V1.2.0 to V1.3.0 is only one iteration, not more than three, so no software partition backup step is added. The dynamic adjustment module optimizes parameters according to the real-time vehicle status. Because the signal strength of -85dBm is between -90dBm and -70dBm, which is a medium signal strength, the transmission rate is adjusted to 250KB / s. The exception handling submodule has preset exception policies, including communication timeout retry count preset to 3 times, data retransmission process triggered by verification failure, and switching to level 3 after 3 consecutive secure access timeouts.

[0053] Step 3: The dynamic configuration model generates a flash sequence file containing detailed instructions, in which... (1) Send the 0x10 0x02 command to switch to the programming session. Timeout is 100ms. Retry 2 times. (2) Send the 0x27 0x01 instruction to make a secure access request, with the key algorithm AES-128 and a timeout of 200ms; (3) Send the 0x31 0x01 command to clear Flash data, with a timeout of 500ms. (4) Transmit software data at a rate of 250KB / s per block, with a timeout of 300ms per block and 3 retries. The total software data is 8MB and requires 2000 blocks to be transmitted. (5) Send the 0x37 0x01 command to perform CRC32 verification, with a timeout of 200ms; (6) Send the 0x31 0x02 command to activate the software, with a timeout of 500ms; (7) Send the 0x10 0x01 command to switch back to the default session. The timeout is 100ms. After the sequence file is generated, it is transmitted to the vehicle T-BOX through the TLS encrypted channel.

[0054] Step 4: After receiving the sequence file, the vehicle-mounted T-BOX begins the flashing process. Sending the 0x10 0x02 command successfully switches to the programming session. Sending the 0x27 0x01 command retrieves the seed value 0x4A3F8C21 returned by the ECU, calculates the key 0x8D7E3F5A using the AES-128 algorithm, and sends 0x27 0x02 0x8D7E3F5A to complete secure access authentication. Sending the 0x31 0x01 command clears the Flash data, which takes approximately 300ms. Then, software data is transmitted at a rate of 250KB / s. When the 800th block is transmitted, the CAN bus load rate rises to 65%, approaching the 70% threshold. The dynamic adjustment module automatically reduces the transmission rate from 250KB / s to 200KB / s. A timeout occurs during the transmission of the 1200th block, triggering a retry process, and the second retransmission is successful. The exception handling submodule records the exception. After all data blocks are transmitted, sending 0x37... 0x01 Perform CRC32 check. The ECU calculates the check value as 0xA3B7C9D1, which matches the server value, and the check is successful. Send 0x31 0x02 After the software is activated, the ECU resets and the new software takes effect, which takes about 400ms. Finally, send 0x10 0x01 to switch back to the default session and report the upgrade success to the OTA server. The log includes a total time of 8 minutes, 1 abnormal record (1200th block retransmission), a maximum load rate of 65%, and a minimum signal strength of -85dBm.

[0055] Step 5: The OTA server collected 100 upgrade logs for this MCU model and performed statistical analysis. The results showed an average flashing success rate of 96% and a failure rate of 4%. 60% of the failures occurred when the bus load rate was greater than 60%, primarily due to data transmission timeouts. The average signal strength in the failed cases was -88dBm, slightly lower than the overall average of -82dBm. Based on the analysis, the optimization and iteration module lowered the bus load rate threshold of the dynamic adjustment module from 70% to 60%, meaning that the transmission rate was reduced when the bus load rate exceeded 60%. The signal strength threshold for poor network conditions was adjusted from -90dBm to -88dBm, allowing the system to enter low-rate protection mode earlier. Furthermore, a rule was added to the parameter matching engine for this MCU model: if the memory is 1MB and the historical average bus load rate is greater than 50%, the initial transmission rate is set to 200KB / s (previously 300KB / s). After the model update, the failure rate in the subsequent 200 upgrades decreased from 4% to 1%, and the flashing success rate increased to 99%.

[0056] This embodiment fully demonstrates the specific implementation of the technical solution of this invention through the entire process of remote OTA upgrade of the MCU of a certain brand of new energy vehicle. The OTA server obtains the hardware parameters, software information, communication parameters and vehicle status of the MCU through the vehicle T-BOX; the dynamic configuration model calls the sequence template library according to the collected information, and configures the data block size to 4KB based on 1MB of memory and the AES-128 key algorithm based on security level 2 through the parameter matching engine; the dynamic adjustment module optimizes the transmission rate from 300KB / s to 250KB / s based on the signal strength of -85dBm; the exception handling submodule presets strategies such as communication timeout retry 3 times, retransmission triggered by verification failure, and switching security access level for continuous timeout; step 3 generates a flashing sequence file containing detailed parameters such as specific UDS instructions, timeout time, and number of retries, and sends it to the vehicle T-BOX through a TLS encrypted channel to ensure the instructions are transmitted safely and efficiently. The accuracy and security of transmission were ensured; the dynamic adjustment module automatically reduced the transmission rate from 250KB / s to 200KB / s when it detected that the bus load rate rose to 65% during the execution process. The exception handling submodule successfully triggered the retry process when the 1200th data transmission timed out and successfully retransmitted on the second time. The final upgrade took 8 minutes, which is 33.3% more efficient than the traditional fixed sequence of 12 minutes; the OTA server collected 100 upgrade logs for big data analysis and identified the pattern of increased failure rate when the bus load rate exceeded 60%. Based on this, the dynamic adjustment threshold was reduced from 70% to 60%, the signal strength threshold was adjusted from -90dBm to -88dBm, and an initial rate optimization rule was added for this model of MCU, which reduced the failure rate of the subsequent 200 upgrades from 4% to 1%.

[0057] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. A dynamic configuration design method for UDS diagnostic flashing sequence in vehicle remote OTA upgrades, characterized in that, Includes the following steps: Step S1: In response to the vehicle's upgrade request, the OTA server collects key information of the target electronic control unit (ECU) through the vehicle-mounted remote information processor (T-BOX). The key information includes hardware parameters, software information, communication parameters, and vehicle status. Step S2: Construct a UDS writing sequence dynamic configuration model, which includes a sequence template library, a parameter matching engine, a dynamic adjustment module, and an exception handling sub-module; Step S3: Based on the key information collected in step S1, the dynamic configuration model calls the basic step template in the sequence template library, matches and fills the execution parameters of each step through the parameter matching engine, and the dynamic adjustment module optimizes the transmission parameters according to the real-time vehicle status to generate a personalized UDS writing sequence. Step S4: The vehicle-mounted remote information processor (T-BOX) executes the personalized UDS flashing sequence, and during the execution process, it monitors abnormal situations in real time through the abnormal handling submodule, dynamically adjusts the flashing parameters or executes the retry process. Step S5: The OTA server collects upgrade logs and optimizes and iterates the dynamic configuration model through big data analysis.

2. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 1, characterized in that, The key information collected in step S1 specifically includes: hardware parameters such as ECU model, chip type, memory capacity, and Flash storage size; software information such as current software version, software version to be upgraded, and software verification algorithm; communication parameters such as supported UDS session type, security access level, and CAN / LIN bus baud rate; and vehicle status such as current voltage, network signal strength, packet loss rate, and bus load rate.

3. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 1, characterized in that: The sequence template library pre-stores general UDS flashing step templates, including seven basic step templates: "session switching, secure access, data clearing, software transmission, verification, flashing activation, and session exit." Each step has a reserved parameter configuration interface. The parameter matching engine automatically matches key parameters for each step based on the hardware parameters and software information of the electronic control unit (ECU), including the secure access key algorithm, data block size, and transmission rate. The dynamic adjustment module dynamically adjusts the data transmission rate and retransmission mechanism based on real-time network signal strength and bus load rate. The exception handling submodule presets exception scenarios and corresponding adjustment strategies, responding to and handling exceptions in real time during the flashing process.

4. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 3, characterized in that, The matching rules of the parameter matching engine include: configuring the data block size according to the memory capacity; if the memory capacity is less than the first threshold, it is configured as the first data block value; if the memory capacity is greater than or equal to the second threshold, it is configured as the second data block value; and according to the degree of difference between the software version to be upgraded and the current software version, if the difference exceeds the preset number of versions, a "software partition backup" step is added.

5. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrades according to claim 3, characterized in that, The adjustment rules of the dynamic adjustment module include: when the network signal strength is lower than the first signal threshold or the bus load rate is higher than the first load threshold, reducing the data transmission rate and adding a data retransmission mechanism; when the network signal strength is higher than the second signal threshold and the bus load rate is lower than the second load threshold, increasing the data transmission rate to the preset maximum value.

6. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 3, characterized in that, The adjustment strategy of the exception handling submodule includes: if multiple consecutive security access requests time out, automatically switch the security access level and extend the waiting time; if the software verification fails, trigger the retry process of "data retransmission, secondary verification, and hardware reset".

7. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 1, characterized in that, The specific process of generating a personalized UDS flashing sequence in step S3 includes: calling a basic step template from the sequence template library and removing steps that are not supported by the ECU; filling specific parameters for each step through the parameter matching engine to generate an operation sequence containing "instruction code, parameter value, execution timeout, and number of retries"; the dynamic adjustment module performs final optimization of the parameters of the data transmission steps based on the real-time vehicle status to generate an executable flashing sequence file, and transmits it to the vehicle remote information processor (T-BOX) through an encrypted channel.

8. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 1, characterized in that, The specific process of execution and monitoring in step S4 includes: sending a session switching command to the target electronic control unit (ECU) to enter the programming session; executing a secure access process and completing identity authentication through a key algorithm that matches parameters; transmitting software data at a dynamically adjusted rate while simultaneously collecting ECU feedback information in real time; the anomaly handling submodule monitors the execution process in real time, and if an anomaly is detected, immediately triggering a preset adjustment strategy; after completing the software flashing, executing an activation command and switching back to the default session, and sending the upgrade result back to the OTA server.

9. The UDS diagnostic flashing sequence dynamic configuration design method for vehicle remote OTA upgrade according to claim 1, characterized in that, The specific process of optimization iteration in step S5 includes: if the failure rate of flashing a certain type of electronic control unit (ECU) exceeds the preset failure rate threshold, analyze the reasons for failure and update the sequence template library or parameter matching rules; optimize the transmission rate threshold of the dynamically adjusted module according to the network status data of different regions; synchronize the optimized model to all OTA server nodes to realize the continuous iteration of flashing sequence configuration capability.

10. A UDS diagnostic flashing sequence dynamic configuration system for remote OTA upgrade of vehicles according to any one of claims 1-9, characterized in that, include: OTA server, vehicle telematics processor (T-BOX), electronic control unit (ECU).

Images