Automobile diagnosis data processing method and device, equipment and storage medium

Abstract

The invention relates to the technical field of vehicle data processing, and discloses an automobile diagnosis data processing method and device, equipment and a storage medium. The method comprises the following steps: collecting a diagnosis communication message of a target vehicle and generating an original data file; locally converting the original data file into an ODX file in a standard format in the equipment; carrying out field correction on the ODX file through an integrated human-computer interaction interface and generating a correction record; and uploading the original data file, the corrected ODX file and the correction record to a cloud diagnosis management platform. According to the method, whole-process field integrated processing of diagnosis data from collection to generation is realized, the problem of low efficiency caused by link splitting in a traditional process is overcome, rework caused by a data quality problem is avoided through a real-time verification mechanism, continuous optimization of diagnosis knowledge is realized by means of a cloud-edge collaborative architecture, and the diagnosis efficiency is improved. And the efficiency and the quality of diagnosis data development are obviously improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle data processing technology, and in particular to a method, apparatus, device, and storage medium for processing vehicle diagnostic data. Background Technology

[0002] In the traditional automotive ECU (Electronic Control Unit) diagnostic data development process, engineers first collect raw diagnostic communication data at a real-vehicle testing site using specialized equipment. After this step, engineers must return to their office environment and upload the acquired data to a remote data center or a local high-performance workstation. The workstation then relies on its computing resources for subsequent data parsing, format conversion, and standardization processing, ultimately generating a diagnostic description file that conforms to the ODX (Open Diagnostic Data Exchange) standard.

[0003] This serialized workflow, due to the forced physical separation of its core processing stages from the data acquisition site, leads to numerous drawbacks. Most notably, engineers cannot verify the completeness and accuracy of the data in real-time at the acquisition end. Any missing data packets, incorrect records, or non-compliant content discovered only in subsequent processing stages means that test vehicles must be re-coordinated, work sites and times rescheduled, and secondary or even multiple data acquisitions must be organized. This reactive rework mechanism not only results in a significant waste of human and time resources, significantly increasing development costs, but also severely slows down the iterative progress of the entire diagnostic data development project, making it difficult to meet the increasingly demanding requirements of modern automotive industry for R&D efficiency and agility. Summary of the Invention

[0004] Based on this, it is necessary to address the technical problems of low efficiency and high rework costs in the existing diagnostic data development process, and propose a method, device, equipment and storage medium for processing automotive diagnostic data.

[0005] Firstly, a method for processing vehicle diagnostic data is provided, the method comprising: Collect diagnostic communication messages from the target vehicle and generate raw data files based on the diagnostic communication messages; Convert the raw data file into a standard ODX file; Modify the ODX file and generate a modification record; Upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0006] Secondly, a vehicle diagnostic data processing apparatus is provided, the apparatus comprising: The acquisition module is used to acquire diagnostic communication messages of the target vehicle and generate raw data files based on the diagnostic communication messages; A conversion module is used to convert the original data file into a standard format ODX file; The modification module is used to modify the ODX file and generate modification records; The upload module is used to upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0007] Thirdly, a portable diagnostic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for processing vehicle diagnostic data.

[0008] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for processing vehicle diagnostic data.

[0009] Beneficial effects: By completing the entire process from data acquisition to ODX file generation on-site using a portable diagnostic device, the physical separation between the traditional on-site vehicle testing and office processing is completely eliminated. This technological feature enables engineers to obtain diagnostic data results instantly, effectively solving the inefficiency problem caused by process fragmentation.

[0010] By integrating ODX file modification functionality and generating modification records on the device side, on-site real-time verification and closed-loop correction of diagnostic data quality are achieved. This allows any missing data or logical errors to be detected and corrected immediately, avoiding the expensive rework required to reschedule vehicle data collection due to errors discovered later in the traditional process. This fundamentally solves the problem of high rework costs.

[0011] By uploading on-site data and correction records to a cloud platform, a collaborative architecture of "edge processing - cloud optimization" was constructed. This not only completed data archiving but also provided a data source for knowledge aggregation and rule optimization in the cloud, enabling continuous improvement in the accuracy of automated processing of subsequent diagnostic tasks. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] in: Figure 1 This is a schematic diagram of the system architecture of a method for processing vehicle diagnostic data in one embodiment; Figure 2 This is a flowchart of a method for processing vehicle diagnostic data in one embodiment; Figure 3 This is a structural block diagram of a vehicle diagnostic data processing device in one embodiment; Figure 4 This is a structural block diagram of a portable diagnostic device in one embodiment. Detailed Implementation

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

[0015] Figure 1 An exemplary system architecture is shown that can be applied to the vehicle diagnostic data processing method or vehicle diagnostic data processing apparatus of this application.

[0016] like Figure 1 As shown, the system architecture may include: a target vehicle 100, a portable diagnostic device 101, and a cloud-based diagnostic management platform 102. The portable diagnostic device 101 and the cloud-based diagnostic management platform 102 can communicate via a network, which serves as the medium for providing communication links between the various units. The network may include various types of wired or wireless communication links, such as: wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables; and wireless communication links including Bluetooth, Wi-Fi, or microwave communication links. The target vehicle 100 and the portable diagnostic device 101 communicate via an automotive diagnostic interface.

[0017] The portable diagnostic device 101 collects diagnostic communication messages from the target vehicle and generates a raw data file based on the diagnostic communication messages; converts the raw data file into a standard format ODX file; modifies the ODX file and generates a modification record; and uploads the raw data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform 102.

[0018] It should be noted that the cloud-based diagnostic management platform includes one or more servers. If there are multiple servers, it can be implemented as a distributed server cluster composed of multiple servers, which is not specifically limited here.

[0019] Portable diagnostic device 101 can be any portable diagnostic device with a display screen, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0020] It should be understood that Figure 1 The number of portable diagnostic devices, networks, and servers shown is merely illustrative. Any number of portable diagnostic devices, networks, and servers can be used depending on implementation needs.

[0021] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a method for processing vehicle diagnostic data provided in an embodiment of the present invention includes the following steps: S1. Collect the diagnostic communication messages of the target vehicle, and generate a raw data file based on the diagnostic communication messages.

[0022] Diagnostic communication messages refer to standardized data units transmitted on the vehicle network bus for diagnosing, configuring, monitoring, or controlling the ECU (Electronic Control Unit). Essentially, they are the basic information carriers for a question-and-answer interaction between diagnostic tools (clients) and the vehicle's electronic control unit (servers) to complete a specific diagnostic task.

[0023] Diagnostic communication messages include the following key fields: Communication identifiers are used to identify the sender and receiver of messages in a bus network. In a CAN bus, this is typically the CAN ID. For example, 0x7E0 often indicates a request from a diagnostic tool, and 0x7E8 indicates a response from an electronic control unit.

[0024] Service identifiers are used to indicate the type of diagnostic service requested. For example, 0x22 represents "read data identifier," and 0x2E represents "write data identifier." This is the "command word" for the diagnostic function.

[0025] Data identifiers are used to represent specific objects or parameters of a service operation. For example, 0xF190 represents a "vehicle identification number" and can answer the questions of "what to read" or "what to write".

[0026] The data payload represents the specific parameters required for service execution or the response data returned by the electronic control unit. For example, in a response message for reading a vehicle identification number (VIN), the data payload is the raw bytes of the VIN code.

[0027] A negative response code is a specific error code that the electronic control unit will return in the response message when a request cannot be executed correctly. For example, 0x13 means "incorrect message length".

[0028] Diagnostic communication is typically based on a "question-and-answer" model. Request messages are proactively sent by the diagnostic tool to initiate a diagnostic action. Response messages are returned by the electronic control unit (ECU) to confirm the result of the request (success or failure). Portable diagnostic devices establish a connection with the vehicle's on-board diagnostic system (OBS) physical interface via their dedicated interface. Upon power-up, the device automatically detects and identifies the communication protocol type used by the vehicle's communication bus. After establishing a stable communication link, the device begins listening for and recording all diagnostic communication messages transmitted on the communication bus. Each successfully captured message is appended with a precise timestamp in real time. The device organizes and stores the message sequence, containing timestamps, communication identifiers, and raw data payloads, into a specific raw data file.

[0029] For example, after the device connects to the diagnostic interface of the test vehicle, it automatically identifies that the vehicle uses the Controller Area Network (CAN) protocol. When a technician triggers a command to read the battery voltage, the device records the request message and the response message from the battery management system. These messages, along with their precise capture time, are written to a file, forming a request record containing timestamp 1634567890.123, communication identifier 0x7E0, and data content 22 F1 90, and a response record containing timestamp 1634567890.135, communication identifier 0x7E8, and data content 62 F1 90 0C 80.

[0030] S2. Convert the original data file into a standard format ODX file.

[0031] In this application, the conversion process is completed collaboratively by the device's local processing engine. The format conversion engine first reads the original data file, performs data cleaning to remove invalid communication frames, and reassembles the multi-frame transmission data according to communication protocol rules to restore the complete diagnostic service unit. Subsequently, the engine queries the device's locally stored data identifier mapping table, mapping the data identifier codes in the message to semantic names and data type definitions, and decodes the data bytes according to the definitions. The decoded information is encapsulated into a structured intermediate data file. The device's built-in lightweight ODX compiler reads this intermediate data file and, according to the locally stored ODX compilation rules, compiles the diagnostic services and data objects into an ODX file conforming to international standards. The format conversion engine performs data cleaning and protocol parsing based on a rule base, specifically including invalid frame filtering and multi-frame reassembly algorithms.

[0032] For example: The format conversion engine identifies a service request for reading data identifier F190 from the raw data. By querying the local mapping table, it is confirmed that F190 represents a vehicle identification number and is a 17-byte ASCII string. The engine decodes the original byte sequence in the response message into a readable string. Based on this information, the ODX compiler creates the corresponding diagnostic service definition in the output file, constructs a request structure containing service identifier 22 and data identifier F190, and a response structure containing service identifier 62 and the vehicle identification number data area.

[0033] S3. Modify the ODX file and generate a modification record.

[0034] Among them, the present application can modify the ODX file manually and / or use a pre-trained lightweight AI model to automatically modify the ODX file. The lightweight AI model is trained based on historical diagnostic data and modification records and is used to automatically correct the semantic mapping of data identifiers. In view of the characteristics of automotive diagnostic data, the lightweight AI model optimizes the mapping accuracy of data identifiers. The lightweight AI model can use gradient boosting decision trees in the training stage and online gradient descent algorithms in the update stage.

[0035] During the manual modification process, after receiving a preview or edit instruction from the user, the human-computer interaction module of the portable diagnostic device calls its ODX file parsing and rendering engine. This engine first reads and parses the ODX file, extracts and converts its internal hierarchical data structure, such as ODX elements like diagnostic services, data object attributes, and request-response parameters, into visual graphical elements. Subsequently, the system renders a graphical editing window on the display unit of the device. This window usually adopts a layout combining a tree list and an attribute panel, presenting complex ODX elements to the user in a well-structured manner and at the same time providing a viewing interface for the original XML source code of the ODX file to achieve the linkage between the graphical view and the source code view.

[0036] For example: The device screen displays an editing interface divided into two columns on the left and right. The left column is an expandable and collapsible tree list. The top-level node is "Battery Management System ECU", under which the sub-node "Diagnostic Service" is expanded, and further services such as "ReadDataByIdentifier_VIN" and "ReadDataByIdentifier_Voltage" are listed under the sub-node. When the user clicks on the "ReadDataByIdentifier_Voltage" service, the attribute panel on the right column displays the detailed information of the data identifier F190 corresponding to this service, including its current semantic description "Battery_Voltage", data type "integer", and editable fields such as the scaling factor.

[0037] Users interact with the editing window via a touchscreen or external input device, triggering specific modification commands. The device's human-machine interface module captures these commands and invokes the corresponding ODX model updater to execute the modification operations. These operations cover direct editing of ODX element attributes, such as modifying the semantic description text of data identifiers; supplementation of diagnostic logic, such as inserting missing secure access seeds and key exchange steps into the diagnostic service sequence; and precise adjustments to data definitions, such as changing the data type of a data object from raw bytes to floating-point numbers, and correspondingly correcting its scaling factor and offset to ensure the accuracy of physical value calculations.

[0038] For example, an engineer locates the data identifier F1A0 in a tree list and finds its automatically generated semantic description is "Unknown". Based on his expertise, he determines that this parameter should be the motor phase current. Therefore, he clicks on the description field and manually changes it to "Motor_Phase_Current". Next, he changes the data type from "Raw Bytes" to "Floating Point" in the data type dropdown menu, and in the adjacent input box, he changes the scaling factor from the default 1 to 0.1 and sets the unit to "A". Furthermore, he discovers that the ODX file is missing the Security Access Service, so he selects "Add Diagnostic Service" from the right-click menu and adds a complete 27-service flow from the template library.

[0039] For every modification made by the user in the graphical interface or source code view, the file synchronization manager within the portable diagnostic device maps and writes the changes to the underlying XML data structure of the ODX file in near real-time. This process ensures that user actions on the interface are immediately reflected in the final output ODX file. Simultaneously, a separate logging module runs concurrently, capturing detailed information for each modification, including the identifier of the modified ODX element, the original value before modification, the new value after modification, the modification timestamp, and the user identifier who performed the modification. This information is structured and saved in a separate modification log file, which is associated with the main version of the ODX file but not embedded within it, thus fully preserving audit trails for human intervention.

[0040] For example, when an engineer changes the description of F1A0 from "Unknown" to "Motor_Phase_Current" and confirms it, the system immediately updates the corresponding information in the ODX file. <short-name>The element content is updated. Simultaneously, a new record is added to the modification log file: "Time: 2023-10-27 10:15:30, User: Engineer_Zhang, Element ID: DID_F1A0, Field: SHORT-NAME, Original Value: Unknown, New Value: Motor_Phase_Current". Similarly, operations such as adding secure access services or modifying scaling factors are also updated and logged in real time.

[0041] During the automated modification process using an AI model, after the portable diagnostic device generates the initial ODX file, the device's built-in intelligent correction engine automatically activates. This engine invokes a lightweight AI model pre-loaded locally on the device and optimized in the cloud. This model scans and analyzes the current ODX file, operating based on learning from a massive amount of historical manual modification records. The model compares elements in the current ODX file (such as data identifiers and service descriptions) with the learned patterns. When it identifies items highly similar to previously corrected error patterns, it automatically generates correction suggestions. These suggestions are directly applied to a copy of the ODX file, generating an "AI pre-corrected version," while simultaneously recording all automatically corrected content and their confidence levels.

[0042] For example, when scanning an ODX file, the AI ​​model encounters a data identifier 0xF1A0, initially described as "Unknown." Based on its learning experience, the model discovers that historically, in ECUs of the "Motor Controller" type, engineers have a 95% probability of correcting a 4-byte response length 0xF1A0 to "Motor_Phase_Current," setting the data type to "Floating-Point," and the scaling factor to 0.1. Due to the high degree of contextual match, the AI ​​model automatically performs this correction with high confidence, updating the description and parameters in the "AI pre-corrected version" of the ODX file. In one possible embodiment, S3, previewing the ODX file on the display unit and modifying the ODX file, includes: S31. Perform preliminary modification operations on the ODX file using a pre-trained lightweight AI model, and display the modified ODX file in the editing window of the display unit; the editing window includes the ODX elements in the modified ODX file.

[0043] The portable diagnostic device, after generating an initial ODX file, automatically invokes its integrated lightweight artificial intelligence model to scan and analyze the file. This model, trained on massive amounts of historical diagnostic data and modification records, can identify common mapping errors or missing definitions in ODX files. By comparing the current ODX elements with learned patterns, the model automatically performs preliminary modification operations, such as correcting the semantic descriptions of data identifiers or supplementing standardized service parameters, generating an optimized intermediate version of the ODX file. Subsequently, the device's human-computer interaction module renders a graphical editing window on the display unit. This window clearly displays all ODX elements in this AI-pre-corrected version in a hierarchical structure, such as the diagnostic service list and data object attributes, preparing for subsequent human interaction.

[0044] For example, when the device's built-in AI model analyzes the initial ODX file, it discovers that the data identifier F1A0 is marked as an unknown parameter. Based on its knowledge base, the model determines that, in the context of the battery management system, this identifier has a very high probability of corresponding to the motor phase current. Therefore, it automatically modifies its semantic description from unknown parameter to motor phase current and sets the data type to floating-point number accordingly. Subsequently, on the device's touchscreen, in the tree list of the editing window, engineers can see that the description of the data identifier F1A0 has been updated to motor phase current, and can view its type and other detailed information in the properties panel.

[0045] S32. Perform a secondary modification operation based on the modification command triggered by the user through the editing window. The secondary modification operation includes modifying the semantic description of the data identifier, supplementing the security access process, or adjusting the type and scaling factor of the data object.

[0046] Engineers review the AI-prepared version and then conduct in-depth verification and interaction through the editing window. The user interface clearly indicates the automatic modifications made by the AI. Based on their professional judgment, engineers can trigger secondary modification instructions for any ODX element. After receiving these instructions, the device performs precise secondary modification operations, covering adjustments to the AI's correction results, such as optimizing the accuracy of semantic descriptions; handling complex logic not covered by the AI, such as supplementing the seed key exchange process required for secure access to protected diagnostic services; and fine-tuning the rules for converting the physical values ​​of data objects, such as adjusting scaling factors and offsets.

[0047] For example, the engineer noticed in the interface that the AI ​​model had corrected the identifier F1A0 to motor phase current, and confirmed that the correction was correct. However, he also discovered that the AI's automatic correction of another identifier, 0B0A, was incorrect, mistakenly associating it with coolant temperature. Therefore, he selected that entry and manually corrected the semantic description to high-voltage contactor status. Furthermore, he found that the ODX file lacked a definition for diagnostic service 27, so he used the interface's add function to create two consecutive diagnostic service steps: 27 01 request seed and 27 02 send key.

[0048] S33. Update the modified ODX file in real time according to the secondary modification operation, and generate modification records for the initial modification operation and the secondary modification operation.

[0049] The portable diagnostic device's file synchronization module responds to every secondary modification by the user, writing the final confirmed changes to the ODX file in real time to ensure a WYSIWYG experience. Simultaneously, a dedicated logging module operates throughout the process, meticulously recording all user actions during secondary modifications, including the modified elements, their original and revised values, as well as the complete content of the initial modification operations performed by the AI ​​model. This comprehensive modification log captures the entire evolution process from the initial state to AI pre-correction and final expert confirmation, providing a robust data foundation for data traceability and model optimization.

[0050] For example, when an engineer manually changes the description of identifier 0B0A from the AI-corrected coolant temperature to the high-voltage contactor status and saves the change, the corresponding field in the ODX file is immediately updated. The system-generated modification log contains two key pieces of information: the first record shows the initial AI modification, changing 0B0A from unknown to coolant temperature; the second record shows the user's secondary modification, ultimately changing 0B0A from coolant temperature to high-voltage contactor status. This detailed log file is stored along with the final ODX file.

[0051] In this embodiment, the initial modification operation is automatically executed by the lightweight AI model, covering common mapping errors; the secondary modification operation is manually executed by the user, covering complex logic corrections.

[0052] This embodiment prioritizes the handling of numerous predictable, routine errors through initial automatic correction using a lightweight AI model, significantly reducing the basic workload of engineers and improving overall efficiency. Subsequently, by guiding experts to focus on verifying the AI ​​correction results and deeply refining complex, proprietary protocols, the irreplaceable value of human experts in critical decision-making and anomaly handling is fully leveraged, ensuring the final quality and reliability of the generated ODX file.

[0053] The training process for lightweight AI models is explained below: The training process aims to build an initial model in the cloud that can automatically understand the semantics of raw diagnostic data. Its core is to use historically accumulated expert knowledge (i.e., manually modified records) to teach the machine.

[0054] The cloud platform extracts all manually modified record files from the massive amounts of task data stored. Each record is constructed as a "sample pair," containing the model's initial incorrect predictions and the engineer's final correct corrections. For example, one sample reveals that the model misclassified the data identifier F1A0 as "unknown," while the engineer corrected it to "motor phase current." Based on this, the platform performs feature engineering, extracting a multi-dimensional feature vector for each sample. These features include the static features of the data identifier itself, the dynamic features of its response message, and the contextual features of the diagnostic session, collectively forming the model's input.

[0055] For example, the platform processes a modification record where the data identifier F1A0 was changed from "unknown" to "motor phase current" by an engineer. The system extracts features for this sample: the hexadecimal value of F1A0, its response length of 4 bytes, the numerical distribution characteristics of the response data bytes, the ECU type to which the request belongs is a motor controller, and the service appears after a secure access session. These features, together with the final correct label "motor phase current," constitute a training sample.

[0056] The platform chose gradient boosting decision trees, a model that combines high accuracy with good interpretability, as its infrastructure. Subsequently, the model was trained using a large number of prepared samples, with the goal of tuning millions of parameters to maximize the probability of the model outputting the correct semantic label when given the aforementioned feature vector. After training, considering the limited computing resources and storage space of edge devices, the model had to be lightweighted. This included pruning to remove neural connections with weak impact on the results and quantization to convert model weights from 32-bit floating-point numbers to 8-bit integers. After this processing, the model size was compressed several times; for example, through pruning and quantization techniques, the model size was compressed from 150MB to 3MB, thus becoming a lightweight AI model suitable for running on portable devices.

[0057] For example, an initial model is trained using hundreds of thousands of samples in the cloud. After training, the model can predict with 85% confidence that F1A0 should be "motor phase current" based on features such as "response length of 4 bytes and ECU type of motor controller". Subsequently, through pruning and quantization, the model size is compressed from 150MB to only 3MB, becoming the initial version V1.0 of a lightweight AI model that can be deployed on portable diagnostic devices.

[0058] The parameter update process of the lightweight AI model is explained below: When portable diagnostic devices are used in the field, the system accurately records any secondary modifications made by engineers to the initial AI-generated results. These records not only contain the final correct answer, but more importantly, they record the differences between the AI's initial judgment and the expert's judgment. When the device is connected to the network, these modification records, rich in new knowledge, are encrypted and uploaded to the cloud platform.

[0059] For example, a device uploads a modification record showing that for the data identifier 0x0B0A, the lightweight AI model V1.0 initially judged it as "coolant temperature" (70% confidence level), but the engineer ultimately corrected it to "high-voltage contactor status". This comparison record of "model prediction - expert correction" becomes the most direct and effective training data for optimizing the model.

[0060] The cloud platform aggregates newly modified records uploaded from tens of thousands of devices, forming an incremental training dataset. Instead of training a new model from scratch, the platform employs an incremental learning strategy. For example, the cloud platform uses online learning algorithms to fine-tune model parameters using the newly modified records and adapts them to edge devices through quantization and compression. Based on the currently deployed model V1.0, it fine-tunes and optimizes its parameters using the new data. This is equivalent to allowing the model to learn the latest and more accurate expert experience based on its existing knowledge. The optimized model undergoes the same compression process, is packaged into a new model parameter file V1.1, and pushed to all connected portable diagnostic devices via OTA technology.

[0061] For example, the cloud collected a large number of modification records related to 0x0B0A, of which 90% of the engineers corrected it to "high-voltage contactor status" instead of the model's predicted "coolant temperature". The platform incrementally trained based on the V1.0 model and these new samples. After training, the new model V1.1 learned this new knowledge, and when it encounters 0x0B0A again, its confidence level for outputting "high-voltage contactor status" will be significantly increased to over 90%.

[0062] The portable diagnostic device silently receives the new model parameter file in the background and stores it in a temporary area. After ensuring the file is complete and error-free, the device automatically replaces the old model file with the new one the next time it starts up or becomes idle. At this point, the device's local lightweight AI model has completed its parameter update, and it will exhibit higher accuracy and broader coverage in subsequent automatic correction of ODX files.

[0063] The next day, when the engineer turned on the portable diagnostic equipment, the device automatically updated the model, and the interface displayed "AI mapping model has been updated from V1.0 to V1.1". When he diagnosed another vehicle of the same type, the model automatically and accurately initialized the 0x0B0A identifier to "high voltage contactor status", without requiring the engineer to manually correct it again.

[0064] S4. Upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0065] When the portable diagnostic device detects an available network connection, it initiates the upload process. The device packages the raw data files, intermediate data files, final ODX file, and modification log files recording human intervention into a complete data task package. This data package is encrypted and then transmitted wirelessly to the enterprise's remote cloud-based diagnostic management platform. This enables centralized archiving and knowledge accumulation of on-site collected data, processing results, and expert experience.

[0066] For example, after completing the diagnostic task, the device connects to the factory wireless network. The user is prompted to confirm the uploaded data packet. Upon confirmation, the device encrypts and packages the original vehicle identification number (VIN) message, structured intermediate data, the corrected ODX file, and a log file recording motor phase current correction entries, and transmits it to the cloud server. The cloud platform can then use this data to optimize mapping rules, providing a more accurate parsing basis for subsequent diagnostic tasks.

[0067] In one possible embodiment of this application, S1, collecting diagnostic communication messages from the target vehicle and generating a raw data file, includes: S11. Establish a communication connection with the target vehicle using the on-board diagnostic interface.

[0068] The portable diagnostic device establishes a mechanical and electrical connection with the vehicle's standard on-board diagnostic interface via its physical connector. After power-on, its internal communication management unit automatically executes a protocol detection process, identifying the specific communication protocol currently used by the vehicle by analyzing the bus's electrical characteristics and signal timing. Based on protocol identification, the device performs a handshake interaction with the target vehicle's network nodes according to the protocol specifications, synchronizing communication parameters and ultimately establishing a stable diagnostic communication link that conforms to the vehicle's network standards. This process enables plug-and-play functionality, eliminating the need for users to manually configure complex network parameters.

[0069] For example, when a portable diagnostic device is plugged into a vehicle's OBD-II interface, the device automatically powers on and begins detection. By analyzing bus levels and message characteristics, it identifies that the vehicle is using the Controller Area Network Flexible Data Rate (CAN) protocol and automatically adjusts its baud rate to 500kbps to synchronize with the vehicle network. Subsequently, the device sends a network management frame to the powertrain control module to confirm the successful establishment of the communication link and prepare for data exchange.

[0070] S12. Listen to the request and response messages generated on the communication bus of the target vehicle within a specified time window through the on-board diagnostic interface to obtain the set of sent and received messages.

[0071] After the communication link is established, the portable diagnostic device configures its bus controller to operate in listener mode. In this mode, the device does not act as an active communicator, but rather as an eavesdropping node on the network, continuously capturing and recording all data frames flowing through the communication bus. The device timestamps each captured data frame using its internal high-precision clock. This process continues within a user-defined or system-preset time window, ultimately forming a raw set of sent and received messages containing all request messages, response messages, and their precise timing information within that time period.

[0072] For example, after the engineer initiates the data acquisition function, the device begins monitoring the powertrain controller LAN bus. Over the next five minutes, the device records all communication data. For instance, at time T1, it captures a frame requesting engine speed reading from the diagnostic tool; at time T2, it captures a response frame containing engine speed data returned by the engine control unit. Between T1 and T2, it may also capture communication frames from other nodes unrelated to diagnostics, such as the body control module. All these frames, along with their timestamps, constitute the initial set of transmitted and received messages.

[0073] S13. Select multiple diagnostic communication messages from the set of transmitted and received messages; each diagnostic communication message includes a timestamp, a communication identifier, and a data payload.

[0074] The data processing unit within the device filters the aforementioned set of transmitted and received messages. The filtering can be based on a pre-installed list of diagnostic communication identifiers within the device. This list contains known source and destination address identifiers used for diagnostic services. The data processing unit compares the communication identifier of each frame in the message set with this list, retaining matching frames and filtering out network management frames, application data frames, or other system communication frames unrelated to the diagnostic service. After this step, each retained diagnostic communication message retains its complete timestamp, communication identifier, and original data payload.

[0075] For example, from the monitored bus messages, the filtering algorithm identifies, based on a preset list, that communication identifier 0x7E0 is typically used to send diagnostic requests to the engine control unit, and 0x7E8 is used to receive its response. Therefore, all messages with communication identifiers of 0x7E0 and 0x7E8 will be retained. For instance, a message with timestamp 1634567890.123, identifier 0x7E0, and data payload 22 F1 90 (request to read VIN code), and a message with timestamp 1634567890.135, identifier 0x7E8, and data payload 62 F1 90 57 56 57… (VIN code response) are filtered out, while a message with identifier 0x123 (possibly corresponding to window control) is filtered out.

[0076] S14. Assemble the multiple diagnostic communication messages into an original data file according to their timestamps.

[0077] The portable diagnostic device invokes the file management module to sort and organize all the filtered diagnostic communication messages according to their timestamps. The sorted message sequence is written to a newly created data file. This file is stored in a standardized structured format, clearly distinguishing each message record into three fields: timestamp, communication identifier, and data payload. This process ultimately generates a time-accurate and structurally sound raw data file, which serves as the data source for the entire system, providing standardized input for subsequent parsing and conversion processes.

[0078] For example, the filtered diagnostic messages are sorted chronologically and written to a CSV file. The first line of this file might be column headers, such as "Timestamp, CAN_ID, Data". Each subsequent line represents a message, such as "1634567890.123, 7E0, 22 F1 90" and the next line "1634567890.135, 7E8, 62 F1 90 57 5657 5A 5A 5A". This complete, time-sorted file is the raw data file A.data, which records the entire sequence of the diagnostic session.

[0079] This embodiment lowers the operational threshold through automated protocol identification and connection establishment; it ensures the integrity and relevance of diagnostic data through comprehensive bus monitoring and precise message filtering; and finally, it generates high-quality, machine-readable raw data files through time-sequential and structured file assembly.

[0080] In one possible embodiment of this application, S2, converting the original data file into a standard format ODX file, includes: S21. The original data file is read through a locally running format conversion engine. Data cleaning and protocol parsing are performed on the original data file to obtain data identifiers. The parsed data identifiers are used to query the data identifier mapping table in the local rule base to obtain the corresponding semantic information. A structured intermediate data file is generated based on the semantic information.

[0081] The portable diagnostic device activates its integrated format conversion engine, which first reads the raw data file from the device's storage unit. Then, the engine performs a data cleaning process, filtering out invalid frames, error frames, and system communication frames unrelated to the diagnostic logic generated during communication, according to predefined rules. After cleaning, the engine performs protocol parsing, reconstructing the data from multiple frames according to communication protocol standards to restore the complete diagnostic service unit and accurately extracting key parameters, including service identifiers and data identifiers. Next, the engine queries the data identifier mapping table stored locally on the device, using the extracted hexadecimal codes of the data identifiers as input to obtain their corresponding semantic names, data type definitions, and data encoding rules. Finally, the format conversion engine integrates all the parsed service information, data identifier semantic information, and decoded data values, encapsulating and outputting them as a structured intermediate data file using a common data exchange format.

[0082] For example, when the format conversion engine processes the raw data file, it encounters a request to read the record containing data identifier F190 and its response record. The engine first verifies that these messages are valid and complete. Next, it parses the service identifier 22 and data identifier F190 from the messages. Then, the engine queries its local data identifier mapping table and learns that F190 represents a vehicle identification number (VIN), its data type is a string, it uses ASCII encoding, and its length is 17 bytes. Based on these rules, the engine decodes the raw byte sequence in the response message into a plaintext string and writes the complete information of this interaction, including the service type, data identifier semantics, decoded value, and original timestamp, into a JSON-formatted intermediate data file.

[0083] S22. The intermediate data file is read by a local lightweight ODX compiler, and the intermediate data file is compiled into an ODX file conforming to the ASAM MCD-2 MC standard according to the ODX compilation rules in the local rule base.

[0084] The portable diagnostic device utilizes its built-in lightweight ODX compiler, designed to operate with limited memory resources. The compiler reads the intermediate data file generated in the previous steps and processes it according to the ODX compilation rule library, also stored locally on the device. The compiler's workflow involves mapping each diagnostic service request and response pair described in the intermediate data file to a diagnostic service element conforming to the ODX standard. It creates a corresponding data object attribute element for each unique data identifier, precisely defining its data type, encoding method, and data length. Simultaneously, the compiler generates matching request and positive response message template structures based on the byte sequence structure of the original message. Finally, the compiler organizes all generated ODX elements according to the standard hierarchical relationship, outputting an ODX file fully compliant with the ASAM MCD-2 MC international standard.

[0085] For example, when processing intermediate data files, the ODX compiler identifies a service record related to reading a vehicle identification number (VIN). According to the ODX compilation rules, it first creates a diagnostic service element in the output ODX file, with the short name defined as ReadDataByIdentifier_VIN. Next, it creates a data object attribute element to define the VIN data type, specifying it as a 136-bit ASCII string. Then, the compiler generates the corresponding request message template, specifying its first byte as the service identifier 22, followed by the data identifier F190. Simultaneously, it generates a positive response message template, specifying its first byte as the response identifier 62, followed by the data identifier F190, and referencing the previously defined VIN data object attribute starting from the third byte. All these elements are integrated into a complete ODX diagnostic layer container, forming the final ODX file.

[0086] This embodiment ensures the quality of input data through data cleaning and protocol parsing, achieves accurate understanding and standardized mapping of diagnostic semantics by querying a local rule base, and finally generates an ODX file that conforms to top industry standards through a lightweight compilation engine. This integrates the complex process, which traditionally relies on cloud computing power, manual intervention, and multi-stage collaboration, into a single portable device and achieves fully automated processing, significantly improving the efficiency of diagnostic data development.

[0087] In one possible embodiment of this application, it further includes: A1. In response to a user-triggered simulation test command, a virtual ECU server is built locally based on the ODX file.

[0088] The process involves a diagnostic simulation that begins when a user triggers the simulation test function through the human-machine interface of a portable diagnostic device. This process includes: first, loading the generated ODX file into memory, where an integrated ODX parser fully parses it to understand all defined diagnostic services, data objects, and communication parameters. Based on this parsing result, a virtual ECU server instance is dynamically created locally on the device. This virtual server completely replicates the diagnostic behavior logic of the target ECU, capable of recognizing and parsing received diagnostic requests, and strictly constructing and returning corresponding diagnostic response messages according to the service flow, data format, and response rules specified in the ODX file.

[0089] For example, a user clicks the "Simulate Test" button on a newly generated ODX file of the battery management system. The device then starts a virtual battery management system server in the background. Based on the ODX file, this virtual server knows that when it receives a request with service identifier 22 and data identifier F190, it needs to reply with a positive response. The response identifier is 62, followed by the data identifier F190, and a 17-byte ASCII string data conforming to VIN encoding rules.

[0090] A2. Send a simulated diagnostic request to the virtual ECU server and receive a simulated diagnostic response returned by the virtual ECU server.

[0091] Once the virtual ECU server is built, the portable diagnostic device automatically acts as the diagnostic client. The test sequence generation module automatically generates a series of standardized diagnostic service request messages based on the ODX file content, such as reading data, reading / writing memory, or executing routine control. These simulated diagnostic requests are sent to the aforementioned virtual ECU server via a virtual communication link within the device. Upon receiving the request, the virtual ECU server immediately processes it in real time and generates a corresponding simulated diagnostic response message, which is returned to the diagnostic client module via the same virtual link. The entire request and response interaction process is completed in a closed loop within the device, without any external vehicle or network connection.

[0092] For example, a portable diagnostic device automatically sends a request message to the virtual battery management system server to read the battery voltage. The message contains three bytes: 22 F1 90. After parsing this request, the virtual server generates and returns a simulated response message based on the service definition in the ODX file, such as 62 F1 90 0C 80, where the last two bytes 0C80 represent a simulated voltage value.

[0093] A3. Compare the simulated diagnostic response with the expected response predefined in the ODX file, and display the comparison result on the display unit.

[0094] The system's result verification module automatically compares the actual simulated diagnostic response returned by the virtual ECU server with the expected response structure predefined for that specific service in the ODX file. The comparison includes, but is not limited to, the response message length, service identifier, data identifier, and the format and range of key data values. After the comparison is complete, the human-machine interface will present the results in a clear visual format on the display unit, for example, by displaying the expected and actual responses side-by-side, and using colors, icons, or text to clearly identify the consistent or differing parts. The system may also provide statistical information on the overall test pass rate.

[0095] For example, the portable diagnostic device's display shows two columns of information side-by-side. One column is "Expected ODX Response," containing "62 F1 90 [17-byte ASCII string]"; the other column is "Actual Virtual ECU Response," containing "62F1 90 57 56 57 5A 5A …". The system compares the two and finds they match perfectly in service identifier, data identifier, data length, and format. Therefore, a green checkmark and the word "Pass" are displayed next to this test case. If the data identifier in the actual response is incorrect, the system highlights the difference and displays "Failed," indicating to the user that there may be an error in the ODX file's service definition.

[0096] This embodiment constructs a precisely functioning virtual ECU environment locally and performs automated diagnostic interactions and result comparisons, enabling engineers to immediately verify the correctness and completeness of ODX files on-site during diagnostic data generation. It can detect and locate logical errors, mapping errors, or missing definitions in the ODX model at the earliest stage, thus avoiding severe rework and time costs caused by bringing defective ODX files into subsequent simulation, flashing, or diagnostic stages. This significantly shortens the development and debugging feedback cycle and improves the accuracy and reliability of diagnostic data development.

[0097] In one possible embodiment of this application, it further includes: B1. Receive update information from the cloud-based diagnostic management platform; wherein the update information includes at least one of the following: optimized ODX compilation rules generated after cloud aggregation and analysis, and optimized data identifier mapping table.

[0098] The cloud-based diagnostic management platform continuously receives encrypted data task packages uploaded from various portable diagnostic devices. Each data package contains raw data files, structured intermediate data files, ODX files, and crucial records of manual modifications. The platform's data access service first decrypts and verifies the integrity of the data packages. Subsequently, data from different devices and vehicle models is automatically cleaned, categorized, and standardized based on its built-in metadata (such as vehicle VIN codes, ECU hardware part numbers, and software version numbers) to prepare for subsequent in-depth analysis.

[0099] For example, the platform receives a total of 50 data task packages uploaded by engineers from Beijing, Shanghai, and Guangzhou for the same "BMS_V2.1" battery management system. The platform first parses these packages to confirm the data integrity, and then groups these 50 data packets into the same analysis cluster according to the ECU model and software version number.

[0100] The platform performs large-scale statistical analysis on all intermediate data files within the same analysis cluster. Its core algorithm calculates the frequency of occurrence of each diagnostic service and data identifier, the statistical distribution of response data length, and the valid range of data values. By identifying diagnostic items with high confidence (e.g., frequency exceeding 95%), the platform can automatically extract a universal diagnostic service set for this type of ECU. Simultaneously, it can also discover and flag ambiguous or proprietary diagnostic items. Based on this statistical consensus, the platform drives the ODX template generation engine to automatically build or optimize a universal ODX diagnostic template with high coverage and precise definition.

[0101] For example, after analyzing 50 "BMS_V2.1" data packets, the platform found that the services "Read Data Identifier F190 (VIN)" and "Read Data Identifier F18C (Total Battery Voltage)" appeared in 100% of the data packets, and the response data format was completely consistent. Therefore, these two services were identified as core services and included in the general template. Meanwhile, it was found that data identifier F1A0 was corrected to "motor phase current" by engineers in 80% of cases, but the definition differed in other cases. The platform will include this diagnostic item and its most likely definition in the template, but add a reliability flag of "Requires on-site confirmation".

[0102] The platform utilizes a massive amount of manually modified records to construct a high-quality supervised learning training dataset. Each record includes a comparison between the "system's initial prediction" and the "expert's final confirmation." The platform uses this data to retrain the diagnostic semantic automatic mapping model. The training process aims to allow the model to learn the engineers' correction logic, thereby enabling it to more accurately predict the semantic names, data types, and scaling factors of data identifiers from raw messages in the future. After training, the model is quantized and compressed to ensure it is suitable for running on resource-constrained edge devices. Finally, the optimized model parameters, or the optimized data identifier mapping table derived from them, are packaged as part of an update package.

[0103] For example, the platform discovered from modification records that the system had incorrectly mapped the data identifier F1A0, with a response length of 4 bytes and an ECU type of "Inverter_V3," to "Unknown." However, engineers generally corrected it to "Motor_Phase_Current" with a scaling factor of 0.1. Through training on a large number of similar samples, the AI ​​model learned this association. After retraining, when the model encounters F1A0 with the same characteristics again, it can directly and accurately output "Motor_Phase_Current" and the correct scaling factor.

[0104] The platform assembles the outputs of the above process—namely, the optimized ODX compilation rules (reflected in the generation logic of the general template) and the optimized data identifier mapping table (or lightweight AI model)—into a specific formatted update package. Before release, this update package undergoes automated testing and compliance verification, such as using standard schemas to verify the conformity of the generated ODX template. The platform also assigns a globally unique version number to each update package and generates detailed changelogs.

[0105] For example, the platform will package the general ODX template fragment of "BMS_V2.1" and the new data identifier mapping table containing the accurate definition of F1A0 into a "rule update package_V2.5". The system automatically verifies that the ODX file generated by this package conforms to the ASAM standard, and then writes information such as version number, update content and applicable conditions into the metadata.

[0106] The platform determines the target group of devices that need to receive this update based on information such as device model and current rule base version. The update information package is placed on the distribution server, waiting to be pushed to the target devices as needed or retrieved by the devices themselves when they connect.

[0107] For example, the cloud platform is configured to mark all portable diagnostic devices that are currently using the V2.4 or earlier version of the data identifier mapping table and have previously diagnosed new energy vehicles as the target push group for "rule update package_V2.5".

[0108] B2. Update the local rule base using the update information.

[0109] The local rule base refers to a collection of data assets, such as rules, templates, and mapping tables, that are pre-stored in the internal memory of portable diagnostic devices to support their offline and automatic completion of diagnostic data parsing and ODX file generation.

[0110] The local rule base is not a single module, but a functional collection of data. Its core components include: data identifier mapping table, ODX compilation rules and templates, communication protocol parsing rules, and optionally, lightweight AI model parameters.

[0111] The data identifier mapping table is a lookup table that associates abstract hexadecimal codes (such as 0xF190) with human-understandable semantic information. It serves as the "translation dictionary" for the format conversion engine and is the cornerstone for converting raw messages into structured data (intermediate data files).

[0112] ODX compilation rules and templates are a set of rules and XML templates that define how to map and assemble structured intermediate data files into ODX files that conform to the ASAM MCD-2 MC international standard.

[0113] Communication protocol parsing rules are rules governing the frame structure, multi-frame reassembly, and timing parameters of different vehicle bus protocols (such as CAN, CAN FD, and DoIP). These rules support the data acquisition module and format conversion engine in correctly parsing the raw byte stream.

[0114] Lightweight AI model parameters represent compressed and optimized machine learning model files, used to assist in more intelligent initial semantic mapping. This improves the accuracy of initial parsing and reduces reliance on manual correction.

[0115] After successfully receiving and decrypting the update data packet, the device initiates the update process. The engine first verifies the format and compatibility of the update data packet. Upon successful verification, an atomic update operation is performed, completely replacing the corresponding old version file in the local rule base with a new data file (such as an optimized ODX compilation rule file or a data identifier mapping table file), or incrementally patching the existing rule base. To ensure system stability, the update process typically takes effect when the device is idle or upon its next startup. After the update is complete, the version number of the local rule base is refreshed, and the device will automatically call the new, more accurate rules and mapping relationships when performing subsequent data parsing and ODX compilation.

[0116] For example, if the received file new_DID_Map_V1.3.txt from the cloud-based diagnostic platform is verified to be in the correct format, the locally stored file old_DID_Map_V1.2.txt is renamed and backed up, and the new file is written to the specified location, updating the mapping table to the currently effective one. Simultaneously, the version number of the mapping table recorded in the system is updated to V1.3. Subsequently, when an engineer diagnoses a vehicle equipped with the new motor controller, the format conversion engine can automatically recognize the previously unresolved data identifier 0x0A45 and accurately map it to "DC_Link_Voltage".

[0117] In one possible embodiment of this application, S4, the step of uploading the original data file, the intermediate data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform, includes: S41. When an available network is detected, the original data file, the intermediate data file, the modified ODX file, and the modification record are packaged into an encrypted data task package.

[0118] The portable diagnostic device periodically or automatically scans for available wireless or wired network connections, triggered by events. Upon detecting a stable and secure network signal, the device's data management unit initiates a packaging process. This unit first gathers four key files related to the diagnostic task: the original data file, the intermediate data file, the final confirmed ODX file, and the modification log file recording all manual corrections. Subsequently, these files are encrypted using an encryption algorithm, and a data integrity checksum is added. Finally, this encrypted data, along with necessary metadata such as the task identifier, device number, and timestamp, is packaged into a single data task package. The entire process ensures the integrity and confidentiality of the dataset to be transmitted.

[0119] For example, the equipment automatically connects to the company's protected Wi-Fi network within the workshop. The system immediately initiates a packaging process, combining the raw message files collected for the battery management system, the parsed structured data files, the final ODX file confirmed and corrected by engineers, and the log file recording operations such as changing the F1A0 parameter from unknown to motor phase current. The system uses the AES-256 algorithm to encrypt the entire data packet and generates a unique task ID associated with it, forming an encrypted data task package ready for upload.

[0120] S42. Upload the encrypted data task package to the cloud-based diagnostic management platform via the available network.

[0121] After the data is packaged and encrypted, the device establishes a secure transmission link with the remote cloud-based diagnostic management platform via an established network connection. This module transmits the encrypted data packet as a data stream through this secure link. The transmission process employs a reliable communication protocol to ensure the stability of the data packet transmission over the network. To cope with unstable network environments, the transmission module supports breakpoint resumption, meaning that after a network interruption and reconnection, transmission can resume from the point of interruption without resending the entire data packet. The device monitors the upload status and clears temporarily sent data packets from its local cache upon successful upload.

[0122] For example, the device establishes a TLS secure channel with the enterprise cloud server via a connected Wi-Fi network. The encrypted data packet is then uploaded through this channel. If the upload is interrupted due to network fluctuations, the system will automatically recognize the interruption and resume transmission from the last interrupted data block position once the network is restored, instead of starting from the beginning. Only after receiving a successful reception confirmation from the cloud will the device interface display "upload successful" and release local temporary storage space.

[0123] Please see Figure 3 As shown, in one embodiment, a vehicle diagnostic data processing apparatus is provided, the apparatus comprising: The acquisition module 301 is used to acquire diagnostic communication messages of the target vehicle and generate raw data files based on the diagnostic communication messages; The conversion module 302 is used to convert the original data file into a standard format ODX file; Modification module 303 is used to modify the ODX file and generate modification records; Upload module 304 is used to upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0124] In one possible embodiment, the step of collecting diagnostic communication messages from the target vehicle and generating a raw data file includes: Establish a communication connection with the target vehicle based on the on-board diagnostic interface; By monitoring the request and response messages generated on the communication bus of the target vehicle within a specified time window through the on-board diagnostic interface, a set of transmitted and received messages is obtained. Multiple diagnostic communication messages are selected from the set of transmitted and received messages; each diagnostic communication message includes a timestamp, a communication identifier, and a data payload. The multiple diagnostic communication messages are assembled into a raw data file according to their timestamps.

[0125] In one possible embodiment, converting the raw data file into a standard ODX file includes: The original data file is read by a locally running format conversion engine, and the original data file is cleaned and parsed to obtain data identifiers. The parsed data identifiers are then used to query the data identifier mapping table in the local rule base to obtain the corresponding semantic information. A structured intermediate data file is then generated based on the semantic information. The intermediate data file is read by a local lightweight ODX compiler, and the intermediate data file is compiled into an ODX file that conforms to the ASAM MCD-2 MC standard according to the ODX compilation rules in the local rule base.

[0126] In one possible embodiment, uploading the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform includes: When an available network is detected, the original data file, the intermediate data file, the modified ODX file, and the modification record are packaged into an encrypted data task package; The encrypted data task package is uploaded to the cloud-based diagnostic management platform via the available network.

[0127] In one possible embodiment, it also includes: The testing module is used to respond to user-triggered simulation test commands and build a virtual ECU server locally based on the ODX file; Send a simulated diagnostic request to the virtual ECU server and receive a simulated diagnostic response returned by the virtual ECU server; The simulated diagnostic response is compared with the expected response predefined in the ODX file, and the comparison result is displayed on the display unit.

[0128] In one possible embodiment, modifying the ODX file and generating a modification record includes: The ODX file is initially modified using a pre-trained lightweight AI model, and the modified ODX file is displayed in the editing window of the display unit; the editing window includes the ODX elements in the modified ODX file. A secondary modification operation is performed based on the modification command triggered by the user through the editing window. The secondary modification operation includes modifying the semantic description of the data identifier, supplementing the security access process, or adjusting the type and scaling factor of the data object. The modified ODX file is updated in real time according to the secondary modification operation, and modification records of the initial modification operation and the secondary modification operation are generated.

[0129] In one possible embodiment, it also includes: An update unit is configured to receive update information from the cloud-based diagnostic management platform; wherein the update information includes at least one of the following: optimized ODX compilation rules generated after cloud-based aggregation and analysis, and optimized data identifier mapping table; The local rule base is updated using the updated information.

[0130] In one embodiment, a portable diagnostic device is provided, which can be a client, and its internal structure diagram can be as follows: Figure 4 As shown, the portable diagnostic device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps of a method for processing automotive diagnostic data.

[0131] In one embodiment, a portable diagnostic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the following steps: Collect diagnostic communication messages from the target vehicle and generate raw data files based on the diagnostic communication messages; Convert the raw data file into a standard ODX file; Modify the ODX file and generate a modification record; Upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0132] This application integrates data acquisition, ODX file generation, and correction functions into a portable on-site diagnostic device, constructing a complete on-site processing loop. It successfully compresses the traditional serial process requiring multi-stage collaboration into minute-level real-time processing, fundamentally solving the inefficiency problem caused by process fragmentation. At the same time, with the help of real-time verification and correction mechanisms, it effectively avoids repeated collection and rework caused by data quality issues, significantly reducing development costs. Finally, through cloud-edge collaborative data backhaul and knowledge accumulation, the system has formed the ability to continuously self-optimize, achieving a dual improvement in the efficiency and quality of diagnostic data development.

[0133] In one embodiment, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, performs the following steps: Collect diagnostic communication messages from the target vehicle and generate raw data files based on the diagnostic communication messages; Convert the raw data file into a standard ODX file; Modify the ODX file and generate a modification record; Upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

[0134] This application integrates data acquisition, ODX file generation, and correction functions into a portable on-site diagnostic device, constructing a complete on-site processing loop. It successfully compresses the traditional serial process requiring multi-stage collaboration into minute-level real-time processing, fundamentally solving the inefficiency problem caused by process fragmentation. At the same time, with the help of real-time verification and correction mechanisms, it effectively avoids repeated collection and rework caused by data quality issues, significantly reducing development costs. Finally, through cloud-edge collaborative data backhaul and knowledge accumulation, the system has formed the ability to continuously self-optimize, achieving a dual improvement in the efficiency and quality of diagnostic data development.

[0135] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or portable diagnostic device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0136] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0137] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0138] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for processing vehicle diagnostic data, characterized in that, The method includes: Collect diagnostic communication messages from the target vehicle and generate raw data files based on the diagnostic communication messages; Convert the raw data file into a standard ODX file; Modify the ODX file and generate a modification record; Upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

2. The method for processing vehicle diagnostic data according to claim 1, characterized in that, The process of collecting diagnostic communication messages from the target vehicle and generating a raw data file includes: Establish a communication connection with the target vehicle using the on-board diagnostic interface; By monitoring the request and response messages generated on the communication bus of the target vehicle within a specified time window through the on-board diagnostic interface, a set of transmitted and received messages is obtained. Multiple diagnostic communication messages are selected from the set of transmitted and received messages; each diagnostic communication message includes a timestamp, a communication identifier, and a data payload. The multiple diagnostic communication messages are assembled into a raw data file according to their timestamps.

3. The method for processing vehicle diagnostic data according to claim 1, characterized in that, The step of converting the original data file into a standard ODX file includes: The original data file is read by a locally running format conversion engine, and the original data file is cleaned and parsed to obtain data identifiers. The parsed data identifiers are then used to query the data identifier mapping table in the local rule base to obtain the corresponding semantic information. A structured intermediate data file is then generated based on the semantic information. The intermediate data file is read by a local lightweight ODX compiler, and the intermediate data file is compiled into an ODX file that conforms to the ASAM MCD-2 MC standard according to the ODX compilation rules in the local rule base.

4. The method for processing vehicle diagnostic data according to claim 3, characterized in that, Uploading the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform includes: When an available network is detected, the original data file, the intermediate data file, the modified ODX file, and the modification record are packaged into an encrypted data task package; The encrypted data task package is uploaded to the cloud-based diagnostic management platform via the available network.

5. The method for processing vehicle diagnostic data according to claim 3 or 4, characterized in that, Also includes: Receive update information from the cloud-based diagnostic management platform; wherein the update information includes at least one of the following: optimized ODX compilation rules generated after cloud aggregation and analysis, and optimized data identifier mapping table; The local rule base is updated using the updated information.

6. The method for processing vehicle diagnostic data according to claim 1, characterized in that, Also includes: In response to a user-triggered simulation test command, a virtual ECU server is built locally based on the ODX file; Send a simulated diagnostic request to the virtual ECU server and receive a simulated diagnostic response returned by the virtual ECU server; The simulated diagnostic response is compared with the expected response predefined in the ODX file, and the comparison result is displayed on the display unit.

7. The method for processing vehicle diagnostic data according to claim 1, characterized in that, The modification of the ODX file and the generation of modification records include: The ODX file is initially modified using a pre-trained lightweight AI model, and the modified ODX file is displayed in the editing window of the display unit; the editing window includes the ODX elements in the modified ODX file. A secondary modification operation is performed based on the modification command triggered by the user through the editing window. The secondary modification operation includes modifying the semantic description of the data identifier, supplementing the security access process, or adjusting the type and scaling factor of the data object. The modified ODX file is updated in real time according to the secondary modification operation, and modification records of the initial modification operation and the secondary modification operation are generated.

8. A device for processing automotive diagnostic data, characterized in that, The device includes: The acquisition module is used to acquire diagnostic communication messages of the target vehicle and generate raw data files based on the diagnostic communication messages; A conversion module is used to convert the original data file into a standard format ODX file; The modification module is used to modify the ODX file and generate modification records; The upload module is used to upload the original data file, the modified ODX file, and the modification record to the cloud-based diagnostic management platform.

9. A portable diagnostic device, characterized in that, The portable diagnostic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method for processing vehicle diagnostic data as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for processing vehicle diagnostic data as described in any one of claims 1 to 7.

Images