A uds-based controller flashing optimization method and system

Abstract

The application discloses a kind of based on UDS's controller brush write optimization method and system, belong to new energy automobile field.The method includes: original brush write data is obtained and is preprocessed optimization in diagnostic equipment end, and the preprocessing optimization includes data compression, checksum calculation;UDS communication protocol between diagnostic equipment end and controller end is optimized, including introducing multithread transmission technology, diagnostic equipment end data frame format optimization, controller end protocol stack upgrade;Buffer area is established in controller end, and optimized cache management mechanism and interrupt handling procedure are used;Intelligent brush write process is designed, including intelligent detection before brush write, real-time monitoring and intelligent fault tolerance in brush write, log record and report generation after brush write;Diagnostic equipment end establishes brush write mode switching mechanism.The application improves the efficiency of brush write.

Description

Technical Field

[0001] This invention belongs to the field of new energy vehicles. Specifically, this invention relates to a controller flashing optimization method and system based on UDS. Background Technology

[0002] In automotive electronic control systems, controller software updates are crucial for ensuring vehicle performance, safety, and functionality. User-defined diagnostics (UDS), a widely used diagnostic protocol, facilitates communication and data exchange between the vehicle controller and external diagnostic equipment to perform operations such as software rewriting. However, current UDS rewriting speeds have limitations, resulting in lengthy rewriting processes. This not only impacts efficiency on automotive production lines and increases production costs but also inconveniences software updates during vehicle maintenance and repair, extending vehicle downtime.

[0003] In existing technologies, flashing a single controller using the traditional UDS flashing method takes an average of 5 minutes. For a car with multiple controllers, the total flashing time can severely impact production schedules. In after-sales service scenarios, long flashing wait times also reduce customer satisfaction.

[0004] Therefore, this invention proposes a controller writing optimization method and system based on UDS. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of the prior art and proposes a controller writing optimization method and system based on UDS to achieve the following objective: improve writing efficiency.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A controller flashing optimization method based on UDS, the method comprising the following steps: Step S1: The diagnostic device acquires the raw flashing data and performs preprocessing optimization, which includes data compression, verification, and calculation. Step S2: Optimize the UDS communication protocol between the diagnostic device and the controller, including introducing multi-threaded transmission technology, optimizing the data frame format of the diagnostic device, and upgrading the protocol stack of the controller. Step S3: Establish a buffer on the controller side and adopt an optimized buffer management mechanism and interrupt handler; Step S4: Design an intelligent flashing process, including intelligent detection before flashing, real-time monitoring and intelligent fault tolerance during flashing, and log recording and report generation after flashing. Step S5: Establish a flashing / writing mode switching mechanism on the diagnostic device.

[0007] Preferably, step S1 includes: Step S11: The diagnostic device automatically reads the original flashing data to be flashed according to the user's selection; Step S12: The diagnostic device uses a preset data compression algorithm to compress the original write data; Step S13: After compression is complete, calculate the checksum of the compressed data; Step S14: Encapsulate the compressed data and its calculated checksum according to a preset format to form a complete flash data packet.

[0008] Preferably, in step S2, the introduced multi-threaded transmission technology, through dynamic thread pool management and concurrent session management, allows the diagnostic device to establish independent UDS communication sessions with multiple controllers simultaneously, achieving parallel writing of multiple controllers, wherein: Dynamic thread pool management: Based on the number of threads configured by the user, a corresponding number of independent transmission threads are created and initialized to form a thread pool; each thread is allocated a dedicated communication handle, memory resources, and state machine; Concurrent session management: Each thread in the thread pool independently executes the complete UDS writing process with its corresponding target controller; the diagnostic device is equipped with a main thread to monitor the running status of all sub-threads in the thread pool, and displays the running status of each sub-thread to the operator in the form of a dashboard or list through the software interface, realizing the visual management of multi-thread status.

[0009] Preferably, in step S2, the optimization of the data frame format at the diagnostic device end includes: Frame structure reconstruction: The core of reconstructing traditional UDS transmission frames is to expand the effective payload and simplify redundant information at the beginning and end of the frame. Adaptive frame verification: For the reconstructed frame structure, the calculation range and algorithm of the frame verification sequence are adjusted synchronously. The diagnostic device dynamically calculates the CRC check value according to the reconstructed frame structure and packages the new CRC check value together with the reconstructed frame structure.

[0010] Preferably, in step S2, the controller-side protocol stack upgrade includes: Dual-mode parsing capability development: Upgrade the controller's bootloader software to enable dual-mode parsing capability, that is, the controller can identify the specific flag bits in the frame header to determine whether the received frame is in the traditional format or the reconstructed format, and automatically call the corresponding parsing routine. Establish an efficient data extraction mechanism: used to identify and extract the payload field from the reconstructed frame structure, and at the same time, perform frame verification; Flow control coordination: The controller-side protocol stack still uses the ISO TP flow control protocol.

[0011] Preferred, optimized cache management mechanisms refer to establishing cache management algorithms based on the cache area, including: Data reception and storage: After the data frame received by the controller from the communication interface is parsed, its payload data is sequentially stored in the buffer area, and the write pointer is updated at the same time. Real-time status monitoring: The controller continuously calculates the current utilization rate of the buffer through a low-priority background task or timer interrupt: Utilization rate = (write pointer - read pointer) / total buffer size × 100%; Threshold triggering mechanism: Preset usage rate trigger threshold; Batch write operation: When the usage rate exceeds the trigger threshold, a batch write task is triggered, that is, the Flash driver is triggered to program all the data in the current buffer from the read pointer to the write pointer as a continuous data block into the specified address of the Flash memory at once; Buffer reset: After a batch write is successful, the read / write pointers are reset, the buffer is cleared, and it is ready to receive the next batch of data.

[0012] Preferably, in step S3, the optimization of the interrupt handler includes increasing the interrupt response priority and simplifying the interrupt service routine (ISR), wherein: Increase interrupt response priority: Set the interrupt priority of the communication peripheral in the controller responsible for receiving data frames to one of the highest levels; Simplify interrupt service routines: Used to remove time-consuming operations from interrupt service routines, retaining only the most critical and indispensable operations.

[0013] Preferably, in step S4: The intelligent detection before flashing includes: before flashing, the diagnostic equipment first performs a comprehensive detection of the vehicle's network status and controller status, and dynamically adjusts the flashing parameters based on the detection results. The parameters include the transmission rate and the number of retries. The real-time monitoring and intelligent fault tolerance in the flashing process include: during the flashing process, the flashing progress and data transmission status are monitored in real time. Once an abnormality is detected, the flashing is immediately paused and fault diagnosis and repair are performed. After the repair is completed, the flashing continues from the pause point to avoid wasting time by restarting the flashing process. The logging and report generation after flashing includes: recording the entire process of detection, adjustment, flashing, pausing, and recovery in detail in a log file, and automatically generating a report containing work data of the flashing process, including vehicle VIN, version before flashing, version after flashing, detection results, time taken, and whether there are any abnormalities.

[0014] Preferably, in step S5, the flashing mode switching mechanism refers to pre-setting multiple flashing modes and configuring corresponding parameters on the diagnostic device. When flashing is required, the operator selects the corresponding flashing mode on the diagnostic device according to different scenarios, and the diagnostic device automatically calls the parameter configuration of the corresponding flashing mode to execute the flashing task.

[0015] The present invention also provides a controller flashing optimization system based on UDS, using the above-described controller flashing optimization method based on UDS. The system includes a diagnostic device and at least one controller, the diagnostic device and at least one controller being used to execute a computer program constructed according to the above-described controller flashing optimization method based on UDS.

[0016] The technical effects of this invention are as follows: This invention significantly improves the efficiency of the UDS flashing process by employing technologies such as dynamic data compression, parallel processing, and adaptive flow control, reducing the total flashing time by more than 30%. While greatly accelerating the process, this solution ensures the reliability and stability of data transmission, and requires no modification to existing host computer tools and vehicle protocol stacks, effectively reducing time and economic costs in production and after-sales processes. Attached Figure Description

[0017] Figure 1 The flowchart illustrates a controller flashing optimization method based on UDS, as provided in this embodiment of the invention. Detailed Implementation

[0018] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the present invention will be explained and illustrated through the following embodiments.

[0019] This invention addresses the problems of long communication idle time, low bandwidth utilization, and low flashing efficiency caused by serial interaction in traditional UDS flashing by implementing five core steps in synergy: data preprocessing optimization, communication protocol optimization, controller optimization, flashing process optimization, and flashing mode switching. While ensuring the reliability and stability of data transmission, it shortens the flashing time for a single controller and the flashing time for a whole vehicle with multiple controllers, without requiring modification to existing host computer tools and vehicle protocol stacks, thus significantly reducing the time and economic costs of automobile production and after-sales processes.

[0020] Specifically, embodiments of the present invention provide a controller writing optimization method based on UDS, such as... Figure 1 As shown, the method includes the following steps: Step S1: The diagnostic device acquires the raw data and performs preprocessing optimization, which includes data compression, verification, and calculation; this is used to reduce the amount of data transmitted and complete integrity verification in advance. Step S2: Optimize the UDS communication protocol between the diagnostic device and the controller, including introducing multi-threaded transmission technology, optimizing the data frame format on the diagnostic device side, and upgrading the protocol stack on the controller side; this is used to achieve parallel transmission between multiple controllers and improve the data transmission efficiency of a single frame. Step S3: Establish a buffer on the controller side and adopt an optimized cache management mechanism and interrupt handler to improve data reception, caching and writing efficiency. Step S4: Design an intelligent flashing process, including intelligent detection before flashing, real-time monitoring and intelligent fault tolerance during flashing, and log recording and report generation after flashing; to achieve intelligent and efficient flashing process. Step S5: Establish a flashing mode switching mechanism on the diagnostic device to achieve dynamic adaptation between flashing speed and reliability.

[0021] The steps in this embodiment of the invention are interconnected, and the entire chain from data source, transmission process, receiving terminal, process management, and scenario adaptation improves the efficiency of UDS writing. The following is a detailed description of each step.

[0022] Traditional UDS flashing processes directly transmit unprocessed raw firmware data, which presents two major problems: First, the raw data contains a large number of repetitive byte patterns, resulting in large data volumes, long transmission times, and high network bandwidth usage. Second, data integrity is not verified beforehand; if data is corrupted during transmission, the entire data block must be retransmitted, potentially leading to flashing retry and significantly increasing processing time. Therefore, referring to step S1 of this embodiment, optimization of the data preprocessing stage is first performed. Data preprocessing optimization is a preliminary step in the flashing process, executed on the diagnostic device side. It is completed after the operator selects the target controller and the raw flashing data to be flashed, but before the diagnostic device establishes a UDS session with the controller. The specific operations of the overall process are as follows.

[0023] Step S11: The diagnostic device automatically reads the raw flashing data to be flashed based on the user's selection. When the operator is ready to perform the UDS flashing task, they first need to select the target controller (such as ECU, TCU, BCM, etc.) in the software interface and specify the raw data file to be flashed (usually a binary firmware file). After confirming the selection, the diagnostic device's software system will automatically trigger the data processing pipeline.

[0024] Step S12: The diagnostic device compresses the raw flash data using a preset data compression algorithm. Specifically, this embodiment uses a high-efficiency lossless compression algorithm (such as LZ77, LZMA, or Deflate) to compress the raw flash data. The compression process significantly reduces the data volume by finding and encoding repeating patterns in the data, typically achieving a compression rate of around 40%, meaning the data volume is reduced to about 60% of its original size. During compression, the software interface on the diagnostic device displays the compression progress in real time through a progress bar and percentage display, allowing operators to clearly understand the processing status.

[0025] Step S13: After compression, calculate the checksum of the compressed data. Specifically, for the checksum calculation of the compressed data, this embodiment uses hash algorithms such as CRC32, SHA-1, or MD5 to generate a unique data fingerprint. This checksum will be used for integrity verification during subsequent data transmission. Calculating the checksum of the data allows for early checking of data integrity and accuracy, avoiding retries and wasted time due to data errors during the flashing process.

[0026] Step S14: Encapsulate the compressed data and its calculated checksum according to a preset format to form a complete flash data packet. The packaging format typically includes: a file header identifier (marking the start of the data packet), a compressed data length field (to facilitate the controller's confirmation of the data reception length), the compressed data body, the checksum value, and a file tail identifier (marking the end of the data packet). This structured encapsulation ensures the integrity and identifiability of the data during transmission.

[0027] Finally, the packaged data blocks are stored in the transmission queue, awaiting the establishment of a UDS session between the diagnostic device and the target controller before being efficiently and reliably transmitted via the TransferData service. This entire preprocessing process not only reduces network transmission load but also provides crucial assurance for the reliability of the write operation through an integrity verification mechanism.

[0028] The preprocessing optimization in step S1 significantly reduces the amount of data transmitted. Specifically, it reduces the original data volume through lossless compression algorithms, directly lowering network transmission load, shortening data transmission time, and improving bandwidth utilization. Simultaneously, the use of lossless compression algorithms ensures that the compressed data is completely consistent with the original data after decompression at the controller, preventing data errors caused by compression and guaranteeing the accuracy of the flashing process. The preprocessing stage also performs data integrity verification, preventing corrupted or erroneous data from entering the transmission process, reducing data retries and process rollbacks during flashing, and improving the smoothness of the flashing process. The structured packet format allows the controller to quickly identify the start, end, and length of data packets, facilitating data parsing and reception, and reducing data processing time at the controller. The progress of the entire compression process is displayed in real time, allowing operators to clearly understand the preprocessing status and improving operational controllability.

[0029] Traditional UDS flashing uses a serial transmission mode, where the diagnostic device establishes sessions with each controller sequentially and transmits data. The total flashing time for multiple controllers is the sum of the flashing times for each controller. For modern new energy vehicles with multiple controllers, the total flashing time can reach several hours, severely impacting production efficiency. Simultaneously, traditional UDS transmission frames have a low effective payload ratio, with a large amount of unnecessary redundant information in the frame header and footer. This results in less effective data transmitted per frame and a larger number of frames needing to be transmitted, increasing both transmission time and the probability of network communication errors. Therefore, referring to step S2 of this embodiment, the communication protocol is optimized. This optimization is performed on both the diagnostic device and controller sides and is a core optimization step implemented after data preprocessing and during the actual data transmission. It solves the efficiency problem of traditional serial transmission and the redundancy problem of single-frame data transmission by introducing multi-threaded transmission technology, optimizing the data frame format on the diagnostic device side, and upgrading the protocol stack on the controller side.

[0030] Specifically, in step S2 of this embodiment, the introduced multi-threaded transmission technology enables the diagnostic device to establish independent UDS communication sessions with multiple controllers simultaneously through dynamic thread pool management and concurrent session management, thereby achieving parallel writing of multiple controllers. For example, for a vehicle network with multiple controllers, the number of transmission threads of the diagnostic device is set to be the same as the number of controllers, and each thread is responsible for communicating with one controller.

[0031] Dynamic thread pool management refers to the operator selecting all target controllers to be flashed and setting the number of transmission threads in the diagnostic equipment's communication software configuration interface. Each thread can also be assigned a specific target controller (e.g., thread 1 corresponds to the engine ECU, thread 2 to the speed control TCU), enabling fine-grained configuration and providing significant flexibility. When flashing begins, the diagnostic equipment creates and initializes the corresponding number of independent transmission threads, forming a thread pool, based on the user-configured thread count. Each thread is allocated a dedicated communication handle, memory resources, and a state machine. Communication handle: Independent CAN or DoIP network connection channel; Memory resources: Dedicated data cache and message queue; State machine: Independently maintains its session state with the corresponding controller, secure access state, and write process state; This design avoids conflicts and delays caused by multiple threads competing for the same communication resources, thus achieving true parallel processing.

[0032] Concurrent session management refers to the following: Each thread in the thread pool independently executes the complete UDS flushing process with its corresponding target controller. For example, the process might involve: diagnostic session control → secure access → routine control (checking programming preconditions) → request download → data transfer → request to exit transfer → routine control (checking checksums). Each thread's session flow is independent and executed in parallel, without any specific order. Simultaneously, the diagnostic device has a main thread to monitor the running status of all sub-threads in the thread pool (connection status of each controller, current progress, transfer rate, and any error messages, etc.). The running status of each sub-thread is then visually displayed to the operator through a dashboard or list on the software interface, enabling visualized management of the multi-threaded status.

[0033] For modern vehicles with multiple controllers, multi-threaded transmission technology reduces the total flashing time from "the sum of flashing times of each controller" to "the flashing time of the slowest controller", resulting in a significant improvement in efficiency.

[0034] Meanwhile, step S2 in this embodiment also improves the effective payload ratio of a single frame of data and reduces the number of transmission frames by optimizing the data frame format on the diagnostic device side and upgrading the protocol stack on the controller side, while ensuring compatibility between the new and old systems.

[0035] Specifically, the optimization of the data frame format at the diagnostic device end includes: Frame structure reconstruction: Reconstructing traditional UDS transmission frames (such as ISO TP protocol under CAN FD frames) involves expanding the payload and simplifying redundant information at the frame header and footer. Expanding the payload means increasing the effective data payload of a single frame from the traditional 8 bytes (CAN 2.0) or 64 bytes (CAN FD). This can be achieved by reducing overhead such as protocol control information (PCI) to increase the payload ratio. Simplifying redundant information at the frame header and footer means merging or removing some fields that are not necessary in specific writing scenarios (such as certain reserved bits or overly long service identifiers) to further reduce overhead. Adaptive Frame Check: Due to the change in frame format, the calculation range and algorithm of the Frame Check Sequence (FCS) need to be adjusted synchronously; the diagnostic device dynamically calculates the CRC check value based on the reconstructed frame structure and packages the new CRC check value together with the reconstructed frame structure to ensure the integrity of data transmission.

[0036] The controller-side protocol stack upgrade includes: Dual-mode parsing capability development: To ensure that both the old and new systems can work, this embodiment upgrades the controller's bootloader software to enable it to have dual-mode parsing capability. That is, the controller determines whether the received frame is in the traditional format or the reconstructed format by identifying specific flag bits in the frame header, and automatically calls the corresponding parsing routine. Establish an efficient data extraction mechanism: This mechanism is used to identify and extract the payload field from the reconstructed frame structure, and at the same time, perform frame verification. After the receiver protocol stack is upgraded, it needs to be able to correctly identify the expanded payload field and extract it efficiently to improve data parsing efficiency. At the same time, it can also verify the frame verification sequence according to the new rules to ensure the integrity of data transmission. Flow control coordination: In this embodiment, the upgraded controller-side protocol stack still adopts the ISO TP flow control protocol, which dynamically adjusts the data transmission rate according to the state of the controller's receive buffer to ensure that the controller's receive buffer is not overwhelmed by excessive data volume during high-speed transmission, thus avoiding data loss.

[0037] The communication protocol optimization in step S2 has the following advantages: By replacing the traditional serial mode with a parallel transmission mode, the overall writing time of multiple controllers is significantly shortened; the single-frame transmission efficiency is also significantly improved, i.e., the effective payload ratio is increased, the number of data transmission frames is reduced, directly shortening the data transmission time of a single controller, and reducing the probability of network communication errors; each thread is allocated a dedicated communication handle and memory resources, avoiding resource contention between threads, realizing fine-grained management of communication resources, and improving the overall network bandwidth utilization; the dual-mode parsing capability of the controller-side protocol stack ensures that this method is fully compatible with existing traditional UDS writing devices and controllers, without requiring modification of existing host computer tools and vehicle protocol stacks, or replacement of controller hardware, resulting in low implementation costs; real-time visualization monitoring of multi-threaded states allows operators to intuitively grasp the writing progress and status of each controller, facilitating timely detection and handling of abnormal situations; this embodiment also strictly adheres to the ISO TP flow control protocol to avoid buffer overflows and data loss caused by high-speed transmission, ensuring the stability of data transmission.

[0038] Traditional controller-side UDS writing employs a receive-and-write processing mode. The controller writes a small amount of data to memory immediately after receiving it. However, the page programming characteristics of memory mean that small-scale, random writes are much slower than large-scale, sequential writes. Frequent small-scale writes not only slow down the writing speed but also increase the number of erase / write cycles, shortening the memory's lifespan. Simultaneously, traditional interrupt handlers suffer from low priority and lengthy processes, leading to controller response delays when data frames arrive, potentially resulting in untimely data reception or data loss. Furthermore, lengthy interrupt handlers consume significant controller resources, impacting the execution of other system tasks and reducing system stability. Therefore, referring to step S3, this embodiment optimizes the controller side by establishing a buffer and employing an optimized buffer management mechanism and interrupt handler. Controller-side optimization is a terminal optimization step implemented during the data reception and writing phases, executed within each vehicle controller. Its core improvements lie in optimizing the buffer management mechanism, optimizing the interrupt handler, and their collaborative design, thereby increasing the data processing and writing speed at the controller side.

[0039] Specifically, a buffer refers to a fixed-size contiguous memory area in the controller's RAM, pre-defined statically or dynamically allocated, used to cache data uploaded and written by the diagnostic device. The buffer size (e.g., 1MB) needs to be precisely calculated, balancing factors such as the total available RAM, maximum data packet size, and Flash write time. Buffers are typically implemented using a ring buffer or a double buffer structure. A ring buffer is a more efficient choice, managing data storage and retrieval by maintaining read / write pointers, avoiding frequent memory relocation.

[0040] An optimized cache management mechanism refers to establishing a cache management algorithm based on the cache area, including: Data reception and storage: Data frames received from the communication interface (such as the CAN controller) are parsed, and their payload data is sequentially stored in the circular buffer while the write pointer is updated. Real-time status monitoring: A low-priority background task or timer interrupt continuously calculates the current utilization rate of the buffer: Utilization rate = (Write pointer - Read pointer) / Total buffer size × 100%; Threshold triggering mechanism: Setting a reasonable trigger threshold (e.g., 80%) and reserving 20% ​​space (water level) is crucial. This ensures that after triggering batch writing and before the buffer is cleared, the Interrupt Service Routine (ISR) still has enough space to receive subsequent data, thereby preventing data overwriting or loss and realizing pipelined operation of data transmission and Flash writing. Batch write operation: When the usage rate exceeds a threshold, the management algorithm triggers the Flash driver to program all data (approximately 0.8MB) from the read pointer to the write pointer in the current buffer as a contiguous block to a specified address in the Flash memory at once. This process typically needs to be interrupt-disabled or executed in a high-priority task to ensure the atomicity of the write operation; Buffer reset: After a batch write is successful, the read / write pointers are reset, the buffer is cleared, and it is ready to receive the next batch of data.

[0041] Optimizing interrupt handlers includes increasing interrupt response priority and simplifying interrupt service routines (ISRs), thereby addressing issues such as response delays, untimely data reception due to excessively long ISRs, and poor system stability in traditional interrupt handling. Specific steps are as follows: Increase interrupt response priority: Set the interrupt priority of the communication peripherals (such as CAN RX interrupt) in the controller responsible for receiving data frames to one of the highest levels in the system (higher than the system tick timer SysTick, etc.); ensure that when the data frame from the diagnostic device arrives, the controller can immediately suspend the currently executing low-priority task, respond quickly to the communication interrupt, minimize interrupt latency, and avoid data loss due to untimely response; Simplified Interrupt Service Routine (ISR): Strictly designed according to the fast-in, fast-out principle, the optimized ISR only executes the most critical and indispensable operations, eliminating all time-consuming operations (all non-critical tasks are strictly prohibited from being executed in the ISR, especially Flash write operations, complex calculations, API calls (such as memory allocation), and logging, etc., these operations should be deferred to the background main loop or low-priority tasks). In this embodiment, the specific execution flow of an ISR is as follows: Read data: Immediately read the received data from the data register of the communication peripheral; Temporary data storage: Quickly store the data into the allocated RAM cache (update the write pointer); Clear interrupt flag: Clears the interrupt request flag of the peripheral device.

[0042] In a preferred embodiment of this application, if the controller hardware supports direct memory access (DMA), a DMA module is configured to assist in data transfer. The DMA module can automatically transfer the data received by the communication peripheral to the designated RAM cache without occupying controller resources, thereby further reducing the processing burden of the controller, shortening interrupt processing time, and improving data reception efficiency.

[0043] Furthermore, in this embodiment, the optimized cache management mechanism and interrupt handler do not run independently. They are designed collaboratively through three dimensions: critical section protection, error handling and recovery, and power consumption considerations. This ensures smooth cooperation between the two and improves the overall stability and efficiency of the controller. The specific operation is as follows: Critical section protection: Since the read / write pointers of the buffer are shared resources and are accessed by both the interrupt service routine (ISR) and the background main loop / cache management task, critical section protection is implemented for the read / write pointers to prevent pointer corruption caused by data races. This is done by disabling interrupts or using a mutex mechanism. When the ISR accesses the pointer, other tasks that may access the pointer are temporarily disabled. When a background task accesses the pointer, it is ensured that the ISR is not executing, thus avoiding pointer data corruption.

[0044] Error Handling and Recovery: A unified error handling mechanism is established. When situations such as batch writing to Flash fails, buffer overflow occurs, or data reception errors occur, the controller immediately records the error code, triggers the exception handling process, and simultaneously sends specific error information back to the diagnostic device. If it is a minor error (such as a single Flash write failure), a retry operation is automatically performed. If it is a serious error (such as a buffer overflow), the data reception and writing process is immediately suspended, awaiting the fault handling instructions from the diagnostic device.

[0045] Power consumption considerations: For battery-powered scenarios in new energy vehicles, power consumption optimization is considered in the collaborative design; the batch write mechanism transforms frequent small-scale Flash writes into a small number of large-scale writes, reducing the Flash's working time and lowering the controller's average power consumption; at the same time, low-priority background monitoring tasks only run at high frequency when necessary and at low frequency when there is no data, further reducing the controller's power consumption.

[0046] The controller-side optimization in step S3 has the following advantages: Batch writing mechanism improves the brushing speed of the controller, significantly shortening the data processing time on the controller. Combined with the high-speed transmission of the diagnostic device, it achieves a speed improvement across the entire link. It transforms frequent small-scale writes into a small number of large-scale writes, reducing the number of Flash erase / write cycles, directly extending its lifespan, and reducing hardware wear and maintenance costs of the controller. High-priority interrupt response and streamlined ISR minimize interrupt latency, ensuring that the controller can keep up with the high-speed data flow of the diagnostic device. Even under heavy network load, it can process each data packet in a timely manner, avoiding data loss, communication timeouts, and error frames. The buffer acts as a buffer between the high-speed communication interface and the low-speed Flash memory, smoothing the data transmission flow and avoiding communication interface blockage caused by slow Flash write speed, thus ensuring the continuity of data transmission.

[0047] Step S4 in this embodiment aims to optimize the flashing process. Flashing process optimization is a management optimization step that runs through the entire process before, during, and after flashing. It is executed on the diagnostic device side. The core is to solve the problems of no advance detection, fixed parameters, need to re-flash for anomalies, and no traceability records in the traditional flashing process by intelligent detection and adaptive parameter adjustment before flashing, real-time monitoring and intelligent fault tolerance during flashing, and log recording and report generation after flashing. This achieves intelligent and efficient flashing process.

[0048] Specifically, the intelligent detection before flashing is the first and most important line of defense to ensure successful flashing. It goes beyond a simple connectivity test and performs a comprehensive "vehicle health check." The intelligent detection before flashing includes: before flashing, the diagnostic equipment first performs a comprehensive test on the vehicle's network status and controller status, and dynamically adjusts the flashing parameters based on the test results. These parameters include transmission rate and number of retries.

[0049] The network status detection of the vehicle includes: (1) Physical layer and link layer diagnostics, including: Connectivity test: Send UDS services such as TesterPresent or ECUReset to the target controller to confirm whether it can give a valid response and whether basic communication has been established; Signal quality analysis: Monitor networks such as CAN bus and analyze the number and type of error frames (such as format errors, bit errors, CRC errors); the error frame rate is a key indicator for evaluating the physical layer quality of the network (such as harness interference, termination resistor mismatch).

[0050] Network load rate calculation: Monitor bus load during pre-detection; excessively high load rate (such as consistently exceeding 50%) indicates network congestion, which can easily lead to conflicts and timeouts during high-speed writing; Sleep / Wake-up Verification: Ensure the vehicle network is in a wake-up state that allows flashing and can properly prevent entering sleep mode during the flashing process; (2) Application layer gateway routing detection (for central gateway architecture): If the target controller is located in a different network segment (e.g., body CAN vs power CAN), the routing function through the gateway will be tested to ensure that the flashing command and data can be forwarded correctly.

[0051] The controller status detection includes: (1) Session and security status check: Confirm whether the controller is in an extended session or a programming session that allows writing. (2) Check the security access status of the controller: If it is not unlocked, the unlocking process can be triggered in advance, or the operator can be prompted to perform security access first; (3) Resource and compatibility audit, including: Storage space verification: Use the RequestDownload service or read the controller identifier to accurately query the available storage space of the target controller and compare it with the size of the flush packet to ensure sufficient space and avoid failure due to insufficient space during the flushing process; Software version verification: Reads (ReadDataByIdentifier) ​​the controller's current software / calibration data version number and hardware part number. Compares this information with the expected information in the flashing data package to ensure version compatibility and prevent accidental flashing that could brick the controller. Programming precondition checks: Trigger specific routines through the RoutineControl service to check critical preconditions such as whether the voltage is stable (usually requiring 12V-15V), whether the transmission is in park, and whether the engine is off.

[0052] Simultaneously, the diagnostic device incorporates a strategy engine that maps detection results (such as error frame rate and load rate) to optimal flashing parameters, thereby dynamically adjusting these parameters based on the detection results. For example: Excellent network quality (error frame rate <1%, load rate <30%) corresponds to aggressive mode, using the highest transmission rate, maximum data block length, and minimum number of retries (e.g., 3 times). The network quality is moderate (with slight interference), corresponding to the balanced mode, which involves using a medium transmission rate, increasing the number of retries (e.g., 10 times), and extending the response timeout. Poor network quality (high error frame rate) or voltage fluctuations trigger a robust mode, which uses a lower transmission rate, increases the number of retries (e.g., 20), and uses smaller data blocks for transmission.

[0053] Finally, the diagnostic device will display all the adjusted flashing parameters in a clear summary form on the diagnostic device software interface and request the operator's final confirmation. The operator can manually modify the parameters according to the actual situation, retaining the final decision-making right of human experts to prevent system misjudgment.

[0054] The real-time monitoring and intelligent fault tolerance in the flashing process include: real-time monitoring of the flashing progress and data transmission status during the flashing process; if an abnormality is detected, the flashing is immediately paused and fault diagnosis and repair are performed; after repair, the flashing resumes from the pause point, avoiding the time waste caused by restarting the flashing process.

[0055] Specifically, multi-dimensional visual monitoring is implemented during the flashing process. This involves building a flashing monitoring dashboard on the diagnostic device software interface to achieve real-time visualization of the flashing status. Specific monitoring dimensions include: Progress monitoring: Displays the overall write progress using a progress bar and percentage. It also shows the current data block number being written / total number of blocks. Performance monitoring: Real-time display of instantaneous transfer rate (KB / s) and average transfer rate, usually presented as a line graph for easy observation of rate fluctuations; Status monitoring: Displays the status of each transmission request (e.g., success, in progress, failure), the number of retries, and the response time.

[0056] Simultaneously, an exception handling and breakpoint resumption mechanism is established during the flashing process. This involves setting multi-dimensional exception triggering conditions and scanning all status data during the flashing process in real time. Once any condition is triggered, the flashing process is immediately and safely paused. During the pause, the diagnostic device immediately records the position of the last successfully flashed data block as the breakpoint and saves the breakpoint information locally to ensure that the breakpoint is not lost. The multi-dimensional exception triggering conditions include: The number of retries for transmitting the same data block exceeds the set maximum value; Received an NRC negative response code from the controller (such as 0x72 General programming failure, 0x22 Incorrect condition); The flashing progress did not change within the scheduled time (progress stalled). Interacting with the vehicle power management system, it was detected that the vehicle voltage was below the safety threshold of 12V. A large number of error frames appeared on the network bus, causing communication to be interrupted.

[0057] Upon detecting an anomaly that caused the flashing process to pause, the diagnostic equipment immediately activated its fault diagnosis expert system. This system analyzed the log data (NRC codes, network traces, controller status, voltage data, etc.) generated during the flashing process. The system's built-in fault tree model matched the anomaly to possible causes and provided specific solutions to the operator. After the operator resolved the issue using the solution, no further complex operations were required; simply clicking the "Continue" button on the diagnostic equipment's software interface allowed the software to resume transmitting the remaining data blocks from the previously recorded breakpoint, eliminating the need to start from scratch and saving significant time.

[0058] The post-flashing log recording and report generation includes: recording the entire process of detection, adjustment, flashing, pausing, and recovery in detail to a log file, which can be exported for subsequent problem tracing and process optimization; and automatically generating a report containing work data of the flashing process, including vehicle VIN, version before flashing, version after flashing, detection results, time taken, and whether there are any abnormalities.

[0059] Step S4 optimizes the flashing process by conducting comprehensive pre-flash detection to identify and mitigate the risk of flashing failures, thereby improving the first-time success rate from the source. Dynamically and adaptively adjusting flashing parameters allows the process to adapt to different network and controller states, maximizing transmission efficiency while ensuring reliability. Real-time monitoring and breakpoint resumption during flashing prevent re-flashing due to anomalies, significantly reducing wasted time. Post-flash logging and report generation enable full-process data traceability, facilitating problem analysis and production / after-sales management, thus achieving an intelligent and refined flashing process.

[0060] To achieve personalized adaptation based on actual application scenarios, see step S5. This embodiment establishes a flashing mode switching mechanism. By predefining multi-mode flashing strategies, operators can select the corresponding flashing mode according to different scenarios such as production, after-sales service, and debugging, so as to meet the personalized needs of different drinking scenarios.

[0061] The aforementioned flashing mode switching mechanism refers to the pre-setting of multiple flashing modes and corresponding parameter configurations on the diagnostic device. Correspondingly, at the diagnostic device software code layer, each mode corresponds to a structure or configuration file, which contains all relevant transmission parameters, function switches (Boolean values), and optimization strategy identifiers. When flashing is required, the operator selects the appropriate flashing mode on the diagnostic device according to different scenarios, and the diagnostic device automatically calls the corresponding flashing mode's parameter configuration to execute the flashing task.

[0062] For example, the flashing mode and its parameter configuration set in this embodiment include: 1. High-Speed ​​Mode: (1) Design goal: Maximize throughput and minimize total write time at all costs; (2) Applicable scenarios: Automobile production line (End-of-Line). The environment is highly controllable, the vehicle power supply is guaranteed by an external voltage regulator, the network quality is excellent, and all controller models are known and stable; (3) Specific parameter configuration: Transmission rate: Set to the theoretical maximum value allowed by the diagnostic interface (such as DoIP, CAN FD) hardware.

[0063] Data block length: Use the maximum allowed length (e.g., 4096 bytes) to reduce the number of requests / responses.

[0064] Timing parameters: Use the most aggressive timeout (e.g., P2* Timeout: 25ms) to quickly determine failure.

[0065] Retry count: Set to minimum (1-3 times). If it fails, abandon the process immediately and let the upper-level process handle it, avoiding wasting time by repeatedly retries a single error block.

[0066] (4) Optimization strategy: Enable multi-threaded parallel writing, sending data to all controllers simultaneously; enable aggressive data compression, sacrificing a small amount of CPU time for less data transfer; skip certain unnecessary pre-check steps (such as detailed version number comparison, as the production line version is fixed).

[0067] 2. Balanced Mode: (1) Design goal: to achieve the optimal balance between speed and reliability and ensure a high success rate.

[0068] (2) Applicable scenarios: after-sales repair workshops and 4S stores. The vehicle network environment is uncertain (there may be slight interference), and the vehicle is powered by a battery.

[0069] (3) Specific parameter configuration: Transmission rate: Set to a high but conservative value (e.g., 80% of high-speed mode) to avoid overloading an unstable network; Data block length: Use a medium length (e.g., 1024 bytes) to balance efficiency and fault tolerance; Timing parameters: Use a standard or slightly longer timeout (e.g., P2* Timeout: 50ms) to give the controller sufficient processing time; Number of retry attempts: Set to medium-high (8-12 times); when encountering momentary network fluctuations, automatic retry can self-repair and prevent the entire process from being interrupted by minor errors.

[0070] (4) Optimization strategy: Enable full pre-inspection functions (network health, voltage detection) to detect risks in advance; enable data verification and caching mechanisms, but not necessarily the highest level of compression.

[0071] 3. Robust Flash Mode (1) Design goal: To ensure the reliability of data transmission under extreme conditions, speed is a secondary consideration.

[0072] (2) Applicable scenarios: after serious problems are diagnosed in the vehicle network, in old vehicles or during the laboratory debugging stage.

[0073] (3) Specific parameter configuration: Transfer rate: Set to a lower value; Data block length: Using the minimum data block size (such as 256 bytes or even lower) results in low retransmission costs even if a single frame is lost; Timing parameters: Use a very lenient timeout (e.g., P2* Timeout: 200ms); Number of retries: Set to the maximum (20+ times).

[0074] (4) Optimization strategy: After each transmission, a short delay can be added to allow the bus to be completely idle; record detailed communication logs for analysis of difficult problems.

[0075] In addition to the preset fixed flashing modes in the diagnostic device, this embodiment also supports the creation of custom modes. This allows advanced users (such as development engineers and technical experts) to create a completely customized configuration set based on the aforementioned parameters and save it as a "custom mode" for later use, providing significant flexibility. Furthermore, the diagnostic device can go a step further by automatically running a simplified network test before the user selects a mode. Based on the test results (such as the number of error frames), it intelligently recommends the most likely applicable mode on the interface (e.g., if good network quality is detected, the high-speed mode is recommended), thereby assisting the operator in making a decision.

[0076] In practice, a clear and intuitive mode selection drop-down menu or tab group should be set up in the main flashing interface of the diagnostic device software. This control is located at the beginning of the flashing process, usually after "Select Controller" and "Load Data File" and before "Start Flashing". Each mode has a clear icon and text description to help the operator quickly understand its applicable scenarios. After selecting a mode, the software interface can change dynamically, for example, highlighting the parameter settings most relevant to that mode.

[0077] This embodiment also constructs a controller flashing optimization system based on UDS, using the aforementioned controller flashing optimization method based on UDS. The system includes a diagnostic device and at least one controller, which are used to execute a computer program constructed according to the aforementioned controller flashing optimization method based on UDS.

[0078] 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 controller flashing optimization method based on UDS, characterized in that: The method includes the following steps: Step S1: The diagnostic device acquires the raw flashing data and performs preprocessing optimization, which includes data compression, verification, and calculation. Step S2: Optimize the UDS communication protocol between the diagnostic device and the controller, including introducing multi-threaded transmission technology, optimizing the data frame format of the diagnostic device, and upgrading the protocol stack of the controller. Step S3: Establish a buffer on the controller side and adopt an optimized buffer management mechanism and interrupt handler; Step S4: Design an intelligent flashing process, including intelligent detection before flashing, real-time monitoring and intelligent fault tolerance during flashing, and log recording and report generation after flashing. Step S5: Establish a flashing / writing mode switching mechanism on the diagnostic device.

2. The controller flashing optimization method based on UDS according to claim 1, characterized in that: Step S1 includes: Step S11: The diagnostic device automatically reads the original flashing data to be flashed according to the user's selection; Step S12: The diagnostic device uses a preset data compression algorithm to compress the original write data; Step S13: After compression is complete, calculate the checksum of the compressed data; Step S14: Encapsulate the compressed data and its calculated checksum according to a preset format to form a complete flash data packet.

3. The controller flashing optimization method based on UDS according to claim 1, characterized in that: In step S2, the introduced multi-threaded transmission technology, through dynamic thread pool management and concurrent session management, enables the diagnostic device to establish independent UDS communication sessions with multiple controllers simultaneously, achieving parallel writing of multiple controllers, wherein: Dynamic thread pool management: Based on the number of threads configured by the user, a corresponding number of independent transmission threads are created and initialized to form a thread pool; each thread is allocated a dedicated communication handle, memory resources, and state machine; Concurrent session management: Each thread in the thread pool independently executes the complete UDS writing process with its corresponding target controller; the diagnostic device is equipped with a main thread to monitor the running status of all sub-threads in the thread pool, and displays the running status of each sub-thread to the operator in the form of a dashboard or list through the software interface, realizing the visual management of multi-thread status.

4. The controller flashing optimization method based on UDS according to claim 1, characterized in that: In step S2, the optimization of the data frame format at the diagnostic device end includes: Frame structure reconstruction: The core of reconstructing traditional UDS transmission frames is to expand the effective payload and simplify redundant information at the beginning and end of the frame. Adaptive frame verification: For the reconstructed frame structure, the calculation range and algorithm of the frame verification sequence are adjusted synchronously. The diagnostic device dynamically calculates the CRC check value according to the reconstructed frame structure and packages the new CRC check value together with the reconstructed frame structure.

5. The controller flashing optimization method based on UDS according to claim 4, characterized in that: In step S2, the controller-side protocol stack upgrade includes: Dual-mode parsing capability development: Upgrade the controller's bootloader software to enable dual-mode parsing capability, that is, the controller can identify the specific flag bits in the frame header to determine whether the received frame is in the traditional format or the reconstructed format, and automatically call the corresponding parsing routine. Establish an efficient data extraction mechanism: used to identify and extract the payload field from the reconstructed frame structure, and at the same time, perform frame verification; Flow control coordination: The controller-side protocol stack still uses the ISO TP flow control protocol.

6. The controller flashing optimization method based on UDS according to claim 1, characterized in that: An optimized cache management mechanism refers to establishing a cache management algorithm based on the cache area, including: Data reception and storage: After the data frame received by the controller from the communication interface is parsed, its payload data is sequentially stored in the buffer area, and the write pointer is updated at the same time. Real-time status monitoring: The controller continuously calculates the current utilization rate of the buffer through a low-priority background task or timer interrupt: Utilization rate = (write pointer - read pointer) / total buffer size × 100%; Threshold triggering mechanism: Preset usage rate trigger threshold; Batch write operation: When the usage rate exceeds the trigger threshold, a batch write task is triggered, that is, the Flash driver is triggered to program all the data in the current buffer from the read pointer to the write pointer as a continuous data block into the specified address of the Flash memory at once; Buffer reset: After a batch write is successful, the read / write pointers are reset, the buffer is cleared, and it is ready to receive the next batch of data.

7. The controller flashing optimization method based on UDS according to claim 6, characterized in that: In step S3, the optimization of the interrupt handler includes increasing the interrupt response priority and simplifying the interrupt service routine (ISR), wherein: Increase interrupt response priority: Set the interrupt priority of the communication peripheral in the controller responsible for receiving data frames to one of the highest levels; Simplify interrupt service routines: Used to remove time-consuming operations from interrupt service routines, retaining only the most critical and indispensable operations.

8. The controller flashing optimization method based on UDS according to claim 1, characterized in that: In step S4: The intelligent detection before flashing includes: before flashing, the diagnostic equipment first performs a comprehensive detection of the vehicle's network status and controller status, and dynamically adjusts the flashing parameters based on the detection results. The parameters include the transmission rate and the number of retries. The real-time monitoring and intelligent fault tolerance in the flashing process include: during the flashing process, the flashing progress and data transmission status are monitored in real time. Once an abnormality is detected, the flashing is immediately paused and fault diagnosis and repair are performed. After the repair is completed, the flashing continues from the pause point to avoid wasting time by restarting the flashing process. The logging and report generation after flashing includes: recording the entire process of detection, adjustment, flashing, pausing, and recovery in detail in a log file, and automatically generating a report containing work data of the flashing process, including vehicle VIN, version before flashing, version after flashing, detection results, time taken, and whether there are any abnormalities.

9. The controller flashing optimization method based on UDS according to claim 1, characterized in that: In step S5, the flashing mode switching mechanism refers to pre-setting multiple flashing modes and configuring corresponding parameters on the diagnostic device. When flashing is required, the operator selects the corresponding flashing mode on the diagnostic device according to different scenarios, and the diagnostic device automatically calls the parameter configuration of the corresponding flashing mode to execute the flashing task.

10. A controller flashing optimization system based on UDS, using a controller flashing optimization method based on UDS according to any one of claims 1-9, characterized in that: The system includes a diagnostic device and at least one controller, the diagnostic device and at least one controller being used to execute a computer program constructed according to any one of claims 1-9 of a UDS-based controller writing optimization method.

Images