Vehicle software flashing method and device, vehicle, storage medium and program product
By separating the vehicle controller configuration into an independent description file and building a common data transformation logic, the problems of toolchain fragmentation and redundant development are solved, resulting in cost reduction and improved robustness.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-28
- Publication Date
- 2026-03-27
Smart Images
Figure CN121742874A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of vehicle software flashing technology, and particularly relates to a vehicle software flashing method, device, vehicle, storage medium and program product. Background Technology
[0002] Currently, the industry commonly uses a process based on the Unified Diagnostic Services (UDS) protocol to update or reprogram key electronic control units (ECUs) in the vehicle's powertrain and chassis domains. This process typically requires dedicated host computer tools to communicate with the target controller for diagnostics and to complete complex data transmission and programming operations.
[0003] However, in actual R&D and production processes, existing software flashing implementation schemes have several significant problems. First, because different controllers are usually provided by different suppliers, their corresponding flashing tools also vary, requiring automakers to maintain and manage multiple incompatible dedicated toolchains, resulting in operational complexity and high costs. Finally, although the underlying flashing protocols and process standards are consistent across different controllers, each supplier needs to repeatedly develop similar upper-level computer software, leading to a significant amount of repetitive work and wasted resources from an industry-wide perspective.
[0004] Therefore, how to design a universal software flashing solution to unify the toolchain and reduce development costs has become a pressing technical problem in this field. Summary of the Invention
[0005] This application provides a vehicle software flashing method, apparatus, vehicle and computer storage medium, and program product, which can unify the vehicle software flashing toolchain and reduce flashing development costs.
[0006] On one hand, embodiments of this application provide a method for flashing vehicle software, the method comprising: Obtain the diagnostic description file, network description file, and flashing file; the diagnostic description file includes the diagnostic parameters of the target electronic control unit; the network description file includes the communication message format between the host computer and the vehicle controller local area network bus; Extract flash data from the flash file; The flash data is filled into the first data structure to obtain the first formatted data; wherein, the first data structure is determined according to the encoding format of the flash file; The first formatted data and diagnostic parameters are populated into the second data structure through the target transformation function to obtain the second formatted data; wherein, the second data structure and the target transformation function are determined according to the Unified Diagnostic Service (UDS) diagnostic protocol; The second formatted data is sent to the vehicle controller local area network bus in a communication message format to drive the target electronic control unit to complete the software flashing.
[0007] Among some possible implementations, the method also includes: Apply a preset external interference signal to the target electronic control unit or vehicle controller local area network bus; Acquire the response data of the target electronic control unit under interference; The test result is determined by comparing the response data with the preset response results.
[0008] In some possible implementations, a preset external interference signal is applied, including at least one of the following: injecting an error frame into the vehicle controller area network bus, causing power supply fluctuations to the target electronic control unit, or injecting abnormal waveforms into the hard-wired signal connected to the target electronic control unit.
[0009] In some possible implementations, before filling the second data structure with the first formatted data and diagnostic parameters through the target transformation function to obtain the second formatted data, the method further includes: Obtain the target service type for the Unified Diagnostic Service (UDS); Based on the correspondence between service types and conversion functions, determine the target conversion function corresponding to the target service type.
[0010] In some possible implementations, the target service type includes a request download service. The first formatted data and diagnostic parameters are populated into a second data structure via a target conversion function to obtain the second formatted data, which includes: Obtain the starting logical address and total data length from the first formatted data; Obtain the data format identifier and address length format identifier from the diagnostic parameters; The starting logical address, total data length, data format identifier, and address length format identifier are filled into the second data structure to obtain the second formatted data.
[0011] In some possible implementations, the target service type includes a data transfer service. The first formatted data and diagnostic parameters are populated into a second data structure via a target conversion function to obtain the second formatted data, which includes: Obtain the maximum transfer block length, wherein the maximum transfer block length is provided by the target electronic control unit in response to the request for download service; Based on the maximum transfer block length, the flush data segment in the first formatted data is divided into multiple sequentially arranged data blocks; Perform the following steps in the order the data blocks are arranged: Get the current data block to be transmitted; The current data block to be transmitted is filled into the second data structure to obtain the second formatted data for the current transmission.
[0012] On the other hand, embodiments of this application provide a vehicle software flashing device, the device comprising: The file acquisition module is used to acquire diagnostic description files, network description files, and flashing files. The diagnostic description files include diagnostic parameters of the target electronic control unit; the network description files include the communication message format between the host computer and the vehicle controller local area network bus. The data extraction module is used to extract flash data from the flash file; The first formatting module is used to fill the flash data into the first data structure to obtain the first formatted data; wherein, the first data structure is determined according to the encoding format of the flash file; The second formatting module is used to fill the first formatted data and diagnostic parameters into the second data structure through the target conversion function to obtain the second formatted data; wherein, the second data structure and the target conversion function are determined according to the Unified Diagnostic Service (UDS) diagnostic protocol; The data transmission module is used to send the second formatted data to the vehicle controller local area network bus in a communication message format to drive the target electronic control unit to complete the software flashing.
[0013] In another aspect, embodiments of this application provide a vehicle, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement a vehicle software flashing method.
[0014] In another aspect, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, a vehicle software flashing method is implemented.
[0015] In another aspect, embodiments of this application provide a computer program product in which instructions are executed by the vehicle's processor, causing the vehicle to perform a vehicle software flashing method.
[0016] The vehicle software flashing method, apparatus, vehicle, and computer storage medium of this application embodiment separate the configurations of controllers from different suppliers into independent diagnostic description files and network description files, rather than embedding them in the host computer tool. The diagnostic description file contains diagnostic parameters of the target electronic control unit, and the network description file contains the communication message format between the host computer and the vehicle controller's local area network bus. Both types of files serve as adaptation carriers and follow industry-standard specifications. For controllers from different suppliers, there is no need to develop dedicated tools. Only the corresponding standardized files need to be replaced. Combined with the first data structure determined according to the flashing file encoding format, the flashing data can be extracted and stored in a standardized manner. Adaptation can be completed through the same host computer, completely breaking the binding relationship between dedicated tools and specific supplier controllers. Furthermore, based on the UDS diagnostic protocol, the second data structure and target conversion function were determined, and a set of universal data conversion and transmission logic was constructed. This logic can cover all controllers that comply with the protocol and standard. There is no need to design separate host computer function modules for different vendors. Each vendor only needs to provide standardized files that are adapted to their own controllers, and the universal host computer can be reused to implement the writing function. This avoids the duplication of development of host computer software with similar functions from the root, and achieves the technical goals of toolchain unification and development cost reduction. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating a vehicle software flashing method provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a vehicle software flashing method provided in another embodiment of this application; Figure 3 This is a flowchart illustrating a vehicle software flashing method provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of a vehicle software flashing system provided in another embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle software flashing device provided in another embodiment of this application; Figure 6 This is a structural schematic diagram of a vehicle provided in another embodiment of this application. Detailed Implementation
[0019] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.
[0020] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or vehicle that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or vehicle. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or vehicle that includes the element.
[0021] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.
[0022] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.
[0023] Currently, although the industry has standardized the underlying flashing process of key electronic control units such as the power domain through the UDS protocol and unified enterprise standards, and clarified the commonalities of flashing logic for different controllers, since each controller is independently developed by different suppliers, suppliers only focus on the compatibility of their own products when designing supporting flashing tools, without considering the compatibility of controllers across suppliers and models. This results in a fragmented toolchain, requiring automakers to maintain multiple sets of incompatible dedicated tools, which in turn leads to problems of complex operation and high costs.
[0024] On the other hand, existing flashing solutions only focus on the implementation of the core functions of "data transmission and programming". They do not design a systematic and automated anomaly simulation and testing mechanism for uncertainties that objectively exist in the vehicle electrical environment, such as network interference, power fluctuations, and abnormal hard-wired signals. The flashing process involves key links such as controller reset, communication shutdown, and multi-frame data transmission, which have high requirements for environmental stability. The lack of targeted testing capabilities makes it impossible to fully verify the robustness of flashing and poses potential operational risks.
[0025] Furthermore, the industry has not fully utilized the common features of different controller flashing processes (such as unified UDS services and consistent data flow control rules), resulting in suppliers having to repeatedly develop similar host computer software. This leads to duplication of labor and waste of resources at the industry level, and fails to meet the urgent needs of automakers for universal tools. Therefore, designing a universal flashing solution with integrated automated testing capabilities has become a pressing technical challenge.
[0026] The vehicle software flashing method of this application separates the configurations of controllers from different suppliers into independent diagnostic description files and network description files, rather than embedding them in the host computer tool. The diagnostic description file contains the diagnostic parameters of the target electronic control unit, and the network description file contains the communication message format between the host computer and the vehicle controller's local area network bus. Both types of files serve as adaptation carriers and follow industry-standard specifications. For controllers from different suppliers, there is no need to develop dedicated tools. Only the corresponding standardized files need to be replaced. Combined with the first data structure determined according to the flashing file encoding format, the flashing data can be extracted and stored in a standardized manner. Adaptation can be completed through the same host computer, completely breaking the binding relationship between dedicated tools and specific supplier controllers. Furthermore, based on the UDS diagnostic protocol, the second data structure and target conversion function were determined, and a set of universal data conversion and transmission logic was constructed. This logic can cover all controllers that comply with the protocol and standard. There is no need to design separate host computer function modules for different vendors. Each vendor only needs to provide standardized files that are adapted to their own controllers, and the universal host computer can be reused to implement the writing function. This avoids the duplication of development of host computer software with similar functions from the root, and achieves the technical goals of toolchain unification and development cost reduction.
[0027] To address the problems of the prior art, this application provides a vehicle software flashing method, apparatus, vehicle, computer storage medium, and computer program product. The vehicle software flashing method provided in this application is described below.
[0028] Figure 1 A schematic flowchart of a vehicle software flashing method according to an embodiment of this application is shown. Figure 1 As shown, the method includes the following steps: S101, obtain the diagnostic description file, network description file, and flashing file; wherein, the diagnostic description file includes the diagnostic parameters of the target electronic control unit; the network description file includes the communication message format between the host computer and the vehicle controller local area network bus.
[0029] As an example, a diagnostic description file can refer to a standardized file used to describe the diagnostic-related attributes of a target electronic control unit (ECU). It contains diagnostic parameters of the target ECU, which provide the basis for the generation, transmission, and response verification of diagnostic commands during the flashing process. It is the core document for realizing diagnostic communication between the host computer and the target ECU.
[0030] As an example, a network description file can refer to a file used to define the data interaction rules between the host computer and the vehicle controller LAN bus, clarify the format specifications of communication messages, ensure that the flashing-related data sent by the host computer can be correctly identified and transmitted by the vehicle controller LAN bus, and provide a guarantee for the effective transmission of data in the bus.
[0031] As an example, a flash file can refer to a file that stores software programs or data to be downloaded to the target electronic control unit. It is the core data carrier for updating the software of the target electronic control unit. Its encoding format follows specific industry standards to ensure the integrity and parseability of the data.
[0032] As an example, diagnostic parameters can refer to key information contained in the diagnostic description file that supports the execution of diagnostic services. These parameters, such as data format identifiers and address length format identifiers, are adapted to the UDS diagnostic protocol and directly affect the construction of diagnostic commands and the determination of response results.
[0033] As an example, a communication message format can refer to a structured format for data transmission defined by a network description file, which specifies the field composition, field length, data encoding method, etc., and serves as a standard for data interaction between the host computer and the vehicle controller's local area network bus.
[0034] Specifically, as an example, the diagnostic description file can be a CDD (Common Data Dictionary) diagnostic description file. The host computer loads this file to obtain the diagnostic parameters of the target electronic control unit (ECU). These parameters represent the UDS diagnostic protocol's configuration on the specific ECU, ensuring the compatibility of the diagnostic service with the target ECU. The network description file can be a DBC (Database CAN) communication description file. The host computer can read this file and parse the communication message format, including key information such as message ID, data segment length, and signal mapping relationships, providing a basis for data encapsulation. The flashing file can be a Hex (Hexadecimal) file. This is a commonly used ECU program storage format in the industry, containing the complete software program data required by the target ECU. The host computer can obtain this Hex file from a specified storage path through a file reading interface, preparing for subsequent data extraction and processing. During the acquisition process, the host computer can read the three types of files through the standard file loading interface of CANoe (CAN Open Environment) software, ensuring the complete import of file data, and supporting flexible replacement of files corresponding to different target electronic control units, thereby improving the versatility of the solution.
[0035] S102, extract flash data from the flash file.
[0036] As an example, flash data can refer to the core data obtained from the flash file for updating the target electronic control unit software. It includes the instruction code, configuration data, and other contents of the software program and is the basic data for updating and optimizing the electronic control unit functions.
[0037] Specifically, as an example, CAPL (Communication Access Programming Language) can be used as the parsing tool. CAPL is a scripting language included with CANoe, possessing efficient file parsing capabilities and accurately identifying the encoding rules of Hex files. During parsing, the file header, middle section, and end section structure of the Hex file are first identified. The header identifies the high-order address information and the start position of the data block, the middle section stores the core program data, and the end section marks the end of the data segment. The CAPL script reads the high-order address information and block start identifier from the header to determine the start position of the valid data; then, the length of the middle section is calculated, valid data is extracted, and redundant identifier information is eliminated; finally, parsing stops based on the end marker of the end section, completing the complete extraction of the flushed data and ensuring that the extracted data accurately reflects the software program content required by the target electronic control unit. During parsing, the CAPL script defines a data read buffer to temporarily store the extracted flushed data, providing data support for subsequent data formatting processing.
[0038] S103, fill the flash data into the first data structure to obtain the first formatted data; wherein, the first data structure is determined according to the encoding format of the flash file.
[0039] As an example, the first data structure can refer to a structured data container designed according to the encoding format of the brush file, used to standardize the storage of the extracted brush data. Its structure is adapted to the data organization method of the brush file and includes fields such as data block start address, data block length, and data buffer.
[0040] As an example, the first formatted data can refer to the standardized data formed by filling the extracted brush data according to the field requirements of the first data structure. It has a unified data storage structure, which facilitates subsequent adaptation and processing with the UDS diagnostic protocol.
[0041] As an example, the encoding format of a file can refer to the rules for organizing and storing data in the file. For Hex files, the encoding format clarifies the data block division method, address identification rules, data verification methods, etc., and is the direct basis for the design of the first data structure.
[0042] Specifically, as an example, a first data structure is designed based on the encoding format of the Hex file. This structure can contain a field for storing the starting address of a data block, a field for storing the length of the data block, and an array for storing the actual flushing data. The length of the array storing the actual flushing data can be set according to the maximum data storage requirements of the Hex file to ensure that it can accommodate flushing data of different sizes. During the filling process, the flushing data extracted in S102 is stored sequentially into the array storing the actual flushing data of the first data structure according to the starting address of the data block. At the same time, the starting address of the corresponding data block is written into the field storing the starting address of the data block, and the actual length of the data block is written into the field storing the length of the data block. For Hex files containing multiple data blocks, by defining the first data structure in the form of an array, the multiple data blocks can be stored separately, ensuring that each part of the flushing data can be managed in a standardized manner, forming a first formatted data with a unified structure, laying the foundation for subsequent integration with the UDS diagnostic protocol.
[0043] S104, the first formatted data and diagnostic parameters are filled into the second data structure through the target conversion function to obtain the second formatted data; wherein, the second data structure and the target conversion function are determined according to the Unified Diagnostic Service (UDS) diagnostic protocol.
[0044] As an example, the target conversion function can refer to a function designed for data format conversion according to the UDS diagnostic protocol and specific service type. Its function is to reorganize and encapsulate the first formatted data and diagnostic parameters according to the requirements of the UDS protocol to ensure that the data can be adapted to the transmission specifications of the UDS diagnostic service.
[0045] As an example, the second data structure can refer to a structured data container designed based on the UDS diagnostic protocol. Its field structure corresponds one-to-one with the request / response data format of the UDS diagnostic service. It is used to store standardized data adapted to the UDS protocol and is the direct carrier of data transmission.
[0046] As an example, the second formatted data can refer to the data formed by filling the first formatted data and diagnostic parameters into the second data structure through the target conversion function. It fully complies with the transmission requirements of the UDS diagnostic protocol and can be directly used for the execution of diagnostic services.
[0047] As an example, the Unified Diagnostic Service (UDS) Diagnostic Protocol can refer to the industry-standard vehicle diagnostic protocol, which defines the types of diagnostic services, data formats, transmission rules, etc. Among them, the flashing-related services include Service 34 (Request Download Service) and Service 36 (Transmit Data Service), which are the core standards followed for data conversion and transmission.
[0048] As another implementation of S104, if the target service type includes a request for download service, S104 may also include the following steps: As an example, the request download service can refer to service 34 in the Unified Diagnostic Service (UDS), which is used to feed back the storage adaptation information of the target electronic control unit to the host computer, providing configuration parameter support for subsequent data transmission.
[0049] Obtain the starting logical address and total data length from the first formatted data.
[0050] As an example, the starting logical address can refer to the address information that identifies the starting storage location of the data to be written in the target electronic control unit's storage medium.
[0051] As an example, the total data length can refer to the total number of bytes of the flush data contained in the first formatted data, reflecting the total scale of the flush data.
[0052] Specifically, as an example, the first formatted data can be stored based on a first data structure, which includes a data block start address field and a data block length field. The CAPL script calls the structure read interface to directly extract the data block start address field value from the first data structure, using it as the starting logical address. Simultaneously, the data block length field value is read as the total data length, and its value matches the total valid data length counted in the middle section of the Hex file. During the extraction process, the CAPL script performs validity checks on the data, ensuring that the starting logical address conforms to the target ECU's storage address range and that the total data length matches the actual data volume after the file is parsed, providing accurate parameters for subsequent data encapsulation.
[0053] Obtain the data format identifier and address length format identifier from the diagnostic parameters.
[0054] As an example, the data format identifier can refer to a key field in the diagnostic parameters, used to indicate the data compression format, data type, and other attributes of the data being written, ensuring that the target electronic control unit parses the data according to the corresponding rules.
[0055] As an example, the address length format identifier can refer to the identification information in the diagnostic parameters used to specify the number of bytes for the two parameters, the starting logical address and the total data length, providing a length basis for parameter parsing during data transmission.
[0056] Specifically, as an example, the diagnostic parameters originate from the loaded CDD diagnostic description file, which contains the complete diagnostic configuration for the target electronic control unit to adapt to the UDS protocol. Through CANoe's file parsing interface, the diagnostic parameter set corresponding to the UDS 34 service can be read from the CDD file. The data format identifier field and the address length format identifier field are then selected from the parameter set. The data format identifier corresponds to the data compression-related configuration in the UDS flashing service, while the address length format identifier specifies the byte counting rules for the starting logical address and the total data length, ensuring that subsequent data encapsulation conforms to the UDS protocol requirements.
[0057] The starting logical address, total data length, data format identifier, and address length format identifier are filled into the second data structure to obtain the second formatted data.
[0058] Specifically, as an example, the second data structure can be a structure adapted to the UDS 34 service, containing fields such as service identifier, data format identifier, address length format identifier, starting logical address, and total data length. Following the field order specified by the UDS protocol, the obtained starting logical address, total data length, data format identifier, and address length format identifier can be filled into the corresponding fields. Simultaneously, the request ID field can be set to 0x34 to identify the UDS 34 service. After filling, the resulting second-formatted data fully conforms to the UDS protocol requirements and can be directly used for subsequent CAN message encapsulation.
[0059] The vehicle software flashing method of this application embodiment clarifies the storage location and scale of the flashing data by extracting the starting logical address and total data length from the first formatted data; it obtains the data format identifier and address length format identifier from the diagnostic parameters, providing a key basis for data parsing; and it fills the above parameters into the second data structure, ensuring that the second formatted data fully complies with the protocol requirements of the request download service. This design achieves precise encapsulation of data related to the request download service, ensuring smooth diagnostic communication between the host computer and the target electronic control unit, enabling the target electronic control unit to accurately identify the storage requirements and format specifications of the flashing data, laying a solid foundation for subsequent flashing data transmission, and improving the accuracy and efficiency of the request download service execution.
[0060] As another implementation of S104, if the target service type includes data transmission service, S104 may also include the following steps: As an example, the data transfer service could be the UDS 36 service within the Unified Diagnostic Services (UDS) used for flushing data transfer, enabling the orderly and complete delivery of flushed data.
[0061] Obtain the maximum transfer block length, which is provided by the target electronic control unit in response to the request for download service.
[0062] As an example, the maximum transport block length can refer to the parameter fed back by the target electronic control unit after responding to the request to download the service. It is used to limit the maximum amount of data that can be transmitted in a single transmission of the data service in the unified diagnostic service, and is the core basis for data splitting and serialization transmission.
[0063] Specifically, as an example, after the host computer sends a command requesting a download service via CANoe, it waits for a response message from the target electronic control unit (ECU). When the target ECU responds to the download service request, it includes a maximum transmission block length (MTBL) parameter in the response message. The host computer parses this response message using a CAPL script, which has precise message parsing capabilities and can identify the field corresponding to the MTBL in the response message. After parsing, the value of this field is extracted as the MTBL, ensuring that subsequent data splitting complies with the transmission capacity limitations of the target ECU and guaranteeing the stability of data transmission.
[0064] Based on the maximum transfer block length, the flush data segment in the first formatted data is divided into multiple sequentially arranged data blocks.
[0065] As an example, a data block can refer to a standardized data unit formed by splitting the flush data segment according to the maximum transport block length. The length of each data block does not exceed the maximum transport block length, which facilitates sequential transmission through the data transmission service.
[0066] As an example, the data segment to be written can refer to the core software program data contained in the first formatted data. It is the basic data content for updating the target electronic control unit software and is stored in the data buffer of the first data structure.
[0067] Specifically, as an example, the total length field of the brush data segment in the first data structure of the first formatted data can be read. The total number of data splits is determined by calculating the total length of the brush data segment and the maximum transmission block length. When the total length is not divisible by the maximum transmission block length, the length of the last data block is the remaining data volume. During the splitting process, data of corresponding lengths is sequentially extracted according to the storage order of the brush data segments in the corresponding storage array of the first data structure, forming multiple sequentially arranged data blocks. This ensures that the arrangement order of the data blocks is consistent with the storage address order of the target electronic control unit, guaranteeing the accuracy of subsequent brush data storage.
[0068] Perform the following steps in the order the data blocks are arranged: Get the current data block to be transmitted.
[0069] As an example, the current data block to be transmitted can refer to a single data block that needs to be sent through the data transmission service in the current transmission order among multiple sequentially arranged data blocks, and is the basic unit of data transmission.
[0070] Specifically, as an example, based on the arrangement order of data blocks, the CAPL script can be used to retrieve the current data block to be transmitted. The CAPL script defines a transmission sequence counter, initially set to 1, with the counter value corresponding one-to-one with the arrangement order of the data blocks. Based on the counter value, the starting index and data length of the current data block to be transmitted in the corresponding storage array of the first data structure are determined. The starting index is calculated by subtracting one from the counter value and multiplying it by the maximum transmission block length. After locating the data by index, the corresponding length of data is read, which is the current data block to be transmitted. After each retrieval, the transmission sequence counter automatically increments by one until all data blocks have been retrieved, ensuring that data blocks are selected sequentially and avoiding transmission order errors.
[0071] The current data block to be transmitted is filled into the second data structure to obtain the second formatted data for the current transmission.
[0072] Specifically, as an example, the request ID field of the second data structure can be set to 0x36 to explicitly identify the current data transmission service within the unified diagnostic service. Then, the current value of the transmission sequence counter is filled into its corresponding field as the sequence number of the current data block. Next, the current data block to be transmitted is completely filled into its corresponding field's data buffer, and the length is set according to the actual length of the data block to be transmitted. The filling process can be automatically completed by a CAPL script, forming the second formatted data for the current transmission, providing a standardized data carrier for subsequent CAN message encapsulation and transmission.
[0073] The vehicle software flashing method of this application provides a scientific basis for data splitting by obtaining the maximum transmission block length fed back by the target electronic control unit, ensuring that the split data blocks can adapt to the transmission capability of the target electronic control unit. Based on this length, the flashing data segment is divided into multiple sequentially arranged data blocks, which are then filled into a second data structure in sequence, realizing serialized data transmission and avoiding failures caused by data transmission chaos or exceeding the transmission capacity. This design effectively solves the problems of difficulty and error in transmitting a large amount of flashing data at once, ensuring that each data block conforms to the protocol specifications of the data transmission service, improving the stability and efficiency of data transmission, and guaranteeing the smooth completion of software flashing.
[0074] S105 sends the second formatted data to the vehicle controller local area network bus in a communication message format to drive the target electronic control unit to complete the software flashing.
[0075] As an example, the vehicle controller area network bus, or CAN bus for short, can be a serial bus system used for data communication between electronic devices within a vehicle. It has high reliability, real-time performance, and anti-interference capabilities, and serves as the physical carrier for data transmission.
[0076] As an example, the target electronic control unit can refer to the electronic control unit in the vehicle that receives and updates the data and completes the software update. It is responsible for controlling key functions such as the vehicle's power system and chassis system. The update of its software program directly affects the vehicle's operating performance and functional realization.
[0077] Specifically, as an example, the host computer calls the standard interface via CANoe to encapsulate the second-formatted data according to the communication message format defined in the network description file. During encapsulation, the second-formatted data is filled into data segments according to the message format requirements, and a complete CAN message is constructed by combining information such as message ID and data length. Subsequently, the encapsulated CAN message is sent to the vehicle controller LAN bus via the CAN device. The CAN device acts as the hardware interface between the host computer and the CAN bus, ensuring stable data transmission. During transmission, the host computer receives feedback messages from the target electronic control unit in real time, adjusts the transmission rhythm according to the feedback results, and continues subsequent data transmission if a positive response is received. If a negative response is received or no response is received after a timeout, the flashing process is terminated and relevant information is recorded. For the second-formatted data corresponding to the data transmission service, each data block is sent sequentially according to the assigned sequence number to ensure the order and integrity of data transmission. After receiving the message on the CAN bus, the target electronic control unit parses the second-formatted data, completes the data reception, verification, and storage according to the requirements of the UDS diagnostic protocol, and finally realizes the software program update, completing the entire flashing process. By changing the loaded CDD and DBC files, this sending process can be adapted to all controllers in the power domain, achieving universal flashing.
[0078] The vehicle software flashing method of this application separates the configurations of controllers from different suppliers into independent diagnostic description files and network description files, rather than embedding them in the host computer tool. The diagnostic description file contains the diagnostic parameters of the target electronic control unit, and the network description file contains the communication message format between the host computer and the vehicle controller's local area network bus. Both types of files serve as adaptation carriers and follow industry-standard specifications. For controllers from different suppliers, there is no need to develop dedicated tools. Only the corresponding standardized files need to be replaced. Combined with the first data structure determined according to the flashing file encoding format, the flashing data can be extracted and stored in a standardized manner. Adaptation can be completed through the same host computer, completely breaking the binding relationship between dedicated tools and specific supplier controllers. Furthermore, based on the UDS diagnostic protocol, the second data structure and target conversion function were determined, and a set of universal data conversion and transmission logic was constructed. This logic can cover all controllers that comply with the protocol and standard. There is no need to design separate host computer function modules for different vendors. Each vendor only needs to provide standardized files that are adapted to their own controllers, and the universal host computer can be reused to implement the writing function. This avoids the duplication of development of host computer software with similar functions from the root, and achieves the technical goals of toolchain unification and development cost reduction.
[0079] As another implementation of this application, in order to improve the robustness and security of software flashing, such as Figure 2 As shown, the method may further include the following steps: S201, apply a preset external interference signal to the target electronic control unit or the vehicle controller area network bus. The preset external interference signal includes at least one of the following: injecting an error frame into the vehicle controller area network bus, causing power supply fluctuations to the target electronic control unit, or injecting abnormal waveforms into hard-wired signals connected to the target electronic control unit.
[0080] As an example, external interference signals can refer to signals that simulate abnormal electrical environments during actual vehicle operation, used to verify the robustness of the flashing process, including types such as bus communication anomalies, power supply fluctuations, and hardwired signal distortion.
[0081] As an example, an error frame can refer to an abnormal communication frame in the vehicle controller area network bus, which can disrupt the normal data transmission order and is a common form of bus interference.
[0082] As an example, power supply fluctuations can refer to the state in which the current or voltage of the power supply to the target electronic control unit deviates from the standard value, covering situations such as sudden voltage rises, drops, and sudden power outages.
[0083] As an example, abnormal waveforms can refer to non-standard waveforms appearing in hard-wired signals connected to the target electronic control unit, including PWM signal distortion, abnormal rising edge wake-up signals, etc.
[0084] Specifically, as an example, interference can be applied using CANoe and its supporting equipment. CANoe has rich functional interfaces, allowing precise control of fault injection devices and power supply devices. When injecting error frames into the vehicle controller LAN bus, the bus control interface can be called via CAPL scripts to trigger the interference device to inject error frames; when causing power fluctuations to the target electronic control unit, scenarios such as sudden power outages and voltage fluctuations can be simulated through the power supply device, with CANoe controlling the adjustment of power parameters; when injecting abnormal waveforms into hard-wired signals, related devices can also be controlled through CANoe's interface to generate distorted PWM signals or abnormal rising edge wake-up signals. All interference applications are triggered through the encapsulated UDS standard test interface, allowing flexible initiation at any stage of the flashing process, and supporting the application of single or multiple interference combinations.
[0085] The vehicle software flashing method in this application injects error frames into the CAN bus to accurately verify the flashing stability when bus communication is abnormal; it applies power supply fluctuations to the target electronic control unit to effectively test the impact of power system anomalies on the flashing process; and it injects abnormal waveforms into hardwire signals to fully verify the flashing adaptability under hardwire transmission link failures. These three types of interference signals cover typical abnormal scenarios in the three core transmission paths of the vehicle electrical system—bus, power, and hardwire—achieving comprehensive and multi-dimensional verification of flashing robustness. This avoids the one-sidedness of testing caused by a single type of interference, ensuring that the flashing process can operate stably under various possible abnormal conditions, further improving the practicality and reliability of the technical solution.
[0086] S202, acquire the response data of the target electronic control unit under interference.
[0087] As an example, response data can refer to the signal data fed back to the host computer by the target electronic control unit through the vehicle controller area network bus under the influence of external interference, including the execution status of the flashing process, data reception results, and abnormal handling feedback.
[0088] As an example, response data under interference can refer to the response data generated when the target electronic control unit is in an external interference environment, which can directly reflect the operating status of the flashing process under abnormal conditions.
[0089] Specifically, as an example, CANoe can monitor the communication status of the vehicle controller area network bus in real time. When external interference is applied, the CAPL script captures all feedback messages sent by the target electronic control unit through the bus listening interface. Response data includes positive response signals, negative response signals, and data transmission status identifiers, where a positive response indicates that the interference has not affected the current flashing step, and a negative response indicates that the interference has caused a process abnormality. Simultaneously, CANoe's built-in log function records the generation time, data content, and corresponding interference type of the response data in detail, ensuring data integrity and traceability, providing a basis for subsequent comparative analysis. During the acquisition process, the script parses the data in real time, extracts core status information, and temporarily stores it in the host computer's data buffer.
[0090] S203. Based on the comparison between the response data and the preset response results, the test results are determined.
[0091] As an example, the preset response result can refer to the standard response that the target electronic control unit should have under interference conditions, as pre-set according to the flashing process design specifications and UDS protocol requirements, including normal flashing execution, correct termination of the process and feedback of corresponding signals, etc.
[0092] As an example, test results can refer to the conclusions drawn by comparing response data with preset response results, which are used to determine the robustness of the flashing process in an interference environment, including types such as "resistant to interference", "effective anomaly handling", and "insufficient robustness".
[0093] Specifically, as an example, the host computer pre-stores preset response results corresponding to different interference scenarios. These results are based on the UDS protocol specification and the design requirements of the flashing process. During comparison, the CAPL script calls the data comparison interface to compare the response data obtained by S202 with the preset results for the corresponding scenario item by item. If the response data shows that the target electronic control unit can still complete data reception and flashing normally under interference, or terminates the process in time and feeds back the correct signal in case of an anomaly, the robustness of the flashing process is determined to be up to standard; if data transmission failure or process deadlock occurs, the robustness is determined to be insufficient. After the comparison is completed, CANoe automatically generates a test report, which records the interference type, response data, comparison results and test conclusions in detail, greatly improving test efficiency.
[0094] The vehicle software flashing method of this application simulates abnormal operating conditions that may occur in actual applications by applying a preset external interference signal to the target electronic control unit or CAN bus, thus overcoming the deficiency of existing technologies in lacking complete testing of the flashing process. By acquiring response data under interference and comparing it with preset response results, the operating status of the flashing process in abnormal environments can be intuitively determined, achieving quantitative verification of flashing reliability. This design extends the flashing process beyond data download to include operating condition adaptability testing, effectively avoiding the potential risks of flashing failure in complex environments, significantly improving the robustness and safety of software flashing, and providing a guarantee for the subsequent stable operation of the vehicle.
[0095] As another implementation of this application, in order to enhance the flexibility and scalability of the writing process, such as Figure 3 As shown, prior to S104, the method may further include the following steps: S301, Obtain the target service type of the Unified Diagnostic Service (UDS).
[0096] As an example, the target service type can refer to the specific UDS service category that needs to be executed in the software flashing process. It is the core basis for data format conversion and needs to be accurately matched with different stages of the flashing process (such as data preparation, data transmission, and process closing).
[0097] Specifically, as an example, the host computer loads the CDD diagnostic description file based on the CANoe software. This file contains the complete diagnostic service configuration for the target electronic control unit (ECU) to adapt to the UDS protocol. The CAPL script calls the CDD file parsing interface to extract all UDS flashing-related service types defined in the file. The target service type is then selected based on the current flashing process stage: In the initial flashing stage, when the target ECU's storage configuration needs to be obtained, the target service type is 34, "Request Download Service"; in the data transmission stage, when flashing data needs to be sent block by block, the target service type is 36, "Transfer Data Service"; and after flashing is completed and the process needs to be confirmed, the target service type is 37, "Flashing End Service". During the extraction process, the CAPL script verifies the compatibility of the service type with the current flashing stage, ensuring that the target service type conforms to the UDS protocol and enterprise standard flashing process requirements.
[0098] S302, Based on the correspondence between service type and conversion function, determine the target conversion function corresponding to the target service type.
[0099] As an example, the correspondence between service types and conversion functions can refer to the mapping rules pre-defined in the system, which clearly define the exclusive data conversion logic for each UDS writing service type, ensuring that the data format conversion of different services meets the protocol requirements.
[0100] As an example, the target conversion function can refer to a dedicated data conversion function that matches the target service type, used to reassemble and encapsulate the first formatted data and diagnostic parameters according to the data format requirements of the corresponding UDS service, so as to adapt it to CAN bus transmission.
[0101] Specifically, as an example, the host computer pre-constructs a mapping table between service types and conversion functions. This mapping table is based on the UDS protocol: 34. Download request service corresponds to the "address and length parameter encapsulation function," 36. Data transmission service corresponds to the "data block splitting and sequence number allocation function," and 37. Write completion service corresponds to the "closing instruction encapsulation function," etc. Each conversion function in the mapping table contains core logic such as data field matching, data length calibration, and protocol format adaptation. After obtaining the target service type, the CAPL script queries the mapping table, locates and calls the corresponding target conversion function, ensuring that subsequent data conversion accurately matches the format requirements of the current UDS service, providing dedicated conversion logic support for the generation of the second-formatted data.
[0102] The vehicle software flashing method in this application embodiment clarifies the main requirements of the current flashing stage by obtaining the target service type; it determines the target conversion function based on the correspondence between service type and conversion function, ensuring a high degree of compatibility between data conversion logic and service type, and avoiding data format errors caused by mismatch between conversion function and service. This design significantly improves the modularity of the flashing process. Different UDS services can achieve data standardization by matching dedicated conversion functions without reconstructing the overall data conversion logic, enhancing the flexibility and scalability of flashing, while further ensuring the accuracy of the second-formatted data, providing strong support for the smooth transmission of subsequent data and flashing execution.
[0103] Figure 4 This diagram illustrates the structure of a vehicle software flashing system according to an embodiment of this application. The system uses a CANoe401 as the core control platform, loading DBC communication description files and CDD diagnostic description files to provide a basis for data transmission and diagnostic adaptation. The CAN device 403 serves as a data transmission interface, enabling data flow interaction between the CANoe401 and the target electronic control unit 406. The CAPL script performs the core processing functions, extracting flashing data according to encoding rules through Hex parsing, splitting and packaging it according to UDS services via data flow control, and then controlling the flashing process to perform the flashing execution.
[0104] like Figure 4As shown, the power supply device 404 is responsible for the power supply control of the target electronic control unit 406 and can simulate interference such as sudden power outages and sleep / wake-up. The interference device 405 can perform fault injection and physical layer fault injection, including interference types such as bus error frames. CANoe 401 can precisely control the above devices (CAN device 403, power supply device 404, and interference device 405) through the rich interfaces of the test module, apply various interferences during the flashing process, and monitor the feedback of the target electronic control unit 406 at the same time, realizing the integration of flashing function and robustness testing. By changing the DBC and CDD files, it can be adapted to target electronic control units of various vehicle models.
[0105] Based on the vehicle software flashing method provided in the above embodiments, this application also provides specific implementation methods of the vehicle software flashing device. Please refer to the following embodiments.
[0106] First see Figure 5 The vehicle software flashing device 50 provided in this application embodiment includes the following modules: The file acquisition module 501 is used to acquire diagnostic description files, network description files, and flashing files; wherein, the diagnostic description files include diagnostic parameters of the target electronic control unit; and the network description files include the communication message format between the host computer and the vehicle controller local area network bus. Data extraction module 502 is used to extract flash data from the flash file; The first formatting module 503 is used to fill the flash data into the first data structure to obtain the first formatted data; wherein, the first data structure is determined according to the encoding format of the flash file; The second formatting module 504 is used to fill the first formatted data and diagnostic parameters into the second data structure through the target conversion function to obtain the second formatted data; wherein, the second data structure and the target conversion function are determined according to the Unified Diagnostic Service (UDS) diagnostic protocol; The target service type includes a request download service, and the second formatting module is used to perform the following operations: Obtain the starting logical address and total data length from the first formatted data; Obtain the data format identifier and address length format identifier from the diagnostic parameters; The starting logical address, total data length, data format identifier, and address length format identifier are filled into the second data structure to obtain the second formatted data.
[0107] The target service type includes data transfer service, and the second formatting module is used to perform the following operations: Obtain the maximum transfer block length, wherein the maximum transfer block length is provided by the target electronic control unit in response to the request for download service; Based on the maximum transfer block length, the flush data segment in the first formatted data is divided into multiple sequentially arranged data blocks; Perform the following steps in the order the data blocks are arranged: Get the current data block to be transmitted; The current data block to be transmitted is filled into the second data structure to obtain the second formatted data for the current transmission.
[0108] The data transmission module 505 is used to send the second formatted data to the vehicle controller local area network bus in a communication message format to drive the target electronic control unit to complete the software flashing.
[0109] In some embodiments, the vehicle software flashing device 50 may further include the following modules: An interference application module is used to apply a preset external interference signal to a target electronic control unit or a vehicle controller local area network bus. The interference application module is used to apply the preset external interference signal in at least one of the following ways: injecting an error frame into the vehicle controller local area network bus, causing power supply fluctuations to the target electronic control unit, or injecting abnormal waveforms into hard-wired signals connected to the target electronic control unit.
[0110] The response acquisition module is used to acquire the response data of the target electronic control unit under interference. The result determination module is used to determine the test result by comparing the response data with the preset response results.
[0111] In some embodiments, the vehicle software flashing device 50 may further include the following modules: The service type acquisition module is used to obtain the target service type of the Unified Diagnostic Service (UDS) before the second formatting module performs its operations. The conversion function determination module is used to determine the target conversion function corresponding to the target service type based on the correspondence between service type and conversion function.
[0112] Figure 6 A schematic diagram of the hardware structure of the vehicle provided in an embodiment of this application is shown.
[0113] The vehicle may include a processor 601 and a memory 602 storing computer program instructions.
[0114] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0115] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.
[0116] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.
[0117] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the vehicle software flashing methods in the above embodiments.
[0118] In one example, the vehicle may also include a communication interface 603 and a bus 610. Wherein, as... Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.
[0119] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or vehicles in the embodiments of this application.
[0120] Bus 610 includes hardware, software, or both, that couples vehicle components together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.
[0121] In addition, in conjunction with the vehicle software flashing methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle software flashing methods in the above embodiments.
[0122] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the vehicle software flashing methods described in the above embodiments.
[0123] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.
[0124] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.
[0125] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.
[0126] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.
[0127] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.
Claims
1. A vehicle software flashing method, characterized in that, The method comprises: obtaining a diagnostic description file, a network description file and a flashing file; wherein the diagnostic description file comprises diagnostic parameters of a target electronic control unit; the network description file comprises a communication message format between an upper computer and a vehicle controller area network bus; extracting flashing data from the flashing file; filling the flashing data into a first data structure to obtain first formatted data; wherein the first data structure is determined according to the encoding format of the flashing file; filling the first formatted data and the diagnostic parameters into a second data structure through a target conversion function to obtain second formatted data; wherein the second data structure and the target conversion function are determined according to a unified diagnostic service (UDS) diagnostic protocol; sending the second formatted data to the vehicle controller area network bus in the communication message format to drive the target electronic control unit to complete software flashing.
2. The method of claim 1, wherein, The method further comprises: applying a preset external interference signal to the target electronic control unit or the vehicle controller area network bus; obtaining response data of the target electronic control unit under interference; comparing the response data with a preset response result to determine a test result.
3. The method of claim 2, wherein, The application of the preset external interference signal comprises at least one of the following: injecting an error frame into the vehicle controller area network bus, performing power fluctuation on the target electronic control unit, and injecting an abnormal waveform into a hard-wired signal connected to the target electronic control unit.
4. The method of claim 1, wherein, Before the filling of the first formatted data and the diagnostic parameters into the second data structure through the target conversion function to obtain the second formatted data, the method further comprises: obtaining a target service type of the UDS; determining a target conversion function corresponding to the target service type according to a corresponding relationship between service types and conversion functions.
5. The method of claim 4, wherein, The target service type comprises a request download service, and the filling of the first formatted data and the diagnostic parameters into the second data structure through the target conversion function to obtain the second formatted data comprises: obtaining a starting logical address and a total data length from the first formatted data; obtaining a data format identifier and an address length format identifier from the diagnostic parameters; filling the starting logical address, the total data length, the data format identifier and the address length format identifier into the second data structure to obtain the second formatted data.
6. The method of claim 5, wherein, The target service type comprises a transmission data service, and the filling of the first formatted data and the diagnostic parameters into the second data structure through the target conversion function to obtain the second formatted data comprises: obtaining a maximum transmission block length, wherein the maximum transmission block length is provided by the target electronic control unit in response to the request download service; dividing a flashing data segment in the first formatted data into a plurality of sequentially arranged data blocks based on the maximum transmission block length; sequentially performing the following steps in the arrangement order of the data blocks: obtaining a current data block to be transmitted; Fill the current data block to be transmitted into the second data structure to obtain second formatted data for current transmission.
7. A vehicle software flashing device, characterized in that, The device comprises: a file acquisition module configured to acquire a diagnostic description file, a network description file and a flashing file, wherein the diagnostic description file comprises diagnostic parameters of a target electronic control unit, and the network description file comprises a communication message format between a host computer and a vehicle controller area network bus; a data extraction module configured to extract flashing data from the flashing file; a first formatting module configured to fill the flashing data into a first data structure to obtain first formatted data, wherein the first data structure is determined according to an encoding format of the flashing file; a second formatting module configured to fill the first formatted data and the diagnostic parameters into a second data structure through a target conversion function to obtain second formatted data, wherein the second data structure and the target conversion function are determined according to a unified diagnostic service (UDS) diagnostic protocol; a data sending module configured to send the second formatted data to the vehicle controller area network bus in the communication message format to drive the target electronic control unit to complete software flashing.
8. A vehicle characterized by comprising: The vehicle comprises a processor and a memory storing computer program instructions. The processor executes the computer program instructions to implement the vehicle software flashing method according to any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the vehicle software flashing method according to any one of claims 1-6.
10. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the vehicle to enable the vehicle to perform the vehicle software flashing method according to any one of claims 1-6.