Vehicle diagnosis method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a vehicle diagnosis method and device, electronic equipment and a storage medium. The method comprises: sending a diagnosis request message to an electronic control unit, wherein the diagnosis request message comprises a target style sheet, the target style sheet comprises target data items and target format information, the target data items are used to indicate the types of vehicle data to be obtained, and the target format information is used to indicate the reply format of the target data items; receiving a diagnosis response message from the electronic control unit, wherein the diagnosis response message comprises target vehicle data, the target vehicle data is obtained by performing format conversion on initial vehicle data according to the reply format, and the initial vehicle data is vehicle data corresponding to the types of vehicle data; analyzing the diagnosis response message to obtain the target vehicle data; and diagnosing the electronic control unit according to the target vehicle data. The embodiments of the present application can improve the diagnosis efficiency when diagnosing the vehicle.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more particularly to vehicle diagnostic methods, devices, electronic equipment, and storage media. Background Technology

[0002] Currently, when using diagnostic equipment to diagnose a vehicle, it is necessary to first obtain the vehicle's data. Obtaining vehicle data is done by sending a diagnostic request message through the diagnostic equipment, and then the vehicle's electronic control unit will reply with a message, sending the requested data back to the diagnostic equipment.

[0003] However, the data format encoding and byte positions within the response message are fixed and cannot be changed after manufacturing. This fixed format results in slow data transmission efficiency, which reduces diagnostic efficiency. Summary of the Invention

[0004] To address the aforementioned problems, embodiments of the present invention provide a vehicle diagnostic method, apparatus, electronic device, and storage medium, which can improve diagnostic efficiency when diagnosing vehicles.

[0005] In a first aspect, embodiments of the present invention provide a vehicle diagnostic method, applied to diagnostic equipment, comprising:

[0006] Send a diagnostic request message to the electronic control unit. The diagnostic request message includes a target style table, which includes target data items and target format information. The target data items are used to indicate the type of vehicle data to be acquired, and the target format information is used to indicate the response format of the target data items.

[0007] The electronic control unit receives a diagnostic response message, which includes target vehicle data. The target vehicle data is obtained by the electronic control unit by converting the initial vehicle data according to the response format. The initial vehicle data is vehicle data corresponding to the vehicle data type.

[0008] The diagnostic response message is parsed to obtain the target vehicle data;

[0009] Diagnose the electronic control unit based on the target vehicle data.

[0010] Secondly, embodiments of the present invention provide a vehicle diagnostic device, including a transmitting unit, a receiving unit, and a processing unit;

[0011] The sending unit is used to send a diagnostic request message to the electronic control unit. The diagnostic request message includes a target style table, which includes target data items and target format information. The target data items are used to indicate the type of vehicle data to be acquired, and the target format information is used to indicate the response format of the target data items.

[0012] The receiving unit is used to receive a diagnostic response message from the electronic control unit. The diagnostic response message includes target vehicle data, which is obtained by the electronic control unit from the initial vehicle data according to the response format. The initial vehicle data is vehicle data corresponding to the vehicle data type.

[0013] The processing unit parses the diagnostic response message to obtain the target vehicle data;

[0014] Diagnose the electronic control unit based on the target vehicle data.

[0015] Thirdly, embodiments of the present invention provide an electronic device, the electronic device including a processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, and the processor being used to execute the computer program stored in the memory, so that the electronic device performs the method as described in the first aspect.

[0016] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in the first aspect.

[0017] Fifthly, embodiments of this application provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, the computer being operable to perform the method as described in the first aspect.

[0018] Implementing the embodiments of this application has the following beneficial effects:

[0019] In this embodiment, a diagnostic request message is first sent to the electronic control unit (ECU). The diagnostic request message includes a target style table, which includes target data items and target format information. The target data items indicate the type of vehicle data to be acquired, and the target format information indicates the response format of the target data items. Then, a diagnostic response message is received from the ECU. The diagnostic response message includes target vehicle data, which is obtained by the ECU from initial vehicle data format conversion based on the response format. The initial vehicle data is vehicle data corresponding to the vehicle data type. Next, the diagnostic response message is parsed to obtain the target vehicle data. Finally, the ECU is diagnosed based on the target vehicle data. Therefore, by sending a diagnostic request message to the electronic control unit (ECU), which includes target format information reflecting the diagnostic equipment's data acquisition and encapsulation requirements, the ECU can acquire data and encapsulate it to obtain a diagnostic response message, rather than encapsulating it according to a fixed format. Compared to the fixed format, the target format information can flexibly adjust the data acquisition items and encapsulation methods according to the diagnostic equipment's needs, avoiding redundant data acquisition and message encapsulation. This improves data transmission efficiency and diagnostic efficiency when diagnosing vehicles. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the drawings used in the embodiments of the present invention or the background art will be described below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of this application;

[0022] Figure 2 This is a flowchart of a vehicle diagnostic method provided in an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of a target style sheet provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of a vehicle diagnostic interaction process based on a first verification provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of a vehicle diagnostic interaction process based on a second verification provided in an embodiment of this application;

[0026] Figure 6This is a schematic diagram of an identifier verification method provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to these processes, methods, products, or devices.

[0031] In this document, the term "embodiment" means that a particular feature, result, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0032] The following describes the relevant content, concepts, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0033] In automotive electronic control units, the data format in their response messages is usually strictly defined at the factory according to established standards or protocols. This involves setting the logic of parameters such as position, encoding type, bytes, and high and low bits. However, the fixed format restricts the combination and transmission of data, resulting in low efficiency.

[0034] See Figure 1 , Figure 1This is a schematic diagram of the architecture of a vehicle diagnostic system provided in an embodiment of this application. The vehicle diagnostic system includes a diagnostic device and an electronic control unit (ECU). The diagnostic device and the ECU interact with each other, for example, the diagnostic device sends a diagnostic request message to the ECU, and the ECU sends a diagnostic response message to the diagnostic device.

[0035] It should be noted that the vehicle diagnostic method provided in this application embodiment is applied to diagnostic equipment. The Electronic Control Unit (ECU) is a key component in a vehicle responsible for managing and controlling different systems. It collects data from the engine, brakes, transmission, etc., through sensors to optimize fuel injection and ignition timing, improving performance and efficiency. The ECU controls safety systems such as the Anti-lock Braking System (ABS) and Electronic Stability Program (ESP) to ensure driving safety. It communicates with other ECUs via the Controller Area Network (CAN) bus to achieve intelligent functions such as adaptive cruise control and automatic parking. It can also perform fault diagnosis and early warning, supporting intelligent, efficient, and safe vehicle operation.

[0036] See Figure 2 , Figure 2 This is a flowchart illustrating a vehicle diagnostic method provided in an embodiment of this application. The vehicle diagnostic method provided in this application includes, but is not limited to, the following steps:

[0037] Step S101: Send a diagnostic request message to the electronic control unit;

[0038] The diagnostic request message includes a target style sheet, which includes target data items and target format information. The target data items indicate the type of vehicle data to be acquired, and the target format information indicates the response format of the target data items.

[0039] Step S102: Receive a diagnostic response message from the electronic control unit;

[0040] The diagnostic response message includes target vehicle data, which is obtained by the electronic control unit converting the initial vehicle data according to the response format. The initial vehicle data is vehicle data corresponding to the vehicle data type.

[0041] Step S103: Parse the diagnostic response message to obtain the target vehicle data;

[0042] Step S104: Diagnose the electronic control unit based on the target vehicle data.

[0043] In one possible embodiment, for a diagnostic device, a target style sheet is first constructed, and a diagnostic request message is generated based on the target style sheet. Then, the message is assembled and sent to the electronic control unit.

[0044] Specifically, the diagnostic equipment generates a target style table locally based on diagnostic needs. For example, to obtain engine speed and coolant temperature data, "engine speed" and "coolant temperature" are written as target data items into the style table. Simultaneously, the target format information specifies parameters such as the starting byte, starting bit, byte endianness, bit endianness, bit length, and data encoding type. For instance, engine speed data is specified to occupy 2 bytes, using little-endian, linear encoding, and a scaling factor of 0.1; coolant temperature data occupies 1 byte, using big-endian, and unsigned integer encoding.

[0045] Furthermore, the constructed target style sheet is encapsulated into a diagnostic request message. The message format follows a predetermined communication protocol, such as a CAN bus-based diagnostic protocol or the ISO 14229 protocol. Taking the CAN bus as an example, the message includes an identifier (ID), a data field, etc. The target style sheet is used as the content of the data field, and an appropriate identifier is set to identify the message as a diagnostic request.

[0046] Furthermore, the diagnostic equipment sends the assembled diagnostic request message to the electronic control unit via an in-vehicle communication network, such as CAN bus or in-vehicle Ethernet.

[0047] Accordingly, when the electronic control unit processes the diagnostic request message, it first parses the request, then acquires and converts the data according to the request, generates a diagnostic response message, and finally sends the diagnostic response message to the diagnostic device.

[0048] Specifically, after receiving a diagnostic request message, the ECU first parses the message, extracting the target pattern table. Based on the target data items in the target pattern table, the ECU retrieves the corresponding initial vehicle data from its internal storage or sensor acquisition modules. For example, it retrieves raw engine speed data from the engine control module and reads the raw coolant temperature measurement from the temperature sensor. Then, the ECU performs format conversion on the acquired initial vehicle data according to the target format information in the target pattern table. For instance, it arranges the raw engine speed data in little-endian order, performs calculations based on linear encoding rules and scaling factors, and adjusts the coolant temperature data to big-endian unsigned integer form. Next, the converted target vehicle data is assembled into a diagnostic response message. Following the same communication protocol, the target vehicle data is filled into the data field of the response message, and the correct identifier is set to indicate that this is a response to the diagnostic request. Finally, the ECU sends the diagnostic response message back to the diagnostic device through the same communication network.

[0049] Furthermore, the diagnostic equipment parses the response message. Receiving the diagnostic response message from the ECU, the equipment parses it according to the format information defined in the target style table. It extracts the target vehicle data from the message, determines the data position based on the start byte and start bit, adjusts the data order according to byte and bit endianness rules, and truncates valid data according to bit length to obtain the target vehicle data. In addition, it can convert binary data into numerical values ​​with actual physical meaning based on the data encoding type, such as converting the converted engine speed data from binary to an actual engine speed value in revolutions per minute (RPM).

[0050] Furthermore, the diagnostic equipment analyzes the target vehicle data obtained from the analysis. For example, it compares the engine speed with the normal speed range to determine if the engine is operating normally, analyzes whether the coolant temperature is too high, and identifies any cooling system malfunctions. Based on the analysis results, a diagnostic report is generated, detailing the detected vehicle data, comparisons with normal ranges, potential fault locations, and fault cause analysis. Finally, the diagnostic report is presented to repair personnel in a visual format, such as on the diagnostic equipment's display screen or transmitted via network to the repair management system, providing a basis for vehicle repair.

[0051] In this embodiment, the explicit format definition of the target style table reduces the complexity and uncertainty of data parsing. The diagnostic device does not need to perform complex format adaptations for ECU data from different sources, enabling it to quickly and accurately parse response messages and obtain target vehicle data, thereby accelerating diagnostic efficiency. Simultaneously, the ECU's data conversion and transmission according to the predetermined format also improves data processing efficiency. Furthermore, when new diagnostic functions need to be added or diagnostic data types need to be updated, only the relevant content in the target style table needs to be modified, without requiring large-scale changes to the underlying communication logic of the diagnostic device and the ECU. For example, to add battery voltage detection, simply add battery voltage as the target data item in the style table and define its format information to achieve the acquisition and diagnosis of new data, enhancing the scalability and flexibility of the diagnostic system.

[0052] Optionally, the response format includes: start byte, start bit, byte endianness, bit endianness, bit length, and data encoding type; step S103, parsing the diagnostic response message to obtain the target vehicle data, may include the following steps:

[0053] Step S201: Parse the vehicle data type from the diagnostic response message;

[0054] Step S202: Determine the response format based on the vehicle data type;

[0055] Step S203: Determine the data storage location of the vehicle data corresponding to the vehicle data type in the diagnostic response message based on the start byte, start bit, and bit length;

[0056] Step S204: Determine the data storage order based on byte endianness, bit endianness, and data encoding type;

[0057] Step S205: Parse the diagnostic response message according to the data storage location and data storage order to obtain the target vehicle data.

[0058] In one possible embodiment, the vehicle data type is parsed from the diagnostic response message. First, the protocol header in the message is identified, then the data item identifiers are extracted, and finally, verification and mapping are performed.

[0059] Specifically, diagnostic response messages typically include a protocol header. Parsing the header information determines the message type, such as a fault code response or a real-time data stream. For example, if the message ID is 0x7E8, it is identified as an ECU response message. The data fields in the message usually include a Diagnostic Identifier (DID), used to uniquely identify the vehicle's data type. For example, a DID of 0x010C indicates engine speed, and a DID of 0x0105 indicates coolant temperature. The extracted DID is compared with the local data dictionary to ensure the data type is valid. If the DID is missing or invalid, an error code is returned.

[0060] In one possible embodiment, the response format is determined based on the vehicle data type. A mapping lookup is performed on the vehicle data type according to a target style table pre-stored in the diagnostic device to obtain the response format corresponding to that vehicle data type. For example, if DID is 0x22010C, its response format can be 2 bytes, little-endian, and linearly encoded.

[0061] In one possible implementation, determining the data storage location involves first calculating the byte offset and processing the bit offset, then verifying the bit length. Specifically, based on the starting byte (e.g., if the starting byte is 2), the data start position is located by offsetting backwards from the message header. For example, if the message is 0x42010C07D0, parsing starts from the 3rd byte (0x07). If the starting bit is not 0, for example, if the starting byte is 4, the bit boundaries spanning bytes need to be calculated. For example, if the data spans byte 2 (bits 4-7) and byte 3 (bits 0-3), the two bytes need to be merged bit by bit. This ensures that the parsed bit length does not exceed the message boundaries, avoiding out-of-bounds reading.

[0062] In one possible implementation, the data storage order is determined. First, byte order adjustment is performed. For example, little-endian indicates the least significant byte first; for example, 0x07D0 would have an actual value of 0xD007. Big-endian indicates the most significant byte first; for example, 0x07D0 would have an actual value of 0x07D0. Then, bit order adjustment is performed. If the response format indicates least significant bit first, then bit 0 is the least significant bit and is parsed in natural order. If the response format indicates most significant bit first, then bit 0 is the most significant bit and the bit order needs to be reversed. For example, if the bit length is 4 and occupies the high 4 bits of the byte, such as 0x07, it can first be converted to 00000111. If the response format indicates most significant bit first, it needs to be inverted to 01110000. Then, masking and bit shifting operations are performed. A bit mask, such as 0xFF, and a bit shifting operation, such as <<, are used to extract the significant bits. If the response format indicates byte&0xF0>>4, then the high 4 bits of the byte are extracted.

[0063] In this embodiment, complex message parsing is broken down into independent steps such as data type identification, format matching, position calculation, order adjustment, and encoding conversion. It strictly adheres to endianness rules and bit boundary calculations to ensure accurate parsing of multi-byte and cross-byte data. Only the target data item is parsed, avoiding full parsing and reducing computational resource consumption, making it particularly suitable for resource-constrained vehicle diagnostic equipment.

[0064] Optionally, before sending the diagnostic request message to the electronic control unit in step S101, the following steps may also be included:

[0065] Step S301: Determine the target data items and target format information;

[0066] Step S302: Generate a target style sheet based on the target data items and target format information;

[0067] Step S303: Generate a diagnostic request message based on the target style sheet.

[0068] Specifically, the target data items can be customized by the user. For example, the user can select the target data items to be obtained through the interactive interface of the diagnostic device. Alternatively, the diagnostic device can automatically determine the target data items based on historical diagnostic data items. For example, based on historical diagnostic data items, the pattern of diagnostic data items can be obtained, and based on this pattern, the target data items that need to be diagnosed now can be predicted. Or, the target data items corresponding to the diagnostic function currently selected by the user can be automatically generated. For example, if the current diagnostic function is to detect whether the vehicle is in working condition, then the target data items may include speed, engine temperature, etc.

[0069] Specifically, the target format information can be customized by the user or automatically generated by the diagnostic device. The diagnostic device can determine different target format information according to the different application scenarios.

[0070] In one possible embodiment, a target style sheet is generated based on the target data items and target format information. According to diagnostic requirements, the vehicle data types to be acquired, such as engine speed, coolant temperature, and fault codes, are selected from a predefined data item library. A unique DID is assigned to each data item; for example, the DID for engine speed is 0x010C, the DID for coolant temperature is 0x0105, and the DID for fault codes is 0x03. Detailed format information is configured for each data item, where the start byte indicates the starting byte position of the data in the message, the start bit indicates the starting bit position of the data within a byte, byte endianness indicates the storage order of multi-byte data (including little-endian or big-endian), bit endianness indicates the storage order of bit fields (including least significant bit first or most significant bit first), bit length indicates the total number of bits occupied by the data, and data encoding type indicates the data encoding method. Then, the data items and format information are combined into a structured style sheet, which can be in JSON or XML format.

[0071] In one possible embodiment, a diagnostic request message is generated based on a target style sheet. This message must adhere to a specific communication protocol, such as ISO 14229 or OBD-II, and encapsulate the target style sheet within it. First, a suitable protocol is selected based on the diagnostic scenario. Then, a message header is constructed based on identifiers and control fields. The identifier specifies the target ECU and priority of the message. In the OBD-II standard, the request message ID is 0x7DF, and the response message ID is 0x7E8. The control fields specify message type, length, and other information. Next, the target style sheet is converted to a protocol-compatible format and added to the message data field. For example, for the ISO 14229 format, the message data field composition could be: [Service ID] + [DID high byte] + [DID low byte] + [Data Length] + [Style Sheet Data].

[0072] For example, see Figure 3 , Figure 3 This is a schematic diagram of a target style sheet provided in an embodiment of this application. For example... Figure 3 As shown, the target style table includes information such as DID, start byte, start bit, byte endianness, bit endianness, bit length, and encoding type. For example, DID is 0x010C, which refers to engine speed, start byte is 2, start bit is 0, byte endianness is little-endian, bit endianness is least significant bit first, bit length is 16, and encoding type is enumeration encoding.

[0073] In this embodiment, the explicit data format definition reduces redundant information, optimizes message length, and improves communication and diagnostic efficiency.

[0074] Optionally, in step S301, determining the target format information may include the following steps:

[0075] Step S401: Obtain historical usage data of the diagnostic equipment;

[0076] Step S402: Based on historical usage data, determine the application scenario of the diagnostic equipment, wherein the application scenario is used to indicate at least one of the following data modes of the diagnostic equipment: data display mode, data transmission mode, and data processing mode;

[0077] Step S403: Determine the target format information based on the application scenario and the preset first mapping relationship, wherein the first mapping relationship is used to reflect the correspondence between the application scenario and the target format information.

[0078] In one possible embodiment, historical usage data of the diagnostic device is acquired. This historical usage data includes device logs, user configuration information, and diagnostic reports. The device logs record information such as the time, data type, and results of each diagnostic operation. The user configuration information includes user-preferred display formats, transmission protocols, and other settings. The diagnostic reports are complete reports generated during historical diagnostic processes, containing a complete record of the data acquisition, processing, and display process. Historical usage data reflects operation records, data formats, and device status. Operation records can include the frequency and time of operations such as "reading engine speed" and "viewing fault code P0101." The data format can be historically used format parameters, such as start byte and endianness. Device status includes the diagnostic device's operating mode, such as offline or online, and the type of connected ECU.

[0079] In one possible embodiment, the application scenario of the diagnostic device is determined based on historical usage data. The operation behaviors in the historical usage data can be grouped by a clustering algorithm, and a classification model can be trained to predict the current application scenario. If the current operation of the user is received, the corresponding application scenario is adjusted in real time. The application scenario is used to indicate at least one of the following data modes of the diagnostic device: data display mode, data transmission mode, and data processing mode.

[0080] In one possible embodiment, target format information is determined based on the application scenario and a preset first mapping relationship, wherein the first mapping relationship reflects the correspondence between the application scenario and the target format information. The first mapping relationship can be determined based on a preset rule base or a dynamic mapping table. For the preset rule base, if the application scenario is real-time monitoring, the target format information can be little-endian, fixed-length, and linearly encoded to facilitate fast parsing; if the application scenario is remote diagnostics, the target format information can be big-endian and compressed to reduce transmission volume; if the application scenario is fault diagnosis, the target format information can be enumerated encoding to directly map fault descriptions. For the dynamic mapping table, association rules between scenarios and formats are automatically generated based on historical data. For example, if 90% of "real-time monitoring" scenarios use little-endian, a strong association is established. The starting byte and starting bit can be determined based on historical usage frequency to determine the most common offsets. Endianness can be selected based on scenario priority; for example, real-time monitoring prioritizes little-endian. For frequently used data items, efficient encoding, such as linear mapping, is used; for infrequently used data, compressed encoding is used to save space.

[0081] For example, if the diagnostic equipment detects frequent readings of engine parameters, it automatically selects little-endian and linear encoding to ensure fast data display. If the equipment detects that data needs to be transmitted to the cloud, it automatically selects big-endian and compressed encoding to reduce network traffic. If the equipment detects that users frequently export historical data, it automatically optimizes the report format to improve data readability.

[0082] In this embodiment, the diagnostic device automatically selects the optimal format, eliminating the need for manual configuration by the user, thus improving operational efficiency. It dynamically adjusts the format according to different application scenarios to ensure optimal data processing and transmission.

[0083] Optionally, in step S301, determining the target format information may include the following steps:

[0084] Step S501: Obtain historical data item information for the target data item;

[0085] Step S502: Based on historical data item information, predict the data item character type and data item character count of the target data item, wherein the data item character type includes at least one of the following: numeric type, text type, and language type;

[0086] Step S503: Determine the proportion of at least one character based on the character type and number of characters in the data item;

[0087] Step S504: Determine the target format information based on the occupancy ratio of at least one character and a preset second mapping relationship, wherein the second mapping relationship is used to reflect the correspondence between the occupancy ratio of at least one character and the target format information.

[0088] Specifically, the historical data information of the target data item includes the original value, timestamp, associated ECU, etc., which are used to reflect the numerical characteristics, time series characteristics and contextual characteristics of the target data item. Among them, the numerical characteristics include the maximum value, minimum value, average value, standard deviation, etc., the time series characteristics include data change trends, periodic fluctuations, etc., and the contextual characteristics include associated data items, such as the correlation between speed and load.

[0089] In one possible embodiment, based on historical data item information, the character type and number of characters of the target data item are predicted. The character type includes at least one of the following: numeric, text, or language. Numeric type identification is performed by distinguishing integers, floating-point numbers, percentages, etc., based on numerical range and precision characteristics. Text types such as fault codes and fault descriptions are identified through regular expression matching, such as combinations of letters and symbols. The language of the text is determined using N-gram features, such as ASCII or UTF-8 multibyte characters, for language type identification. Based on time series models such as Long Short-Term Memory networks, the trend of data item length over time and the association rules between data item length and operating parameters are predicted. Operating parameters may include vehicle speed, engine load, etc.

[0090] In one possible embodiment, at least one character occupancy ratio is determined based on the character type and number of characters in the data item. The character occupancy ratio includes space occupancy ratio, time occupancy ratio, and importance weight ratio. The space occupancy ratio is obtained by calculating the proportion of different character types in the total storage space, such as 80% for numeric characters and 20% for text characters. The time occupancy ratio is determined based on the statistical proportion of time spent by different character types during data transmission; for example, numeric characters are prioritized in real-time transmission. The importance weight ratio is determined based on the information value weight of each character type calculated using information entropy; for example, fault code text has a higher weight than ordinary status indicators. Furthermore, the ratio threshold is dynamically adjusted according to the application scenario; for example, in remote diagnostic scenarios, text data is compressed first.

[0091] In one possible embodiment, target format information is determined based on at least one character occupancy ratio and a preset second mapping relationship, wherein the second mapping relationship reflects the correspondence between the at least one character occupancy ratio and the target format information. Specifically, the second mapping relationship can be determined based on a ratio-format mapping table and a fuzzy matching algorithm. According to the ratio-format mapping table, the target format information can be determined based on the combination of character occupancy ratios. For example, if the character occupancy ratio combination is numeric > 80%, the target format information can be little-endian, fixed-length, or binary encoding; if the character occupancy ratio combination is text > 50% and contains multi-byte characters, the target format information can be UTF-8 encoding, variable-length fields, or big-endian alignment; if the character occupancy ratio combination is a mixed type with high real-time requirements, the target format information can be segmented encoding or a parallel transmission mechanism. According to the fuzzy matching algorithm, when the actual ratio combination does not match the preset rule, the nearest neighbor algorithm is used to select the most similar format configuration. In addition, more bit width is allocated to high-weight character types to ensure accuracy, such as using 16-bit encoding for fault codes. For mixed data types, a composite encoding scheme is used, such as the first 8 bits being a status flag and the last 24 bits being a numerical value.

[0092] In this embodiment, the encoding scheme is optimized to take into account the characteristics of different character types, such as binary compression for numeric characters and character set adaptation for text characters. This allows the same storage space to carry more effective information and automatically adapts to different language environments. For example, Chinese diagnostic reports use UTF-8 encoding, while English uses ASCII encoding. On devices with limited computing resources, the decoding complexity is reduced by optimizing the character occupancy ratio.

[0093] Optionally, in step S301, determining the target format information may include the following steps:

[0094] Step S601: Obtain the remaining storage space of the electronic control unit;

[0095] Step S602: Obtain a candidate format information corresponding to the electronic control unit;

[0096] Step S603: Predict the byte space occupied by each candidate format information to obtain a bytes of space occupied;

[0097] Step S604: Determine the target format information from the a candidate format information based on the remaining storage space and the space occupied by a bytes.

[0098] Specifically, the process begins with a storage information request and interaction. The diagnostic device sends a request command to the electronic control unit (ECU) to obtain the storage status via a diagnostic communication protocol, for example, by sending a specific service ID. Upon receiving the request, the ECU parses the command and extracts the remaining storage space information from its internal storage management module. Then, the information is parsed and verified. The ECU encapsulates the remaining storage space data into a storage response message and returns it to the diagnostic device. Upon receiving the message, the diagnostic device parses the data according to the protocol rules and verifies the accuracy of the information through checksums, data range checks, and other methods to ensure that the obtained remaining storage space value is true and reliable.

[0099] In one possible embodiment, a candidate format information library is pre-established. This library covers various combinations of data encoding and storage formats, including but not limited to different byte endianness modes such as big-endian and little-endian, bit length settings such as 8 bits, 16 bits, and 32 bits, and data encoding types such as linear encoding, enumeration encoding, and compressed encoding. Based on the type, function, and diagnostic requirements of the electronic control unit (ECU), a suitable candidate format information is selected from the candidate format library. For example, for ECUs with limited storage resources, compressed encoding and short-bit-length formats are preferentially selected as candidates; for ECUs with stronger processing capabilities, more complex but efficient encoding formats are determined, forming a candidate format set.

[0100] In one possible implementation, the byte space occupied for each candidate format information is predicted, resulting in 'a' bytes of space. A byte space prediction model based on format parameters is established, comprehensively considering the key parameters in each candidate format information. For linear encoding formats, the space occupied is calculated based on the data range, precision requirements, and bit length. For compressed encoding formats, the number of bytes after compression is estimated by combining data characteristics, such as repetition and distribution patterns, as well as the characteristics of the compression algorithm. For each candidate format information, if it is a fixed bit length format, the byte space occupied is directly calculated based on the bit length: byte space occupied = bit length / 8, rounded up. If it is a variable length or compressed format, the average space occupied is estimated through historical data simulation, sample testing, etc. For example, after encoding a set of sample data using the format, the number of bytes is counted, and the average value is taken as the byte space occupied.

[0101] Furthermore, based on the remaining storage space and the space occupied by 'a' bytes, the target format information is determined from 'a' candidate format information. The byte space occupied by each candidate format is compared with the remaining storage space of the ECU, and candidate formats that satisfy the condition that the byte space occupied is less than or equal to the remaining storage space of the ECU are selected, forming a feasible format subset. If the feasible format subset contains multiple elements, further selection is performed according to preset optimization objectives: a space utilization priority method can be adopted, selecting the format whose byte space occupied is closest to the remaining storage space to maximize storage space utilization; a performance priority method can be adopted, prioritizing formats with high parsing efficiency and low consumption of ECU computing resources; or a compatibility priority principle can be adopted, selecting the format with the best compatibility with other system modules, such as communication modules and display modules. The final target format information is determined from the feasible format subset using the above strategies.

[0102] In this embodiment of the application, the problem of wasted or insufficient storage space caused by improper format selection is avoided by dynamically adapting the format information.

[0103] Optionally, after sending the diagnostic request message to the electronic control unit in step S101, the following steps may also be included:

[0104] Step S701: Receive a diagnostic verification message from the electronic control unit, wherein the diagnostic verification message is used to indicate that the diagnostic response message is verified, and the diagnostic verification message includes a target verification item, which is format information in the target style table that does not have a mapping relationship with the preset style table;

[0105] Step S702: Determine the first format of the vehicle data corresponding to the target verification item in the diagnostic response message;

[0106] Step S703: Determine the second format corresponding to the target check item in the diagnostic request message;

[0107] Step S704: Based on the second format and the first format, perform format conversion on the vehicle data corresponding to the target verification item in the diagnostic response message to obtain the verified diagnostic response message.

[0108] Specifically, the verification request is identified by the CAN bus ID or the unified diagnostic service ID, and the target verification item field contains the DID and its format parameters for unmapped format information.

[0109] In one possible embodiment, the diagnostic device listens to the communication bus, extracts verification messages with specific IDs, parses the message content according to the protocol specifications, identifies the target verification items, and distinguishes between mandatory verification items and optional verification items. The mandatory verification items are parameters that affect data security, while the optional verification items are parameters that only affect the display effect.

[0110] In one possible embodiment, a first format of the vehicle data corresponding to the target check item in the diagnostic response message is determined. Based on the DID of the target check item, the corresponding data field is located from the diagnostic response message. For example, if the check item is engine speed DID = 0x010C, 0x07D0 is extracted from the response message 0x42010C07D0 as the original data. Then, byte order analysis and bit field identification are performed. The byte order is inferred through data characteristics. For example, if the parsed engine speed value is 2000 RPM and the data is 0x07D0, it is inferred to be big-endian, i.e., 0x07D0 = 2000. The data boundaries are analyzed to verify whether the bit length meets expectations, such as a 16-bit integer.

[0111] In one possible embodiment, the second format corresponding to the target verification item in the diagnostic request message is determined, the target style table is extracted from the diagnostic request message, and the format definition corresponding to the target verification item is located, such as little-endian or linear encoding.

[0112] In one possible embodiment, the vehicle data corresponding to the target verification item in the diagnostic response message is format-converted according to the second format and the first format to obtain the verified diagnostic response message. The format conversion includes byte order conversion, bit field rearrangement, and encoding type conversion. If the first format is big-endian and inconsistent with the second format (little-endian), the byte order is swapped, such as converting 0x07D0 to 0xD007. The bit order is adjusted through offset and mask operations. If different encodings are involved, the conversion is performed according to the corresponding algorithm. The data bit order and byte order are reorganized according to the requirements of the second format.

[0113] Furthermore, the verified diagnostic response message is parsed to obtain the first vehicle data, and finally the electronic control unit is diagnosed based on the first vehicle data.

[0114] For example, see Figure 4 , Figure 4 This is a schematic diagram of a vehicle diagnostic interaction process based on a first verification, provided in an embodiment of this application. First, the diagnostic device sends a diagnostic request message to the vehicle bus and receives a diagnostic verification message. If the diagnostic verification message indicates that there is no missing data in the target verification item and it is only a data format verification, the diagnostic response message can be verified according to the target verification item after receiving the diagnostic response message to obtain the verified diagnostic response message.

[0115] In one possible embodiment, if the diagnostic verification message indicates that there is data in the target verification item that cannot be verified, for example, the data that cannot be verified may be missing due to inconsistent DIDs, then the diagnostic request message is verified. The original DID in the diagnostic request message is verified so that the verified DID matches the electronic control unit, and the verified diagnostic request message is sent to the electronic control unit so that the electronic control unit generates a corresponding verification diagnostic response message based on the verified diagnostic request message. Then, the electronic control unit receives the verification diagnostic response message, parses the verification diagnostic response message to obtain the target vehicle data, and finally diagnoses the electronic control unit based on the target vehicle data.

[0116] For example, see Figure 5 , Figure 5 This is a schematic diagram of a vehicle diagnostic interaction process based on a second verification, provided in an embodiment of this application. First, the diagnostic device sends a diagnostic request message 1 to the vehicle bus and receives a diagnostic verification message 1. If the diagnostic verification message 1 indicates that the target verification item 1 has missing data, and the target vehicle data cannot be obtained by verifying the diagnostic response message 1 corresponding to the diagnostic request message 1, then, based on the diagnostic verification message 1, the device sends a diagnostic request message 2 to the vehicle bus and receives the diagnostic verification message 2. If the diagnostic verification message 2 indicates that the target verification item 2 has no missing data and is only a data format verification, then, based on the target data item 2 in the diagnostic verification message 2, the diagnostic response message 2 is verified to obtain the verified diagnostic response message 2.

[0117] In this embodiment, the electronic control unit verifies the diagnostic request message. When a target verification item exists, a diagnostic verification message is sent to the diagnostic device. This ensures that the diagnostic device can verify the diagnostic response from the electronic control unit to the diagnostic device based on the target verification item, thereby obtaining the required correct data. Furthermore, if the diagnostic device is unable to verify the target verification item due to missing data or too many target verification items, the diagnostic device can also verify the diagnostic request response and resend the verified diagnostic request response to the electronic control unit. This enables the electronic control unit to generate the diagnostic response required by the diagnostic device based on the verified diagnostic request response, thus improving diagnostic efficiency.

[0118] In a specific embodiment, when the diagnostic device requests data from the vehicle ECU, it can set a style table. The style table defines the vehicle data items to be requested (which can be multiple), the starting position of each data item's response, the number of bytes occupied, the endianness of the bytes, and the encoding type (including ASCII, UNICODE, numeric, UTF8, etc.). The style table is then filled into the request command and sent to the vehicle ECU. Upon receiving the request, the ECU will organize the corresponding data values ​​according to the format in the style table and then fill them into the response command, sending them back to the diagnostic device. In this way, the diagnostic device can customize the returned format of the vehicle data, making it easier to parse and understand. The obtained vehicle data can be used directly without further encoding conversion, improving diagnostic efficiency.

[0119] Specifically, before requesting data from the vehicle's ECU, the diagnostic equipment can define a style table. This style table supports defining format information for multiple data items, including the starting byte, starting bit, byte endianness, bit endianness, bit length, and data encoding type. The starting byte refers to the byte from which the data value is stored in the response command, with the index starting from 0. The starting bit indicates the starting position within a byte, also starting from 0. One byte contains 8 bits, and the bit length indicates the number of bits used to store the data value. For example, if the vehicle voltage data starts with byte 2, the starting bit is 0, and the bit length is 16, it means the voltage value will be stored in the 3rd and 4th bytes of the response command, totaling 16 bits. Byte endianness refers to the order of the high and low bytes. Big-endian is indicated by a flag of 1, and little-endian by a flag of 0. For example, if the voltage data needs to be stored in the 3rd and 4th bytes, big-endian means the high byte is placed in the 3rd byte first, and the low byte in the 4th byte last. Little-endian is the reverse, with the low byte first and the high byte last. Endianness: A byte has 8 bits, numbered BIT7-BIT0. In big-endian, BIT7 is the most significant bit, and in little-endian, BIT0 is the most significant bit. Data encoding type refers to the format in which data values ​​are stored. Different encodings are used in different scenarios. For example, ASCII is generally used to display English characters, while UNICODE is generally used to display characters from other languages. UTF-8 is generally used for transmission over networks. Numerical values ​​can be directly converted to their values. For example, a voltage value of 12V is represented by the numerical encoding 12, but by ASCII 0x3132.

[0120] Furthermore, the stylesheet can define the format of multiple data items simultaneously, each with a unique DID. For example, it could be: Voltage DID + Voltage start byte + Voltage byte endianness flag + Voltage start bit + Voltage bit endianness flag + Voltage bit length + Voltage code + [Temperature DID + Temperature start byte + Temperature byte endianness flag + Temperature start bit + Temperature bit endianness flag + Temperature bit length + Temperature code]. Each data item's format can be set independently or by data type. For instance, types can be numeric or text. Numeric types could be voltage, temperature, or RPM, while text types could be fault codes, ignition switch status, or gear position. Default formats can be set for different types, and each data item can also have its format set individually.

[0121] The information in the style sheet can be manually specified or automatically defined based on the usage scenario of the diagnostic device. For example, if the data needs to be displayed on a webpage, the encoding method can be automatically set to UTF8. If the diagnostic data needs to be transmitted over a network, the bytes can be automatically set to big-endian mode because the byte order on the network is big-endian. If the data needs to be processed locally, little-endian mode can be used because processors or ARM processors process data according to little-endian. If there are multiple usage scenarios, the data encoding type is determined by the largest supported encoding. For example, in a scenario that includes English characters, other language characters, and network transmission, if UTF8 occupies more bytes, UTF8 is determined as the target data encoding type. When used in different scenarios, the UTF8 encoding is then converted to other encoding formats.

[0122] Furthermore, after the style sheet is generated, the diagnostic equipment can fill the style sheet into the request command and send it to the corresponding vehicle ECU to request vehicle data.

[0123] Furthermore, after receiving the request command, the vehicle ECU parses the style sheet in the request. It then analyzes and judges the style sheet. If the style sheet contains errors, such as the requested DID not existing in the ECU, or incorrect endianness markings, the ECU will reply to the diagnostic equipment that the style sheet contains errors and data cannot be obtained. For an example, see [link to documentation]. Figure 6 , Figure 6This is a schematic diagram of an identifier verification method provided in an embodiment of this application. A diagnostic request message is received by the vehicle bus. Each ECU determines whether to execute the operation corresponding to the diagnostic request message based on the message. For example, the first ECU, second ECU, and third ECU obtain the diagnostic request message from the vehicle bus, parse the message to obtain the DID. If the DID of any ECU matches the DID in the diagnostic request message, it is determined that the ECU can process the request, and this ECU is identified as the target ECU, continuing the subsequent data processing flow. If the DIDs of all ECUs cannot match the DIDs in the diagnostic request message, a diagnostic verification message is returned to the diagnostic device via the vehicle bus, indicating that a response is not possible.

[0124] Accordingly, if the vehicle ECU analyzes the pattern table correctly, it will convert the corresponding data values ​​according to the format defined in the pattern table and fill them into the bytes and bits specified in the response command. After all the data items requested in the pattern table have been filled, the response command is sent to the diagnostic device. The diagnostic device can then parse the values ​​of the requested data items according to the definition in the pattern table and perform operations such as displaying or uploading to the backend server. Since the data item values ​​have already been converted according to the encoding in the pattern table, they can be used directly without further conversion by the diagnostic device; for example, UTF-8 encoded voltage values ​​can be directly uploaded to the backend interface.

[0125] In summary, in this embodiment, a diagnostic request message is first sent to the electronic control unit (ECU). This message includes a target style table, which contains target data items and target format information. The target data items indicate the type of vehicle data to be acquired, and the target format information indicates the response format for the target data items. Then, a diagnostic response message is received from the ECU. This response message includes target vehicle data, which is obtained by converting the initial vehicle data according to the response format. The initial vehicle data corresponds to the vehicle data type. Next, the diagnostic response message is parsed to obtain the target vehicle data. Finally, the ECU is diagnosed based on the target vehicle data. Therefore, by sending a diagnostic request message to the ECU, which includes target format information, and receiving a diagnostic response message from the ECU containing target vehicle data obtained by converting the initial vehicle data according to the response format, and then performing a diagnosis based on the parsed target vehicle data, diagnostic efficiency is improved during vehicle diagnosis.

[0126] The methods of the embodiments of the present invention have been described in detail above, and the apparatus of the embodiments of the present invention is provided below.

[0127] See Figure 7 , Figure 7 This is a schematic diagram of the structure of a vehicle diagnostic device provided in an embodiment of this application. Figure 7 As shown, the vehicle diagnostic device 800 includes a sending unit 801, a receiving unit 802, and a processing unit 803. The sending unit 801 sends a diagnostic request message to the electronic control unit (ECU), wherein the diagnostic request message includes a target style table, which includes target data items and target format information. The target data items indicate the type of vehicle data to be acquired, and the target format information indicates the response format of the target data items. The receiving unit 802 receives a diagnostic response message from the ECU, wherein the diagnostic response message includes target vehicle data, which is obtained by the ECU from initial vehicle data through format conversion according to the response format. The initial vehicle data is vehicle data corresponding to the vehicle data type. The processing unit 803 parses the diagnostic response message to obtain the target vehicle data and performs diagnostics on the ECU based on the target vehicle data.

[0128] In specific implementations, the sending unit 801, receiving unit 802, and processing unit 803 in this application embodiment may also execute other implementations described in the vehicle diagnosis method of this application embodiment, which will not be repeated here.

[0129] See Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 8 As shown, the electronic device 900 includes a transceiver 901, a processor 902, and a memory 903, which are connected via a bus 904. The memory 903 stores computer programs and data, and can transmit the data stored in the memory 903 to the processor 902. The electronic device 900 can be the vehicle diagnostic device 800 or a diagnostic device described above, and the processor 902 can be the transmitting unit 801, receiving unit 802, and processing unit 803 described above. In this embodiment, the processor 902 is used to read the computer program in the memory 903 and execute some or all of the steps of the vehicle diagnostic method described above.

[0130] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the vehicle diagnostic methods described in the above method embodiments.

[0131] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the vehicle diagnostic methods described in the above method embodiments.

[0132] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0133] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical or other forms.

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

[0136] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software program modules.

[0137] If the integrated module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). 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 memory 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 memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0138] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vehicle diagnostic method, characterized in that, Applied to diagnostic devices, the method includes: Send a diagnostic request message to the electronic control unit, wherein the diagnostic request message includes a target style table, the target style table includes target data items and target format information, the target data items are used to indicate the type of vehicle data to be acquired, and the target format information is used to indicate the response format of the target data items; The electronic control unit receives a diagnostic response message, wherein the diagnostic response message includes target vehicle data, the target vehicle data is obtained by the electronic control unit by converting the initial vehicle data according to the response format, and the initial vehicle data is vehicle data corresponding to the vehicle data type. The electronic control unit receives a diagnostic verification message, wherein the diagnostic verification message is used to indicate that the diagnostic response message is verified, and the diagnostic verification message includes a target verification item, wherein the target verification item is format information in the target style table that does not have a mapping relationship with the preset style table; Determine the first format of the vehicle data corresponding to the target verification item in the diagnostic response message; Determine the second format corresponding to the target verification item in the diagnostic request message; Based on the second format and the first format, the vehicle data corresponding to the target verification item in the diagnostic response message is converted to a new format to obtain the verified diagnostic response message. The diagnostic response message is parsed to obtain the target vehicle data; The electronic control unit is diagnosed based on the target vehicle data.

2. The method as described in claim 1, characterized in that, The response format includes: start byte, start bit, byte endianness, bit endianness, bit length, and data encoding type; parsing the diagnostic response message to obtain the target vehicle data includes: The vehicle data type is parsed from the diagnostic response message; The response format is determined based on the vehicle data type. Based on the start byte, start bit, and bit length, determine the data storage location of the vehicle data corresponding to the vehicle data type in the diagnostic response message; The data storage order is determined based on the byte endianness, the bit endianness, and the data encoding type; The diagnostic response message is parsed according to the data storage location and the data storage order to obtain the target vehicle data.

3. The method as described in claim 1 or 2, characterized in that, Before sending the diagnostic request message to the electronic control unit, the method further includes: Determine the target data item and the target format information; The target style sheet is generated based on the target data items and the target format information; The diagnostic request message is generated based on the target style sheet.

4. The method as described in claim 3, characterized in that, Determining the target format information includes: Obtain historical usage data of the diagnostic device; Based on the historical usage data, the application scenario of the diagnostic device is determined, wherein the application scenario is used to indicate at least one of the following data modes of the diagnostic device: data display mode, data transmission mode, and data processing mode; The target format information is determined based on the application scenario and the preset first mapping relationship, wherein the first mapping relationship is used to reflect the correspondence between the application scenario and the target format information.

5. The method as described in claim 3, characterized in that, Determining the target format information includes: Obtain historical data item information for the target data item; Based on the historical data item information, predict the data item character type and data item character count of the target data item, wherein the data item character type includes at least one of the following: numeric type, text type, and language type; Based on the character type and number of characters in the data item, determine the proportion of at least one character. The target format information is determined based on the occupancy ratio of the at least one character and a preset second mapping relationship, wherein the second mapping relationship is used to reflect the correspondence between the occupancy ratio of the at least one character and the target format information.

6. The method as described in claim 3, characterized in that, Determining the target format information includes: Obtain the remaining storage space of the electronic control unit; Obtain a candidate format information corresponding to the electronic control unit; Predict the byte space occupied by each candidate format information to obtain a bytes of space occupied. Based on the remaining storage space and the space occupied by a bytes, the target format information is determined from the a candidate format information.

7. A vehicle diagnostic device, characterized in that, Applied to diagnostic equipment, the apparatus is used to perform the method according to any one of claims 1-6, the apparatus comprising a transmitting unit, a receiving unit, and a processing unit; The sending unit is configured to send a diagnostic request message to the electronic control unit, wherein the diagnostic request message includes a target style table, the target style table includes target data items and target format information, the target data items are used to indicate the type of vehicle data to be acquired, and the target format information is used to indicate the response format of the target data items; The receiving unit is configured to receive a diagnostic response message from the electronic control unit, wherein the diagnostic response message includes target vehicle data, the target vehicle data is obtained by the electronic control unit through format conversion of initial vehicle data according to the response format, and the initial vehicle data is vehicle data corresponding to the vehicle data type. The processing unit parses the diagnostic response message to obtain the target vehicle data; The electronic control unit is diagnosed based on the target vehicle data.

8. An electronic device, characterized in that, include: A processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, the processor being used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-6.

Images