Vehicle flashing control method, computer equipment and computer storage medium

Abstract

The embodiment of the invention discloses a vehicle flashing control method, computer equipment and a computer storage medium. According to the embodiment of the invention, the data body of the flash file is not transmitted by using the communication service of a communication protocol, but the storage position information and the related control instruction of the flash file are transmitted by using the communication service, so that the vehicle control device is guided to autonomously acquire the file data from the specified high-speed storage position. Through the separated design of a control instruction and data transmission, an acquisition path of a flash file is sent to a vehicle control device in an instruction form, so that the vehicle control device autonomously pulls the file from a high-speed external storage medium or an internal domain controller cache, bandwidth limitation and storage pressure when a traditional diagnosis bus transmits a large file are thoroughly avoided, and the reliability of the diagnosis bus is improved. The flashing efficiency is greatly improved; and the dependence on hardware resources is reduced.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of vehicle diagnosis, in particular to a vehicle flashing control method, a computer device and a computer storage medium. BACKGROUND

[0002] In the field of automotive electronics and diagnosis, flashing refers to the process of writing new program files (such as software packages for repairing vulnerabilities, adding functions, and improving performance) into various controllers (ECUs) of a vehicle through specific tools (such as diagnostic devices / host computers) and communication protocols (such as UDS unified diagnostic services).

[0003] With the development of vehicle systems and DoIP technology, the content of the automotive diagnostic flashing file is becoming larger and larger, and there are higher requirements for transmission and storage. In the process of flashing the automotive electronic control unit (ECU), the increasing size of the flashing file leads to insufficient on-board storage space and low diagnostic transmission efficiency. The traditional flashing process relies on UDS diagnostic services (such as services 34 and 38) to transmit the entire file content on the diagnostic bus, which not only occupies a large amount of temporary storage space of the ECU, but also may cause flashing failure in the case of large files, and the transmission takes a long time. SUMMARY

[0004] Embodiments of the present application provide a vehicle flashing control method, a computer device and a computer storage medium, which utilize communication services to transmit storage location information and related control instructions of the flashing file, and guide the vehicle control device to autonomously obtain file data from the specified high-speed storage location, thereby completely avoiding the bandwidth limitation and storage pressure of traditional diagnostic bus transmission of large files.

[0005] The first aspect of the embodiments of the present application provides a vehicle flashing control method, which is applied to a diagnostic device; the method comprises:

[0006] establishing a communication link with a vehicle control device based on a preset communication protocol; the communication protocol comprises a plurality of communication services; the plurality of communication services are used to transmit file content;

[0007] determining storage location information of a target flashing file used for flashing the vehicle control device;

[0008] sending a service instruction corresponding to a target communication service to the vehicle control device based on the communication link, the service instruction being used to indicate the storage location information of the target flashing file, the target communication service being any one of the plurality of communication services, so that the vehicle control device obtains the target flashing file from the storage space indicated by the storage location information of the target flashing file for programming operation.

[0009] The second aspect of the embodiment of the present application provides a vehicle flashing control method, the method is applied to a vehicle control device; the method comprises:

[0010] establishing a communication link with a diagnosis device based on a preset communication protocol; the communication protocol comprises a plurality of communication services; the plurality of communication services are used for transmitting file content;

[0011] receiving service instructions corresponding to a target communication service sent by the diagnosis device based on the communication link, the service instructions being used for indicating storage location information of a target flashing file, the target communication service being any one of the plurality of communication services;

[0012] obtaining the target flashing file from a storage space indicated by the storage location information of the target flashing file, and performing a programming operation based on the target flashing file.

[0013] The third aspect of the embodiment of the present application provides a computer device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the method of the first aspect or the second aspect when executing the computer program.

[0014] The fourth aspect of the embodiment of the present application provides a computer storage medium, the computer storage medium stores instructions, and the instructions make the computer execute the method of the first aspect or the second aspect when the computer executes the instructions.

[0015] From the above technical solutions, the embodiment of the present application has the following advantages:

[0016] The embodiment of the present application is not used for transmitting the data body of the flashing file by using the communication service of the communication protocol, but is used for transmitting the storage location information of the flashing file and related control instructions by using the communication service, and guiding the vehicle control device to independently obtain file data from a specified high-speed storage location. Through the separation design of the control instructions and the data transmission, the obtaining path of the flashing file is sent to the vehicle control device in the form of instructions, so that the vehicle control device independently pulls the file from the high-speed external storage medium or the internal domain controller cache, completely avoids the bandwidth limitation and storage pressure when a large file is transmitted through the traditional diagnosis bus, greatly improves the flashing efficiency and reduces the dependence on hardware resources. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 It is a network framework schematic diagram in the embodiment of the present application;

[0018] Figure 2 It is a flowchart of a vehicle flashing control method in the embodiment of the present application;

[0019] Figure 3 It is another flowchart of a vehicle flashing control method in the embodiment of the present application;

[0020] Figure 4 Figure 1 is a schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0021] The vehicle flashing control method, computer device and computer storage medium provided by the embodiments of the present application use a communication service to transmit storage location information and related control instructions of a flashing file, and guide a vehicle control device to autonomously acquire file data from a specified high-speed storage location, thereby completely avoiding bandwidth limitation and storage pressure when a large file is transmitted through a traditional diagnostic bus.

[0022] The vehicle flashing control method according to the embodiments of the present application is described below.

[0023] Referring to Figure 1 The network framework in the embodiments of the present application includes:

[0024] The diagnostic device and the vehicle control device can establish a communication link through a preset communication protocol.

[0025] The network topology of the embodiments of the present application is a command network and multiple optional high-speed data networks. In the physical / data link layer, the diagnostic device still retains a traditional diagnostic bus interface, which is used to establish a basic connection and send control instructions. Optionally, the diagnostic device can also configure a shared file path through Ethernet.

[0026] The communication protocol can be a control class communication protocol based on a unified diagnostic service (UDS) and a data class communication protocol based on a file transfer protocol (such as FTP, TFTP or a custom high-speed file transfer protocol), and the embodiments of the present application do not limit the communication protocol as long as communication between the two can be achieved.

[0027] The vehicle control device can be an ECU, which retains a diagnostic bus interface for receiving control instructions and feedback states. The vehicle control device can add and use an additional high-speed data interface, such as a USB Host interface for directly reading a U disk, an Ethernet interface for accessing an OTA cache or a workshop shared server, and other high-speed internal buses, such as Ethernet / IP, for acquiring a downloaded file from other domain controllers (such as a central gateway) in the vehicle.

[0028] The communication channels of the two include: a control channel, such as a traditional diagnostic bus, which is used to transmit “meta-instructions”, such as session control, security access, file path, signature information, process command, etc., and has a small data volume; and a data channel, i.e., an external high-speed channel, such as USB, Ethernet, CAN FD / Ethernet, etc., which is specially used to transmit “data body”, i.e., a large flashing file itself.

[0029] The data flow based on this network framework is as follows: In the control flow, the diagnostic device initiates and controls the entire flashing process through the diagnostic bus, and sends an instruction packet containing "file storage location information" through the communication service of the UDS protocol; Instruction parsing, the vehicle control unit receives the instruction through the diagnostic bus, parses out the method of obtaining the flashing file and the method of verifying the flashing file; Autonomous data retrieval, the vehicle control unit actively switches to the corresponding high-speed data interface (such as mounting a USB flash drive, accessing a network path), and autonomously and at high speed reads the complete flashing file into its internal storage; Result feedback, after the vehicle control unit completes the autonomous flashing, it reports the flashing result to the diagnostic device through the diagnostic bus.

[0030] Therefore, the advantages of the above architecture lie in its decoupling and high efficiency. Control and data are separated, freeing the diagnostic bus from heavy data transfer and allowing it to handle only lightweight commands with greater responsiveness. Secondly, it utilizes high-performance channels; file transfer leverages the vehicle's existing or specially designed high-speed data channels (USB 2.0 / 3.0, 100 / 1000BASE-T1 Ethernet), offering orders of magnitude speed improvement over traditional diagnostic buses (typically <1Mbps). Simultaneously, it reduces the cache pressure on the vehicle control unit, allowing it to stream and process files via the data channel without needing to cache the entire file in RAM, significantly reducing the need for temporary storage. Furthermore, it offers high flexibility, supporting various data sources such as USB drives, network sharing, and OTA (Over-The-Air) updates, adapting to different scenarios including production, after-sales service, and remote operations.

[0031] The following is combined with Figure 1 The network framework described herein is used to illustrate the vehicle flashing control method in the embodiments of this application:

[0032] Please see Figure 2 One embodiment of the vehicle flashing control method in this application includes:

[0033] 201. Establish a communication link with the vehicle control device based on a preset communication protocol; the communication protocol includes multiple communication services; the multiple communication services are used to transmit file content;

[0034] The method in this embodiment can be applied to diagnostic equipment. The diagnostic equipment can establish an initial communication connection with the diagnostic interface of a vehicle control device via a traditional diagnostic bus (such as a CAN / LIN bus), complete session mode switching (such as switching from a default session to an extended diagnostic session) and secure access authentication (such as verifying identity and permissions through a seed-key mechanism), ensuring the security and legitimacy of the communication link. The multiple communication services may include diagnostic session control services, secure access services, communication control services, data transmission services, etc., as defined in the UDS protocol. Some of these services (such as data transmission services) can be used to transmit the main content of the flashing file.

[0035] 202. Determine the storage location information of the target flashing file used to flash the vehicle control device;

[0036] The diagnostic device can locate the target flashing file in local storage media (such as an internal hard drive or an external USB flash drive) or network shared storage (such as a workshop server or cloud storage) and obtain its specific storage path. For example, the local path is " / Diagnostic / Files / ECU_Update_V1.2.bin", the network path is "ftp: / / 192.168.1.100 / CarFiles / Engine_ECU.bin", or the USB flash drive mount path is " / mnt / usb1 / ECU_Firmware.bin".

[0037] Meanwhile, the diagnostic equipment can extract additional information about the target flash file, including the file's unique identifier, version number, compatible vehicle control device model, and checksum (such as a checksum generated based on hash algorithms like CRC32 and SHA256). This information is then integrated with the storage location information into structured data for subsequent transmission to the vehicle control device.

[0038] The target flash file can be uploaded to the local storage medium via a storage medium that already stores the target flash file, or it can be downloaded to the local storage medium from a network shared storage via OTA technology. This embodiment does not limit the method of obtaining the target flash file.

[0039] 203. Send a service instruction corresponding to the target communication service to the vehicle control device based on the communication link. The service instruction is used to indicate the storage location information of the target flashing file. The target communication service is any one of the plurality of communication services, so that the vehicle control device can obtain the target flashing file from the storage space indicated by the storage location information of the target flashing file and perform programming operations.

[0040] The diagnostic equipment selects any target communication service in the communication protocol, encapsulates the integrated storage location information and additional information into a service instruction according to the communication protocol data format, such as using the transmission data service with service ID 0x31 of the UDS protocol to generate a service instruction, and sends the service instruction to the vehicle control device.

[0041] Therefore, this embodiment no longer uses the communication service of the communication protocol to transmit the data body of the flash file. Instead, it utilizes the communication service to transmit the storage location information of the flash file and related control commands, guiding the vehicle control device to autonomously retrieve the file data from the designated high-speed storage location. Through the separation design of control commands and data transmission, the acquisition path of the flash file is sent to the vehicle control device in the form of commands, enabling it to autonomously pull the file from a high-speed external storage medium (such as a USB flash drive, vehicle Ethernet shared server) or internal domain controller cache. This completely avoids the bandwidth limitations and storage pressure when transmitting large files on the traditional diagnostic bus, significantly improving flashing efficiency and reducing hardware resource dependence.

[0042] For example, when the target file to be flashed is a 5GB vehicle controller firmware package, the traditional method requires nearly 3 hours of transmission via the CAN bus at a rate of 500kbps, and the ECU needs to reserve at least 5GB of temporary RAM space. In this embodiment, the diagnostic device only needs to send a service command containing the storage location of the flashing file (data size less than 100 bytes). According to the instructions of the service command, the vehicle control device can complete the file download within 40 seconds via the vehicle Ethernet at a rate of 1Gbps, and can directly write it to the Flash storage area without occupying additional RAM space, which greatly improves the flashing efficiency and reduces hardware resource dependence.

[0043] The following will be discussed in the preceding text. Figure 2 Based on the illustrated embodiments, embodiments of this application will be described in further detail. Please refer to [link to relevant documentation]. Figure 3 Another embodiment of the vehicle flashing control method in this application includes:

[0044] 301. Establish a communication link with the diagnostic device based on a preset communication protocol; the communication protocol includes multiple communication services; the multiple communication services are used to transmit file content;

[0045] The method of this embodiment can be applied to vehicle control devices. The vehicle control device establishes a physical connection with the diagnostic device through its built-in diagnostic bus interface (such as a CAN / LIN interface), and then completes link initialization based on a preset communication protocol: First, it responds to the session control command sent by the diagnostic device (such as UDS service 0x10) and enters the extended diagnostic session mode; then, it completes key verification with the diagnostic device through a secure access process (such as UDS service 0x27) to ensure the security of the communication link; finally, it establishes a stable bidirectional communication link, wherein the preset communication protocol includes control services (such as session management, secure access, and service command transmission) and data services (such as file content transmission), which can be used for subsequent command interaction.

[0046] 302. Receive a service instruction corresponding to the target communication service sent by the diagnostic device based on the communication link. The service instruction is used to indicate the storage location information of the target write file, and the target communication service is any one of the plurality of communication services.

[0047] The vehicle control unit continuously monitors the command transmission of the diagnostic equipment through the diagnostic bus interface. When a service frame corresponding to the target communication service (such as the transmission data frame of UDS service 0x31) is detected, it is parsed: First, the legality of the service frame format (such as frame length and checksum) is verified. If it is legal, the storage location information encapsulated in the frame is extracted. This information may include the storage medium type identifier (such as 0x01 representing USB storage, 0x02 representing the vehicle Ethernet shared path, and 0x03 representing the internal domain controller cache), specific path parameters (such as the mount point of USB storage " / mnt / usb0 / " + file name "ECU_V2.1.bin", or the IP address of the Ethernet path "192.168.0.5" + shared directory " / Firmware / Engine / " + file name), and additional file information (such as file size, version number, and SHA256 checksum).

[0048] Optionally, after parsing is complete, the vehicle control unit can send a "command received successfully" response frame to the diagnostic device via the diagnostic bus (such as the positive response corresponding to UDS service 0x7F).

[0049] 303. Obtain the target flash file from the storage space indicated by the storage location information of the target flash file, and perform programming operations based on the target flash file;

[0050] The diagnostic equipment sends the service command to the vehicle control unit via the established communication link. Upon receiving the service command, the vehicle control unit parses the storage location type and specific path. Based on the media type identifier in the storage location information, the vehicle control unit calls the corresponding high-speed data interface: if identified as USB storage, it activates its USB Host interface, detects and mounts the external USB flash drive, reads the target flash file according to the parsed path, and simultaneously verifies in real time whether the file size in bytes matches the file size in the additional information; if identified as a vehicle Ethernet shared path, it switches to the Ethernet interface, establishes a connection with the server at the specified IP address based on the TCP / IP protocol, downloads the target flash file via the FTP / TFTP protocol, and performs CRC verification on each data segment during the download process; if identified as an internal domain controller cache, it sends a file request to the domain controller via the vehicle's internal high-speed bus (such as Ethernet / IP) and receives the target flash file pushed by the domain controller.

[0051] During the process of acquiring the flashing file, the vehicle control unit can verify in real time whether the file's checksum and size are consistent with the information in the service command, ensuring the file's integrity and correctness. After the verification is successful, the internal programming operation is initiated to write the flashing file into its own storage unit (such as Flash memory). Once completed, the flashing success status information is sent to the diagnostic device via the communication link.

[0052] Throughout the acquisition process, the vehicle control unit can temporarily store the file data in its own high-speed cache (such as DDR memory) to avoid occupying diagnostic bus bandwidth.

[0053] After obtaining the target flash file, the programming operation can begin. The vehicle control unit will erase, write, and verify its own storage area according to the preset programming process: First, the built-in Flash erasure module is called to perform sector erasure on the target storage partition (such as the firmware storage area of ​​the ECU) to ensure that the old data is completely cleared; then, the file writing process is started, and the obtained target flash file is written to the erased storage partition in blocks, while recording the write address and check value of each block of data; after the writing is completed, the full file verification mechanism is triggered, the hash value of the written data is recalculated using the SHA256 algorithm, and compared with the check code in the service command. If the two match, the programming is considered successful; if they do not match, the retry process is automatically triggered (the corresponding sector is erased again before each retry).

[0054] Optionally, during the programming process, the vehicle control device also provides real-time progress information (such as "erasure progress 20%", "write progress 50%", "verification in progress") to the diagnostic equipment via the control channel. If an abnormality occurs (such as erasure timeout, write error, verification failure), a fault code (such as "0x10: erasure failure" or "0x20: file verification error") is immediately sent and the operation is terminated, awaiting further instructions from the diagnostic equipment.

[0055] Therefore, this embodiment no longer uses the communication service of the communication protocol to transmit the data body of the flash file. Instead, it utilizes the communication service to transmit the storage location information of the flash file and related control commands, guiding the vehicle control device to autonomously retrieve the file data from the designated high-speed storage location. Through the separation of control commands and data transmission, the acquisition path of the flash file is sent to the vehicle control device in the form of commands, enabling it to autonomously pull the file from the high-speed external storage medium or the internal domain controller cache. This completely avoids the bandwidth limitations and storage pressure when transmitting large files on the traditional diagnostic bus, significantly improving flashing efficiency and reducing hardware resource dependence.

[0056] based on Figure 2 and Figure 3 In the illustrated embodiment, optionally, the diagnostic device can calculate a checksum for the target flash file according to a preset encoding algorithm to obtain an initial checksum corresponding to the target flash file, and encapsulate the initial checksum in a service instruction. The vehicle control device can then verify the integrity of the target flash file based on this initial checksum. Specifically, the vehicle control device can calculate a checksum for the target flash file according to a preset encoding algorithm to obtain a target checksum corresponding to the target flash file, and perform integrity verification on the target flash file based on the initial checksum and the target checksum carried in the service instruction. If the initial checksum and the target checksum match, programming operations are performed based on the target flash file; if the initial checksum and the target checksum do not match, a response message indicating that the integrity verification of the target flash file failed is returned to the diagnostic device.

[0057] For example, after the vehicle control unit reads all the data of the target file to be written, it can perform integrity verification based on the SHA256 checksum in the supplementary information: the actual SHA256 value of the file is calculated by the built-in hash algorithm module and compared with the checksum in the supplementary information; if the two match, the file is determined to be complete and the program is ready to proceed to the programming stage; if they do not match, a "file corrupted" fault response is sent to the diagnostic device through the diagnostic bus, and the device waits for a retry instruction. During the retry, the storage location information can be resent, or the vehicle control unit can be instructed to replace the storage medium to obtain the file.

[0058] Therefore, integrity verification can effectively avoid file incompleteness caused by packet loss, data tampering, or storage media damage during the flashing process, thus ensuring the reliability of the flashing operation from the source.

[0059] For example, if some bytes of the target flash file are lost during storage on a USB flash drive due to a loose USB interface, the target checksum calculated by the vehicle control unit will be inconsistent with the initial checksum in the service command. In this case, the vehicle control unit will immediately terminate the programming process and report an exception, preventing the incomplete firmware from being written to the storage unit. This avoids the risk of functional failure or even hardware damage to the vehicle control unit due to running incorrect firmware. Furthermore, this integrity verification mechanism does not rely on additional detection from external devices; it can be completed using the vehicle control unit's own computing power, further simplifying the flashing process and enhancing its ability to autonomously handle abnormal situations.

[0060] Optionally, the vehicle control unit may return the flashing and programming results based on the target flashing file to the diagnostic device via a communication link. The flashing and programming results may include information indicating whether the programming operation was successful, firmware version information, and programming time, or may include fault information that caused the programming operation to fail.

[0061] For example, after the programming operation is completed, the vehicle control unit can generate a result report based on the flashing and programming results returned by the diagnostic equipment: if the programming is successful (overall verification passed), the report includes information such as "operation successful", new firmware version number, and programming time; if the programming fails (e.g., integrity verification fails, write error), the report includes information such as fault type code, fault occurrence stage (e.g., file acquisition stage, programming stage), and suggested troubleshooting directions. The result report is then encapsulated into a response frame and sent to the diagnostic equipment via the diagnostic bus. Upon receiving the frame, the diagnostic equipment can display the results or trigger subsequent processing (e.g., re-initiating the flashing process).

[0062] The following describes an exemplary application scenario of the method of this application embodiment, using a diagnostic instrument and an ECU as examples, and further details the technical solution of this application embodiment by listing the process steps:

[0063] Step 1: Enter the pre-programming stage;

[0064] The core purpose of this step is to establish a stable and secure flashing environment. The diagnostic tool first requests the ECU to switch from the default session to the extended diagnostic session via the UDS 0x10 diagnostic session control service. In this session, the ECU performs a series of environment preparation operations: suppressing unnecessary periodic communication messages to prevent excessive bus load from affecting critical command transmission; checking vehicle status to ensure safety conditions such as zero vehicle speed and the ignition switch being in the ON position but the engine not running; and possibly backing up volatile data or disabling some non-core functions. This stage does not involve specific file operations but rather lays the foundation for subsequent high-risk programming actions, ensuring the system is in a controllable, ready-to-go state.

[0065] Step 2: Switch to the programming session and gain secure access;

[0066] Once the environment is ready, the diagnostic tool needs to obtain higher operating privileges. First, use the 0x10 service again to switch the ECU session mode from extended diagnostic session to programming session. This is the highest-privilege diagnostic mode for the ECU, and writing to memory is typically only allowed in this mode.

[0067] Subsequently, the 0x27 secure access service is executed to authenticate the user, which is a core checkpoint to prevent unauthorized flashing. The process employs a "challenge-response" mechanism: the diagnostic tool requests a pseudo-randomly generated seed from the ECU; the diagnostic tool uses a pre-agreed encryption algorithm (such as based on a shared key) with the ECU to calculate a key from the seed; the diagnostic tool then sends this key to the ECU.

[0068] The ECU internally executes the same algorithm for verification. If the key matches, the flashing and reprogramming privileges are unlocked.

[0069] Step 3: Enter the diagnostic flushing routine control;

[0070] After secure unlocking, the diagnostic tool needs to activate the low-level software module inside the ECU specifically for flashing. This is achieved through the UDS 0x31 routine control service.

[0071] Specifically, the diagnostic device can send a startup routine request to the vehicle control unit based on the communication link between the device and the vehicle control unit. The startup routine request carries a routine identifier corresponding to the flashing program, so that the vehicle control unit can execute the routine corresponding to the routine identifier to enter the flashing ready state.

[0072] For example, the diagnostic tool sends a "start routine" request, which includes a specific routine identifier. This identifier corresponds to a pre-installed firmware program within the ECU used for erasing Flash memory, writing data, and verification. After executing this routine, the ECU's software officially enters the "ready to receive data / instructions" stage. At this point, the ECU's memory controller, Flash driver, and other hardware resources are configured to be programming-ready, awaiting subsequent service instructions from the diagnostic tool and the acquisition of the flash file based on those instructions.

[0073] Step 4: A fundamental shift in the way core data is transmitted;

[0074] 1. Sending "File Storage Location Information" instead of "File Data": The diagnostic tool still initiates the 0x34 / 0x38 service, but its parameters indicate that the subsequent transmission is not of the file content, but a set of "metadata". Next, the diagnostic tool sends the 0x36 service, but its data field no longer contains program code; instead, it loads an "information packet" pointing to the file to be flashed. The specific content of the "information packet": This information packet precisely tells the ECU how to obtain the file itself. Its structured information may include: the type and address of the data source where the file to be flashed is located, access credentials (such as the username / token required to access the network path), security verification information (such as the expected hash value of the file (such as SHA-256) or digital signature for subsequent verification by the ECU), and file attributes (such as the exact file size, format, etc.).

[0075] 2. ECU Role Transformation: After receiving this "information packet," the ECU's task changes from "passively receiving data" to "actively executing the acquisition task." Based on instructions, it calls the corresponding underlying drivers (USB host driver, TCP / IP protocol stack, file system driver) to access the specified source and independently reads the entire file into its controllable memory area. The diagnostic bus is thus freed up during this process.

[0076] Step 5: Optional instruction reception confirmation;

[0077] This step is a robust design feature to ensure that critical commands have been reliably received and understood by the ECU.

[0078] This step involves the diagnostic device sending a service command corresponding to the data transmission service among the multiple communication services in the aforementioned communication protocol to the vehicle control unit. The vehicle control unit then responds to the service command for the data transmission service by returning a response message.

[0079] For example, after sending a service command containing information about the file storage location to be written, the diagnostic tool can (optionally) send a 0x36 service request with an empty data field or only a padding value.

[0080] This "empty" request is essentially a handshake confirmation to the ECU. If the ECU has successfully received and parsed the previous substantive instruction, it should return a positive response, equivalent to the ECU replying "Instruction parsing complete, ready to execute file retrieval operation"; if the ECU returns a negative response, it indicates that there may have been a problem with the previous instruction transmission, and the process needs to be rolled back or an error message needs to be reported. This step enhances fault tolerance in unreliable communication environments.

[0081] Step 6: Officially end the command phase and trigger autonomous ECU operation;

[0082] This step marks the official closure of the "command transmission phase" and triggers the ECU to begin the subsequent complete workflow.

[0083] 1. Send 0x37 service: After receiving the positive response of 0x36 in the previous step (or directly after the previous step), the diagnostic tool immediately sends 0x37 to request to exit the transfer service.

[0084] 2. ECU Response and Action: The ECU responds positively to this 0x37 service. This positive response has a dual meaning: for the diagnostic tool, it means that the "command transmission phase" has been correctly completed according to the protocol; for the ECU itself, this is often an internal trigger. Upon receiving 0x37, the ECU's flashing control logic will understand: "All external commands have been issued. Now, immediately initiate the complete autonomous process of obtaining the flashing file according to the received commands, and performing subsequent verification and installation."

[0085] Step 7: Dependency check, file verification and installation;

[0086] This step is crucial to the quality and safety of the flashing operation, and it occurs after the ECU has autonomously acquired the necessary files.

[0087] 1. Diagnostic Tool Dependency Check: The diagnostic tool does not directly participate in the installation but performs an independent "pre-installation audit." It queries the ECU for key information such as the current hardware part number, hardware version, and software version via UDS services (e.g., 0x22 read data identifier). Simultaneously, the diagnostic tool (or its backend system) verifies whether this ECU information meets the operating requirements of the new software based on the bill of materials information included in the flashing file. This includes: hardware compatibility, ensuring the ECU hardware version supports the new software; software dependencies, ensuring the versions of other related software modules within the current ECU match the new software to prevent system failures due to version conflicts; and configuration dependencies, checking whether the necessary vehicle configuration parameters are ready.

[0088] 2. ECU File Verification: In parallel with the diagnostic tool's check, the ECU performs a high-security level local verification of the acquired complete flash file in its memory. This includes:

[0089] Integrity verification: First, the ECU calculates the hash value of the file (such as SHA-256) and compares it with the hash value previously transmitted by the diagnostic tool via the 0x36 service to ensure that there are no bit errors or data corruption in the file during transmission or reading.

[0090] Authenticity verification (digital signature): This is crucial for tamper prevention. The ECU uses a pre-stored "public key" in its secure storage to decrypt and verify the "digital signature" attached to the flashing file. This signature is generated by the software vendor using the corresponding "private key." Only after successful signature verification can it be proven that the file is of reliable origin, has not been tampered with, and is not malicious software.

[0091] 3. Start Flashing File Installation: Only after both of the above checks pass will the ECU initiate the actual installation program. This program is executed by its internal bootloader or flashing driver, and the core operations include:

[0092] Erase target memory sector: Erase the old program area in Flash that needs to be updated to a blank state.

[0093] Programmatic writing: The verified new file data is written to the Flash memory block by block according to the predetermined memory address.

[0094] Post-write verification: This typically uses a read-readback comparison method to ensure that the data written to Flash is completely consistent with the source data in memory, preventing errors during the programming process.

[0095] Step 8: Post-programming phase and resource cleanup;

[0096] This stage marks the completion of the main flashing process, with the goal of restoring the ECU to a normal, operational state and confirming the results.

[0097] 1. Perform an ECU reset: The diagnostic tool sends a UDS 0x11 reboot service request to the ECU to perform a soft reset. This will restart the ECU's microprocessor and boot from the newly programmed Flash area, thus making the new software effective. The reset will clear temporary data in RAM but retain non-volatile configurations.

[0098] 2. Switching Sessions and Reading Version Information: After the ECU is reset, it will automatically return to the default diagnostic session. The diagnostic tool needs to re-establish the connection. The diagnostic tool will again use service 0x22 to read key data identifiers such as the software version number and programming date. Comparing the read information with the expected new version information is the most direct evidence of successful flashing. It may also execute service 0x19 to read diagnostic fault codes to confirm that no new fault codes were generated unexpectedly during the flashing process.

[0099] 3. Exit the new transfer mode service, such as ending the file transfer sharing service or unplugging the USB flash drive.

[0100] For example, for shared file paths / OTA updates, the diagnostic tool can send a specific UDS or network command to instruct the ECU or vehicle gateway to close temporarily opened network connections or file handles. For USB flash drives, the diagnostic tool will prompt the operator that "it is safe to remove the USB flash drive." The ECU will then terminate access to the USB Mass Storage device, ensuring the data cache has been cleared, and the user can then physically remove the USB flash drive.

[0101] After all operations are completed, the diagnostic tool typically performs a full "final check," which may include checking the communication of all relevant ECUs, clearing temporary fault codes related to the flashing process, and recording the success of the flashing operation and new version information in the service log. At this point, the entire flashing process is safely and completely finished.

[0102] Therefore, by following the above steps, diagnostic equipment can be freed from its traditional role as a "file transporter," significantly reducing the load on the diagnostic bus during data transmission. Simultaneously, the active file acquisition by the ECU and local multi-dimensional verification mechanisms significantly improve the security and reliability of the flashing process. Compared to the traditional model that relies on the diagnostic bus to transmit files frame by frame, this solution not only optimizes resource utilization efficiency but also fundamentally reduces the risk of flashing failures caused by bus congestion, data packet loss, or external malicious injection through a decentralized file acquisition method and a rigorous verification process. This provides a more efficient and robust technical path for firmware updates of vehicle electronic control units.

[0103] The computer device in the embodiments of this application is described below. Please refer to [link / reference]. Figure 4 One embodiment of the computer device in this application includes:

[0104] The computer device 400 may include one or more central processing units (CPUs) 401 and a memory 405, in which one or more applications or data are stored.

[0105] The memory 405 can be volatile or persistent storage. The program stored in the memory 405 can include one or more modules, each module including a series of instruction operations on the computer device. Furthermore, the central processing unit 401 can be configured to communicate with the memory 405 and execute the series of instruction operations stored in the memory 405 on the computer device 400.

[0106] Computer device 400 may also include one or more power supplies 402, one or more wired or wireless network interfaces 403, one or more input / output interfaces 404, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0107] The central processing unit 401 can perform the aforementioned... Figure 2 Diagnostic device or in the illustrated embodiment Figure 3 The specific operations performed by the vehicle control device in the illustrated embodiment will not be described in detail here.

[0108] This application also provides a computer storage medium, one embodiment of which includes: the computer storage medium storing instructions, which, when executed on a computer, cause the computer to perform the aforementioned... Figure 2 Diagnostic device or in the illustrated embodiment Figure 3 The operation performed by the vehicle control device in the illustrated embodiment.

[0109] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0110] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0111] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0112] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0113] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A vehicle flashing control method, characterized in that, The method is applied to a diagnostic device; the method includes: A communication link with the vehicle control device is established based on a preset communication protocol; the communication protocol includes multiple communication services; the multiple communication services are used to transmit file content; Determine the storage location information of the target flashing file used to flash the vehicle control device; Based on the communication link, a service instruction corresponding to the target communication service is sent to the vehicle control device. The service instruction is used to indicate the storage location information of the target flashing file. The target communication service is any one of the plurality of communication services, so that the vehicle control device can obtain the target flashing file from the storage space indicated by the storage location information of the target flashing file and perform programming operations.

2. The method according to claim 1, characterized in that, Before sending the service instruction corresponding to the target communication service to the vehicle control device based on the communication link, the method further includes: The target file to be flashed is calculated according to a preset encoding algorithm to obtain the initial checksum corresponding to the target file to be flashed. The initial checksum is encapsulated in the service instruction so that the vehicle control device can verify the integrity of the target flash file based on the initial checksum.

3. The method according to claim 1, characterized in that, Before sending the service instruction corresponding to the target communication service to the vehicle control device based on the communication link, the method further includes: A startup routine request is sent to the vehicle control device via the communication link. The startup routine request carries a routine identifier corresponding to the flashing program, so that the vehicle control device executes the routine corresponding to the routine identifier to enter the flashing ready state.

4. The method according to claim 1, characterized in that, The method further includes: A service instruction corresponding to the data transmission service among the plurality of communication services is sent to the vehicle control device, so that the vehicle control device returns a response message in response to the service instruction of the data transmission service.

5. A vehicle flashing control method, characterized in that, The method is applied to a vehicle control device; the method includes: A communication link is established with the diagnostic device based on a preset communication protocol; the communication protocol includes multiple communication services; the multiple communication services are used to transmit file content; Based on the communication link, the diagnostic device sends a service instruction corresponding to the target communication service. The service instruction is used to indicate the storage location information of the target file to be written. The target communication service is any one of the plurality of communication services. The target flash file is obtained from the storage space indicated by the storage location information of the target flash file, and programming operations are performed based on the target flash file.

6. The method according to claim 5, characterized in that, Before performing the programming operation based on the target flash file, the method further includes: The target file to be flashed is calculated according to a preset encoding algorithm to obtain the target check code corresponding to the target file to be flashed. The integrity of the target file is verified based on the initial checksum of the target file carried in the service instruction and the target checksum. The programming operation based on the target flash file includes: If the initial verification code matches the target verification code, then the programming operation based on the target flashing file is performed; If the initial checksum does not match the target checksum, a response message indicating that the integrity verification of the target file failed is returned to the diagnostic device.

7. The method according to claim 5, characterized in that, Before receiving the service instruction corresponding to the target communication service sent by the diagnostic device based on the communication link, the method further includes: The vehicle control device sends a startup routine request via the communication link, and the startup routine request carries a routine identifier corresponding to the flashing programming. Execute the routine corresponding to the routine identifier to enter the write-ready state.

8. The method according to claim 5, characterized in that, After performing the programming operation based on the target flash file, the method further includes: The communication link is used to return the flashing and programming results based on the target flashing file to the diagnostic device. The flashing and programming results include information indicating whether the programming operation was successful, firmware version information, and programming time, or include fault information that caused the programming operation to fail.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 4 or 5 to 8.

10. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the method as described in any one of claims 1 to 4 or 5 to 8.

Images