Data processing method, apparatus and system

Abstract

The application provides a data processing method, device and system, which is applied to an agent processor in a data processing system, the data processing system comprising a plurality of vehicle processors and a central processor; the central processor is in communication connection with the agent processor and the plurality of vehicle processors, and is used for acquiring driving data packets from the plurality of vehicle processors and sending the driving data packets to the agent processor; the method comprises the following steps: receiving a plurality of driving data packets sent by the central processor, and determining an analysis mode based on the acquisition condition of the interface document of the driving data packet; analyzing the multi-source driving data packet according to the analysis mode, so as to query the planning parameter from a knowledge graph based on a generated data description file; generating a directed acyclic graph used for representing a data processing sequence according to the planning parameter, and processing the multi-source driving data packet according to a dynamic workflow represented by the directed acyclic graph to generate a standardized data packet.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to data processing methods, apparatus and systems. Background Technology

[0002] In the autonomous driving cloud data processing involved in this application, a unified gateway is typically used to access multi-source vehicle raw data, and the data is decrypted, parsed, converted and stored in the database through a cloud pipeline for subsequent algorithm training and simulation testing.

[0003] However, sensor configurations, communication protocols, and data encapsulation methods vary significantly across different vehicle models. Existing solutions often rely on manually writing fixed parsing rules and scripts for vehicle-by-vehicle adaptation. When protocol documentation is missing, fields change, or versions are iterated, the processing flow is easily limited by prior experience, leading to extended access cycles, complex process maintenance, and difficulty in adapting to the continuous changes in heterogeneous data.

[0004] Therefore, it is urgent to address how to improve the adaptability of data access and parsing and reduce the reliance on manual rule configuration in multi-source heterogeneous autonomous driving data processing scenarios. Summary of the Invention

[0005] The data processing method, apparatus, and system provided in this application address the aforementioned technical problems. This solution targets multi-source heterogeneous autonomous driving data processing scenarios. In a data processing system where intelligent agent processors, central processors, and multiple vehicle processors collaborate, it performs unified analysis and processing of driving data packets from different vehicle processors. This allows the data processing process to adapt to the interface documentation of the data packets and constructs a corresponding processing sequence based on data characteristics and planning results. This improves the ability to access and parse driving data from different sources and in different formats, reducing reliance on fixed manual rules.

[0006] In a first aspect, embodiments of this application provide a data processing method applied to an intelligent agent processor in a data processing system, the data processing system including multiple vehicle processors and a central processor;

[0007] The central processor is connected to the agent processor and multiple vehicle processors to obtain driving data packets from the multiple vehicle processors and send them to the agent processor.

[0008] The methods include:

[0009] It receives multiple driving data packets sent by the central processor and determines the analysis mode based on the acquisition of the interface documentation of the driving data packets;

[0010] The multi-source driving data packets are analyzed according to the analysis mode to retrieve planning parameters from the knowledge graph based on the generated data description file;

[0011] Based on the planning parameters, a directed acyclic graph (DAG) is generated to represent the data processing order. Then, the multi-source driving data packets are processed according to the dynamic workflow represented by the DAG to generate standardized data packets.

[0012] In one possible embodiment, after generating the standardized data packet, the method further includes:

[0013] Standardized data packets undergo quality assessment, and if the quality assessment is passed, the standardized data packets are stored in a standardized data lake to transform them into reusable data assets.

[0014] In one possible embodiment, the method further includes:

[0015] If the quality assessment fails, identify the data segments that failed in the standardized data package and repair them.

[0016] If the failed data segment cannot be repaired, an alarm report will be generated.

[0017] In one possible embodiment, repairing the failed data segments includes:

[0018] If a data segment is detected missing in the acquisition device that acquires the multi-source driving data packet corresponding to the standardized data packet, the missing data segment is estimated and the data segment is completed by using the data acquired by other acquisition devices at the same time and the calibration parameters corresponding to the current acquisition device.

[0019] In one possible embodiment, repairing the failed data segments includes:

[0020] Confidence analysis is performed on the repair data segments generated during the repair process to obtain the repair confidence level;

[0021] If the repair confidence level is higher than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair is confirmed to be successful.

[0022] In one possible embodiment, the method further includes:

[0023] If the repair confidence level is lower than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair data segment is marked with questionable annotations, which are then fed back into the knowledge graph.

[0024] In one possible embodiment, after performing quality assessment on the standardized data packets, the method further includes:

[0025] The results of the quality assessment are fed back to the knowledge graph to update the parameters in the knowledge graph, and the data processing strategy of multi-source driving data packets is abstracted into reusable skills and stored in the preset skill library.

[0026] In one possible embodiment, the analysis mode is determined based on the acquisition of interface documents for multi-source driving data packets, including:

[0027] If the interface documentation is obtained, the analysis mode is determined to be the document parsing mode;

[0028] Without obtaining the interface documentation, the analysis mode is determined to be binary mode recognition mode.

[0029] In one possible embodiment, upon obtaining the interface documentation, the multi-source driving data packets are analyzed according to the analysis mode, including:

[0030] Using a large language model, multi-source driving data packets are analyzed and extracted according to preset data extraction requirements to obtain data description files.

[0031] In one possible embodiment, without obtaining the interface documentation, the multi-source driving data packets are analyzed according to the analysis mode, including:

[0032] Binary stream analysis is performed on multi-source driving data packets to match the file header identifiers and delimiter sequences of the multi-source driving data packets, and to infer the encapsulation layer and payload division in order to generate a data description file.

[0033] In one possible embodiment, planning parameters are queried from the knowledge graph based on the generated data description file, including:

[0034] Based on the data description file, index information is generated to retrieve planning parameters from the knowledge graph; the knowledge graph contains the correspondence between various vehicle configuration information and various parsing strategies.

[0035] In one possible embodiment, index information is generated based on the data description file, including:

[0036] Extract vehicle identification and sensor information from the data description file as index information.

[0037] In one possible embodiment, planning parameters are queried from the knowledge graph based on the generated data description file, including:

[0038] Based on the index information, the vehicle configuration information and parsing history in the knowledge graph are queried to obtain planning parameters. The planning parameters include at least: historical processing data, recommendation parser plugin, and calibration parameter storage location.

[0039] In one possible embodiment, a directed acyclic graph characterizing the data processing order is generated based on planning parameters, including:

[0040] Extract data features from the data description file;

[0041] Based on data characteristics and planning parameters, a directed acyclic graph is generated to characterize the data processing order.

[0042] In one possible embodiment, the step of determining the dynamic workflow includes:

[0043] Instantiate each node in the directed acyclic graph as a scheduled task;

[0044] Based on the connection order of each node in the directed acyclic graph, multiple scheduling tasks are sequentially sorted to obtain a dynamic workflow.

[0045] In one possible embodiment, the scheduling task includes at least: a parsing task, a spatiotemporal synchronization task, an encoding task, and a metadata generation task.

[0046] In one possible embodiment, generating standardized data packets includes:

[0047] According to the dynamic workflow, the multi-source driving data packets are processed to obtain parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags;

[0048] Standardized data packets are generated based on parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

[0049] In one possible embodiment, before receiving multiple driving data packets sent by the central processor, the method further includes:

[0050] Receive raw data packets transmitted back from different vehicles;

[0051] Process the original data packets and verify their integrity;

[0052] If the verification passes, the original data packet is stored in the data buffer pool to generate a multi-source driving data packet.

[0053] Secondly, embodiments of this application provide a data processing device applied to an intelligent agent processor in a data processing system, the data processing system including multiple vehicle processors and a central processor;

[0054] The central processor is connected to the agent processor and multiple vehicle processors to obtain driving data packets from the multiple vehicle processors and send them to the agent processor.

[0055] The device includes:

[0056] The receiving module is used to receive multiple driving data packets sent by the central processor and determine the analysis mode based on the acquisition of the interface documentation of the driving data packets;

[0057] The analysis module is used to analyze multi-source driving data packets according to the analysis mode, so as to query planning parameters from the knowledge graph based on the generated data description file;

[0058] The generation module is used to generate a directed acyclic graph (DAG) to represent the data processing order based on planning parameters, and to process multi-source driving data packets according to the dynamic workflow represented by the DAG to generate standardized data packets.

[0059] In one possible embodiment, after generating the standardized data packet, the data processing device is further used to:

[0060] Standardized data packets undergo quality assessment, and if the quality assessment is passed, the standardized data packets are stored in a standardized data lake to transform them into reusable data assets.

[0061] In one possible embodiment, the data processing apparatus is further configured to:

[0062] If the quality assessment fails, identify the data segments that failed in the standardized data package and repair them.

[0063] If the failed data segment cannot be repaired, an alarm report will be generated.

[0064] In one possible embodiment, the data processing apparatus is further configured to:

[0065] If a data segment is detected missing in the acquisition device that acquires the multi-source driving data packet corresponding to the standardized data packet, the missing data segment is estimated and the data segment is completed by using the data acquired by other acquisition devices at the same time and the calibration parameters corresponding to the current acquisition device.

[0066] In one possible embodiment, the data processing apparatus is further configured to:

[0067] Confidence analysis is performed on the repair data segments generated during the repair process to obtain the repair confidence level;

[0068] If the repair confidence level is higher than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair is confirmed to be successful.

[0069] In one possible embodiment, the data processing apparatus is further configured to:

[0070] If the repair confidence level is lower than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair data segment is marked with questionable annotations, which are then fed back into the knowledge graph.

[0071] In one possible embodiment, the data processing apparatus is further configured to:

[0072] The results of the quality assessment are fed back to the knowledge graph to update the parameters in the knowledge graph, and the data processing strategy of multi-source driving data packets is abstracted into reusable skills and stored in the preset skill library.

[0073] In one possible embodiment, the receiving module is further configured to:

[0074] If the interface documentation is obtained, the analysis mode is determined to be the document parsing mode;

[0075] Without obtaining the interface documentation, the analysis mode is determined to be binary mode recognition mode.

[0076] In one possible embodiment, the analysis module is further configured to:

[0077] Using a large language model, multi-source driving data packets are analyzed and extracted according to preset data extraction requirements to obtain data description files.

[0078] In one possible embodiment, the analysis module is further configured to:

[0079] Binary stream analysis is performed on multi-source driving data packets to match the file header identifiers and delimiter sequences of the multi-source driving data packets, and to infer the encapsulation layer and payload division in order to generate a data description file.

[0080] In one possible embodiment, the generation module is further configured to:

[0081] Based on the data description file, index information is generated to retrieve planning parameters from the knowledge graph; the knowledge graph contains the correspondence between various vehicle configuration information and various parsing strategies.

[0082] In one possible embodiment, the generation module is further configured to:

[0083] Extract vehicle identification and sensor information from the data description file as index information.

[0084] In one possible embodiment, the generation module is further configured to:

[0085] Based on the index information, the vehicle configuration information and parsing history in the knowledge graph are queried to obtain planning parameters. The planning parameters include at least: historical processing data, recommendation parser plugin, and calibration parameter storage location.

[0086] In one possible embodiment, the generation module is further configured to:

[0087] Extract data features from the data description file;

[0088] Based on data characteristics and planning parameters, a directed acyclic graph is generated to characterize the data processing order.

[0089] In one possible embodiment, the generation module is further configured to:

[0090] Instantiate each node in the directed acyclic graph as a scheduled task;

[0091] Based on the connection order of each node in the directed acyclic graph, multiple scheduling tasks are sequentially sorted to obtain a dynamic workflow.

[0092] In one possible embodiment, the scheduling task includes at least: a parsing task, a spatiotemporal synchronization task, an encoding task, and a metadata generation task.

[0093] In one possible embodiment, the generation module is further configured to:

[0094] According to the dynamic workflow, the multi-source driving data packets are processed to obtain parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags;

[0095] Standardized data packets are generated based on parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

[0096] In one possible embodiment, the data processing apparatus is further configured to:

[0097] Receive raw data packets transmitted back from different vehicles;

[0098] Process the original data packets and verify their integrity;

[0099] If the verification passes, the original data packet is stored in the data buffer pool to generate a multi-source driving data packet.

[0100] Thirdly, embodiments of this application provide a data processing system, which includes multiple vehicle processors and a central processor;

[0101] The central processor is connected to the agent processor and multiple vehicle processors to obtain driving data packets from the multiple vehicle processors and send them to the agent processor.

[0102] The agent processor in the data processing system is used to perform data processing using the methods provided above.

[0103] Fourthly, embodiments of this application provide an electronic device, including: a processor and a memory;

[0104] The memory stores instructions that the computer executes;

[0105] The processor executes computer execution instructions stored in memory, causing the processor to perform the method provided by the first aspect of the invention described above.

[0106] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the data processing method described in the first aspect of the invention.

[0107] In a sixth aspect, this application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the data processing method described in the first aspect of the invention.

[0108] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0109] The data processing method, apparatus, and system provided in this application determine the analysis mode based on the interface documentation of the driving data package and query planning parameters from the knowledge graph based on the generated data description file. This enables the data processing process to adaptively plan in combination with the actual differences of multi-source driving data, thereby reducing the reliance on manually preset parsing rules and vehicle-by-vehicle adaptation scripts. By generating a directed acyclic graph representing the data processing order based on the planning parameters and processing multi-source driving data packages according to the dynamic workflow represented by the directed acyclic graph, the decryption, parsing, conversion, and standardization processes can be executed in a sequence that better matches the current data characteristics, thereby improving the access efficiency, parsing adaptability, and process maintenance convenience of multi-source heterogeneous driving data. Attached Figure Description

[0110] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0111] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0112] Figure 1 A schematic diagram of the system architecture of the data processing system provided in this application;

[0113] Figure 2 Flowchart of the data processing method provided in the embodiments of this application Figure 1 ;

[0114] Figure 3 Flowchart of the data processing method provided in the embodiments of this application Figure 2 ;

[0115] Figure 4 Flowchart of the data processing method provided in the embodiments of this application Figure 3 ;

[0116] Figure 5 Flowchart of the data processing method provided in the embodiments of this application Figure 4 ;

[0117] Figure 6 Flowchart of the data processing method provided in the embodiments of this application Figure 5 ;

[0118] Figure 7 Flowchart of the data processing method provided in the embodiments of this application Figure 6 ;

[0119] Figure 8 Flowchart of the data processing method provided in the embodiments of this application Figure 7 ;

[0120] Figure 9 This is a schematic diagram of the structure of the data processing method apparatus provided in the embodiments of this application;

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

[0122] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0123] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0124] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the data processing method provided in the embodiments of this application is merely an example, and the data processing method may include more or less content.

[0125] In the field of autonomous driving cloud data processing, a common business model involves multiple vehicle processors continuously transmitting driving data packets. A central processor then aggregates these packets and submits them to a cloud-based intelligent processing unit for unified access, parsing, and storage, supporting subsequent algorithm training, simulation testing, and annotation. Due to the continuous changes in mass-produced vehicle models, test fleets, and sensor combinations, data processing systems need to perform unified analysis and standardized transformation of multi-source driving data in the cloud.

[0126] Existing technologies typically adapt driving data packets vehicle-by-vehicle based on interface documentation and fixed rule scripts. A central processor first receives data transmitted from vehicles, then performs decryption, unpacking, field extraction, and format conversion according to a pre-configured parsing process, before outputting the results to downstream applications. When interface documentation is missing, field definitions change, or vehicle model protocols iterate, the relevant processing logic often needs to be manually rewritten and adjusted, making the process heavily reliant on prior experience. For data packets from different sources, existing solutions lack a unified structure identification method and a mechanism to automatically organize subsequent processing based on parsing results. When faced with continuous inflow of heterogeneous data, this easily leads to parsing failures, slow process switching, and repetitive maintenance work.

[0127] To address the aforementioned technical challenges, a unified data access and analysis link is established between the central processor and the intelligent agent processor. First, the appropriate analysis mode is selected based on the obtained interface documentation. Then, the data description results drive the organization of subsequent processing sequences. Since the differences in structural expression and readability of different driving data packages can be identified and normalized first, planning parameters in the knowledge graph are queried based on this, and a dynamic workflow is generated. The data processing process can revolve around the actual data characteristics, avoiding strong dependence of fixed scripts on new vehicle models and protocols, thereby improving the continuity and standardization of processing after multi-source driving data access.

[0128] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0129] To facilitate understanding, the following will combine... Figure 1 The data processing system applicable to the embodiments of this application will be described.

[0130] Figure 1 A schematic diagram of the system architecture of the data processing system provided in this application. Please refer to [link / reference]. Figure 1 The data processing system 100 includes: an agent processor 101, a central processor 102, and a vehicle processor 103.

[0131] Multiple vehicle processors 103 are deployed on different vehicles to continuously generate and transmit driving data packets. The central processor 102 aggregates and forwards data from different vehicle processors 103, enabling the intelligent agent processor 101 to access multi-source data through a unified entry point. Based on the above method, the intelligent agent processor 101 parses, identifies, and standardizes the driving data packets, and organizes the subsequent processing order according to the data description results, thereby reducing reliance on fixed scripts and manual adaptation.

[0132] Since the central processor 102 is responsible for unified communication connection and centralized forwarding, data from different vehicle models and different protocols can be continuously accessed; and with the adaptive processing capability of the intelligent agent processor 101, the success rate of parsing heterogeneous driving data, processing consistency and subsequent database entry efficiency are improved, making it more suitable for autonomous driving cloud data processing scenarios.

[0133] Furthermore, the intelligent agent processor 101, as the core processing unit of the data processing system 100 of this application, integrates various intelligent agent components and supporting infrastructure to achieve adaptive and standardized processing of multi-source heterogeneous driving data packets. Specifically, the intelligent agent processor 101 may include: a data packet recognition intelligent agent, a planning and scheduling intelligent agent, a cluster of professional execution intelligent agents, a quality assessment intelligent agent, and a feedback learning module, as well as supporting components such as a knowledge graph, a preset skill library, and a data buffer pool.

[0134] Among them, the data packet cognitive agent belongs to the intelligent perception and cognition layer. When the interface document is obtained, it calls the Large Language Model (LLM) to perform semantic analysis and structured information extraction on the interface document. It extracts information such as sensor list, data format, frame structure, field offset, and physical meaning from the unstructured technical document and generates a machine-readable structured JSON description. When the interface document is not obtained, it calls the pre-trained neural network model to perform exploratory analysis on the raw binary data stream. Through file header recognition, delimiter sequence detection, length field parsing, and CRC check code recognition, it infers the data encapsulation level and payload division.

[0135] The planning and scheduling agent, belonging to the dynamic programming and scheduling layer, uses vehicle model identifiers and sensor information from the data description file output by the data packet cognitive agent as indexes to query the knowledge graph and obtain planning parameters such as historical processing experience, recommended parser plugins, and calibration parameter storage locations for that vehicle model. Based on the data features and planning parameters in the data description file, it dynamically generates a Directed Acyclic Graph (DAG), instantiates each node in the DAG as a schedulable task instance, and uses a topological sorting algorithm to determine the linear execution sequence of tasks, resulting in a dynamic workflow. The planning and scheduling agent also acts as a central scheduler, assigning tasks to corresponding agents in the specialized execution agent cluster and managing dependencies and exception handling between tasks.

[0136] The specialized execution agent cluster belongs to the specialized collaborative execution layer. Optionally, the specialized execution agent cluster includes at least one of the following agents: a parsing strategy generation agent, used to retrieve matching parsing script templates from a preset skill library or generate parsing code in real time based on a data description file, decompose the raw data stream, and output atomic data such as raw image frames, point cloud frames, and Controller Area Network (CAN) messages; a spatiotemporal synchronization agent, used to time-align the data from each sensor based on the Global Positioning System (GPS) timestamp and perform coordinate system unification based on the vehicle calibration parameters (intrinsic and extrinsic parameters) stored in the knowledge graph; and a format conversion agent, used to encode and convert the parsed atomic data according to a preset standard format, such as converting H.265 video to JPEG (Joint Photographic Experts Group) image sequences and converting custom binary point clouds to point cloud data. Data (PCD) format files, converting CAN bus messages into standard DBC format; metadata generation agent, used to generate scene metadata and sequence metadata according to the "dataset-scene-sequence-frame" hierarchical structure, enriching the descriptive information of standardized data packets.

[0137] The quality assessment agent, belonging to the quality control layer, is used to perform quality verification on standardized data packets. Specifically, it performs integrity checks (verifying the existence of all expected sensor data and the completeness of frame counts), consistency checks (verifying the consistency between data content and metadata declarations), and quality analysis (calling pre-trained models to detect anomalies such as image blurring and point cloud noise). If the quality assessment passes, the standardized data packet is stored in the standardized data lake; if the quality assessment fails, the failed data segments are identified and repaired using other sensor data from the same period; if repair is impossible, an alarm report containing the anomaly type, anomaly location, and data packet identifier is generated.

[0138] The feedback learning module belongs to the continuous learning and evolution layer and is used to achieve system self-optimization. For example, it collects internal feedback (abnormal cases detected by the quality assessment agent, repair records, and quality scores) and external feedback (data usage issues reported by downstream toolchains). It analyzes the feedback information, abstracts successful processing strategies and parsing scripts into reusable skills and stores them in a preset skill library, performs root cause analysis on failed or under-optimized cases and updates the vehicle configuration parameters and parsing strategies in the knowledge graph, thereby forming a closed loop from "data application" to "processing optimization" and enabling the system to continuously evolve.

[0139] In addition, the intelligent agent processor 101 also integrates the following supporting components: a knowledge graph, used to store configuration information, calibration parameters, parsing history and processing strategies for each vehicle model, which can be organized in the form of a graph database for querying and updating by the data packet recognition intelligent agent and the planning and scheduling intelligent agent; a preset skill library, used to store reusable parsing script templates, format conversion tools and processing flow templates for retrieval and invocation by the parsing strategy generation intelligent agent; and a data buffer pool, used to temporarily store driving data packets forwarded by the central processor 102, supporting sequential reading and processing by the data packet recognition intelligent agent, the planning and scheduling intelligent agent and the professional execution intelligent agent cluster.

[0140] Through the collaborative work of the aforementioned intelligent agent components and supporting components, the intelligent agent processor 101 realizes a complete closed-loop processing flow from data access, cognitive understanding, dynamic planning, professional execution to quality control and continuous learning.

[0141] It should be noted that, Figure 1 Only three vehicle processors are shown in the illustration. In practical applications, the number of vehicle processors can be expanded or reduced according to the actual scenario. This application does not impose any specific restrictions on this.

[0142] Figure 2 Flowchart of the data processing method provided in the embodiments of this application Figure 1 .like Figure 2 As shown, this data processing method is applied to an intelligent agent processor in a data processing system. The data processing system includes multiple vehicle processors and a central processor. The central processor is communicatively connected to the intelligent agent processor and the multiple vehicle processors, respectively, and is used to obtain driving data packets from the multiple vehicle processors and send them to the intelligent agent processor. The method includes:

[0143] S201: Receive multiple driving data packets sent by the central processor, and determine the analysis mode based on the acquisition of the interface documentation of the driving data packets.

[0144] Understandably, completing unified access and preliminary classification of heterogeneous data before it enters the intelligent agent's processing flow can provide a reliable data foundation for subsequent cognitive analysis and dynamic planning. Unified access to multiple driving data packages can eliminate interface differences in multi-source data access; and adaptively select the optimal analysis mode based on the availability of interface documentation, avoiding processing interruptions due to missing documentation.

[0145] In one possible embodiment, after receiving multiple driving data packets forwarded by the central processor, the agent processor can determine the availability of the interface document corresponding to each driving data packet. For example, it searches for the data interface document for the vehicle model in the preliminary metadata associated with the data packet. The search path includes looking for document references in the data packet metadata area, querying the vehicle model knowledge graph to see if the model has already stored an interface document, and searching in the document management system by vehicle identification number or vehicle model identifier. When the interface document is available, the driving data packet is assigned to the document parsing path; when the interface document is unavailable, the driving data packet is assigned to another analysis path, allowing subsequent analysis to adaptively switch based on the existence of the document. Here, the interface document describes the protocol, fields, offset, length, type, and verification rules of the driving data packet, and the analysis mode limits the parsing logic used by the agent processor for the driving data packet.

[0146] To address situations where fleet origins, vehicle models, and sensor combinations differ, the central processor can aggregate driving data packets from multiple vehicle processors before sending them to the agent processor. The agent processor then selects an analysis mode based on the availability of the interface documentation, thus establishing entry conditions for subsequent unified analysis. This step, by binding the analysis entry point to the interface documentation acquisition status, ensures that data packets from different sources enter the corresponding processing paths, avoiding mismatches that occur when protocols change due to direct reliance on fixed scripts in subsequent parsing.

[0147] S202. Analyze the multi-source driving data packets according to the analysis mode, and query the planning parameters from the knowledge graph based on the generated data description file.

[0148] Among them, multi-source driving data packets refer to multiple driving data packets that are aggregated by the central processor and sent to the intelligent agent processor. Each data packet comes from different mass-produced vehicles and may include heterogeneous sensor data such as camera video streams, LiDAR point clouds, millimeter-wave radar echoes, and CAN bus messages.

[0149] Understandably, the data description file can be a structured cognitive description file (such as JSON format) output by the agent processor, containing key information such as vehicle model, sensor list, data format, frame structure, field offsets, and physical meaning. It forms the foundation for all subsequent processing. The knowledge graph is a structured knowledge base that stores the correspondence between various vehicle configuration information and various parsing strategies in the form of a graph database. The planning parameters are parameters obtained from the knowledge graph to guide the generation of the DAG, and at least include historical processing data, recommendation parser plugins, and the storage location of calibration parameters.

[0150] When the analysis mode is determined to be a document parsing path, the agent processor can analyze multiple driving data packets to extract data description files. When the analysis mode is determined to be another analysis path, the agent processor can analyze the driving data packets to generate data description files. The data description files are used to express the structural information, field relationships, and identifiable features of multi-source driving data packets in a machine-readable manner, and may further include relevant information for indexing knowledge graphs.

[0151] Optionally, the knowledge graph stores the relationships between different vehicle models, protocols, sensor deployments, historical parsing results, and processing strategies. The agent processor retrieves knowledge nodes matching the current driving data packet based on relevant information in the data description file, obtaining planning parameters related to subsequent processing. These planning parameters may include at least parser plugin identifiers, field processing order, spatiotemporal synchronization relationships, calibration parameter storage locations, historical processing constraints, and task dependencies. By driving knowledge graph queries through the data description file, the agent processor can transform the identification results of the original driving data packet into a structured set of parameters that can be used for scheduling and orchestration, enabling subsequent processing to be executed based on data characteristics rather than a fixed configuration.

[0152] In this step, the data description file serves to uniformly express the data structure from different sources, while the knowledge graph serves to carry the empirical relationships and strategy mappings. When the two work together, the acquisition of planning parameters can be made independent of manual configuration, thus providing directly usable input for generating the processing sequence.

[0153] S203. Based on the planning parameters, generate a directed acyclic graph to represent the data processing order, and process the multi-source driving data packets according to the dynamic workflow represented by the directed acyclic graph to generate standardized data packets.

[0154] A Directed Acyclic Graph (DAG) is a graph structure composed of nodes and directed edges. Nodes represent data processing tasks, and directed edges represent dependencies between tasks. It contains no cycles and is dynamically generated. A dynamic workflow refers to the workflow sequence obtained by instantiating each node in the DAG as a scheduled task and then sorting them according to their dependencies. Standardized data packets are used to indicate data packets that conform to the "dataset-scene-sequence-frame" hierarchical structure standard after parsing, spatiotemporal synchronization, format conversion, and metadata generation.

[0155] After obtaining the planning parameters, the agent processor can construct a directed acyclic graph (DAG) based on the dependencies, task priorities, and input-output mapping relationships defined in the planning parameters. This DAG maps processing actions such as parsing, denoising, time alignment, coordinate transformation, field encoding, metadata completion, quality verification, and encapsulation output to nodes in the graph. The edges between nodes represent the sequence of tasks and the direction of data flow. For the same batch of multi-source driving data packets, different nodes can select different instantiation parameters based on vehicle source, sensor type, and field integrity, thus ensuring that each node in the DAG corresponds one-to-one with a specific processor task.

[0156] Subsequently, the agent processor drives the dynamic workflow according to the topological order represented by the directed acyclic graph. It sequentially performs unpacking, field extraction, cross-packet association, spatiotemporal synchronization, format unification, and metadata generation for each driving data packet. The processed results are encapsulated into standardized data packets. These standardized data packets can uniformly carry parsing results, time references, spatial references, encoding formats, vehicle type identifiers, sensor identifiers, and processing logs, facilitating subsequent storage, retrieval, training, or simulation.

[0157] Understandably, during the execution of a dynamic workflow, if the input data upon which a node depends does not meet the conditions, the agent processor can skip irrelevant nodes or wait for the preceding nodes to complete before continuing execution, based on the graph structure, to maintain consistency between the entire processing order and the actual data characteristics. This step transforms the planning parameters into an acyclic graph and organizes the execution order accordingly, enabling multi-source driving data packets to complete sequential, structured, and standardized output within the same processing framework, thereby forming a reusable unified data packet.

[0158] Based on the above analysis, this application provides a data processing method, including receiving multiple driving data packets sent by a central processor and determining an analysis mode based on the acquisition of interface documents; analyzing the multi-source driving data packets according to the analysis mode, querying planning parameters from a knowledge graph based on the generated data description file; generating a directed acyclic graph to represent the data processing order according to the planning parameters, and processing the multi-source driving data packets according to the dynamic workflow represented by the directed acyclic graph to generate standardized data packets.

[0159] In this application, by using the availability of interface documentation as the basis for switching analysis modes, data description files as the unified structural expression carrier, and knowledge graphs as the source of planning parameters, and by transforming the planning parameters into a directed acyclic graph to drive dynamic workflow execution, driving data packets from different sources and with different protocol versions can be processed on the cloud side according to a consistent orchestration logic, thereby forming standardized data outputs that can be directly used for subsequent storage, training, and simulation. It should be understood that the above examples are merely illustrative and not limiting.

[0160] This application employs an adaptive switching analysis mode based on interface document acquisition status. Its implementation principle lies in using the existence of a document as a routing condition to guide the original data packet to a document parsing path or a binary recognition path, thereby breaking the dependence of fixed parsing rules on prior knowledge. It unifies the expression of heterogeneous data structures through data description files. Its implementation principle is to transform the physical characteristics of multi-source protocols into machine-readable structural mapping relationships, enabling subsequent processing units to identify field boundaries and semantic levels without manual intervention. It retrieves planning parameters through a knowledge graph. Its implementation principle is to establish graph traversal matching between structural mapping relationships and historical vehicle configurations and parsing strategies, automatically outputting a set of task constraints adapted to the current data. It generates dynamic workflows through directed acyclic graphs. Its implementation principle is to map the dependencies in the planning parameters into topological nodes and directed edges, instantiating tasks and sorting the topology according to acyclic constraints, ensuring that the processing order strictly follows the dynamic reorganization of the actual data characteristics. This solution eliminates the need for manual writing of vehicle-specific adaptation scripts when accessing multi-source driving data. The system can automatically match the parsing logic and execution path based on the inherent structure of the data, completely eliminating the rigid dependence of fixed pipelines on new protocols and new vehicle models, and significantly improving the adaptability, parsing success rate and process maintenance convenience of heterogeneous data access.

[0161] Figure 3 Flowchart of the data processing method provided in the embodiments of this application Figure 2 .like Figure 3 As shown, after S203 generates the standardized data packet, the method also includes:

[0162] S301. Perform quality assessment on the standardized data packets, and if the quality assessment is passed, store the standardized data packets in the standardized data lake to transform the standardized data packets into reusable data assets.

[0163] The quality assessment process is a data verification process used to determine whether standardized data packets meet the conditions for inclusion in the lake. Its verification objects include at least the field integrity, field consistency, and preset quality conditions in the standardized data packets.

[0164] After the standardized data packet is encapsulated, the quality assessment module first reads the metadata, encoding format and field mapping relationship of each data segment, and then checks for missing required fields, field type conflicts, abnormal timestamp order and out-of-bounds value ranges according to the preset verification rules, and summarizes the detection results into the quality assessment results.

[0165] For example, the agent processor traverses the list of sensors declared in the data description file, verifying one by one whether the corresponding data file in the standardized data package exists and whether the number of frames is complete (integrity check); verifying whether the image resolution matches the resolution field declared in the metadata (consistency check); calling the Laplacian ambiguity model to calculate the ambiguity score, and determining frames below the threshold as ambiguous frames (quality analysis). After all checks are passed, a standard directory tree is constructed according to the "dataset-scene-sequence-frame" hierarchical structure, and all standard format data files, metadata files, and directory structures are written to the standardized data lake in an atomic transaction, and a "new standard data ready" event is published through a message queue.

[0166] Understandably, a standardized data lake is a persistent storage area used to store standardized data packets that have passed quality assessment. It can consist of hierarchical object storage, metadata indexing units, and access control units. The hierarchical object storage is used to carry standardized data packets, the metadata indexing units are used to record data sources, parsing versions, and quality labels, and the access control units are used to limit access permissions for subsequent training, annotation, or simulation tasks.

[0167] Furthermore, after the quality assessment is passed, the system writes the standardized data packet along with the corresponding quality label into the standardized data lake, so that the data packet becomes a reusable data asset after archiving is completed. In practical applications, the above storage components can also be selected from other models or implementation methods, which are not limited in this application.

[0168] In this embodiment, the quality assessment and storage of standardized data packets form a closed-loop process. The quality assessment result serves as the sole basis for whether a data packet enters the data lake. Only data packets that meet the requirements of integrity, consistency, and preset quality conditions will be persistently saved and indexed, so that subsequent algorithm training, annotation, and simulation calls can directly retrieve data resources with uniform structure and controllable quality.

[0169] After adopting this implementation method, the standardized data packets are filtered for quality verification before being stored in the data lake, which makes the data entering the data lake traceable and callable. The data after entering the lake can also be repeatedly retrieved and reused according to the metadata index, thereby realizing the accumulation of standardized data packets into reusable data assets.

[0170] This application performs quality assessment on standardized data packets and stores them in a data lake upon passing the assessment. The underlying principle involves scanning and comparing each data segment's field integrity, type consistency, and value range according to preset verification rules, generating a structured assessment conclusion, and using this conclusion as the sole gating signal for data entry control. This mechanism imposes mandatory quality baseline constraints on data entering the storage area, filtering out invalid data with incomplete structures or logical conflicts. This ensures that the data assets stored in the data lake possess high structural uniformity and secure access, directly supporting stable retrieval and reuse for downstream training and annotation tasks.

[0171] S302. If the quality assessment fails, identify the data segments that failed in the standardized data packet and repair them.

[0172] S303. If the failed data segment cannot be repaired, generate an alarm report.

[0173] Among them, the data segment that fails to pass the quality assessment refers to the data segment in the standardized data packet that does not meet the preset quality threshold or integrity constraint. It corresponds to the local area where there are missing fields, abnormal format, out-of-bounds values, timing conflicts, or inconsistent check codes.

[0174] Understandably, repair processing is a remedial procedure performed on the failed data segment. It typically involves calculating and completing missing values ​​based on related fields within the same driving data packet, statistical characteristics of similar historical data packets, or field constraints in a knowledge graph, mapping and replacing outliers, and recalculating the confidence level after repair. Alarm reports are outputs used to record repair failures. They must include at least the location identifier of the failed data segment, the anomaly type, a record of the repair attempt, and the reason for the failure, so that the system or human team can take further action.

[0175] In practical implementation, the evaluation results output by the quality assessment module can be written to segment-level labels. The data processing unit uses these labels to locate abnormal intervals in the standardized data packets and extracts the corresponding byte segments, fields, or record segments as failed data segments. Subsequently, the repair unit selects a repair strategy based on the field type. For example, interpolation or regression estimation is used for continuous sensor values, context-consistent mapping is used for enumerated state values, and neighboring record alignment is used for timestamp anomalies.

[0176] After repair, the system performs consistency and integrity checks on the data segment again. If the checks still fail to meet the repair requirements, the alarm generation unit encapsulates the abnormal information into an alarm report and outputs it to the central processor or maintenance terminal. In practical applications, the repair unit can also use other algorithm models, which are not limited in this application.

[0177] Optionally, an alarm can be triggered when repair is unreachable, enabling the processing chain of standardized data packets to be refined from overall assessment to segment-level handling, reducing the direct discarding of recoverable data. For unrecoverable data, the alarm report provides clear anomaly location and handling basis, allowing subsequent manual review, rule adjustment, or model update to directly target the source of the anomaly.

[0178] By adopting this implementation method, repairable anomalies in standardized data packets can be locally corrected and continue to enter subsequent lake entry or analysis stages, while data that is difficult to repair can be recorded and reported in a timely manner, thereby improving the continuity of data processing, the traceability of anomalies, and the availability of standardized data assets.

[0179] In one alternative implementation, repair processing is performed on the missing data segments, and further physical prior constraint injection and differentiable generation repair can be performed. Specifically: the system constructs an analytical rule base containing vehicle kinematic constraints and sensor field-of-view geometry; during the calculation of missing data segments, a differentiable rendering module is introduced to transform physical constraints into loss function terms, driving the generative neural network to perform constraint optimization in the feature space; the optimized parameters are back-mapped to the data space to generate complete data segments that conform to the laws of physical propagation and geometric continuity.

[0180] Furthermore, the system can perform downstream task impact simulation and adaptive threshold calibration steps: before confidence assessment, the repair data segment is input into a lightweight proxy model sandbox for rapid simulation to predict its performance impact on downstream target detection or trajectory prediction algorithms; based on the simulation results, the confidence judgment threshold is dynamically adjusted, the repair strictness is automatically increased for downstream sensitive tasks, and the threshold is relaxed for non-sensitive tasks to ensure smooth process, and a differentiated repair quality grading report is output.

[0181] This application identifies and repairs failed data segments when a quality assessment fails. If the repair fails, an alarm report is generated. The underlying principle is to break down the overall assessment result to segment-level granularity, call the corresponding compensation algorithm for local reconstruction based on the field anomaly type, and record anomaly metadata and trigger a reporting process when the algorithm fails to converge. This approach allows the data processing chain to refine from overall verification to local self-healing, maximizing the preservation of recoverable data segments and avoiding direct discard. For unrepairable anomalies, the alarm report provides a clear location identifier and failure reason, enabling subsequent manual review or rule adjustments to accurately pinpoint the source of the problem, improving the continuity of data processing and the traceability of anomalies.

[0182] In one alternative implementation, the process of repairing data segments that failed to pass may include:

[0183] If a data segment is detected missing in the acquisition device that acquires the multi-source driving data packet corresponding to the standardized data packet, the missing data segment is estimated and the data segment is completed by using the data acquired by other acquisition devices at the same time and the calibration parameters corresponding to the current acquisition device.

[0184] The acquisition device is used to collect raw driving data within the same time window and output the data source that can be used for repair and estimation to the central processor. Data segment missing means that there is a local data hole that is not collected, not transmitted or not parsed within the corresponding timestamp range, and the hole is identified as a failed data segment by the quality assessment module. The calibration parameters are used to characterize the spatial pose relationship, field of view offset relationship or measurement mapping relationship between the current acquisition device and other acquisition devices, and serve as constraints when estimating missing data segments, so that the completion result is consistent with the coordinate system and field system of the standardized data packet.

[0185] In practical implementation, after generating standardized data packets, the agent processor first performs a consistency check on the continuity of data segments corresponding to each acquisition device, determining whether there are any broken intervals based on timestamps, frame numbers, or field indexes. When it is identified that the current acquisition device is missing a data segment of a preset length within a certain time period, it extracts image data, point cloud data, velocity data, or attitude data acquired by other acquisition devices within the same time window, reads the calibration parameters of the current acquisition device, maps the data from other acquisition devices to the data coordinate system of the current acquisition device, and then performs interpolation, extrapolation, or geometric inversion on the target fields within the missing interval to form a complete data segment corresponding to the missing interval. The completed data segment is then concatenated with the original standardized data packet and written back into the standardized data packet according to the predetermined field order, enabling the repaired data segment to participate in subsequent quality assessment, database entry, or training calls.

[0186] When using this processing method, the estimation of missing data segments depends on redundant acquisition information and calibration constraints within the same time window. The completion result corresponds to the observation relationship of the current acquisition device, thus enabling the partial missing data to be restored to structurally continuous data content, and making the repaired standardized data packets meet the requirements of subsequent unified parsing and storage.

[0187] This application utilizes data from other acquisition devices during the same period and the calibration parameters of the current device to extrapolate missing data segments. Its implementation principle lies in leveraging the spatiotemporal overlap characteristics of multiple sensors to read redundant observation data within the same time window. By combining the spatial pose extrinsic parameters of the current and reference devices, coordinate mapping and geometric interpolation are performed to reconstruct continuous signals within the missing intervals. Through physical extrapolation using the inherent multi-source redundancy characteristics of the vehicle platform, local data gaps are restored to continuous content conforming to spatial geometric relationships. The repaired data segments can seamlessly participate in subsequent data storage or analysis, reducing the risk of data chain breakage due to single-point acquisition interruptions.

[0188] In another optional embodiment, the repair process for the failed data segments further includes:

[0189] Confidence analysis is performed on the repair data segments generated during the repair process to obtain the repair confidence level;

[0190] If the repair confidence level is higher than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair is confirmed to be successful.

[0191] Among them, the repair data segment refers to the candidate data segment generated when the failed data segment is completed, replaced or reconstructed. Its content may come from the associated fields in the same driving data package, the mapping results of other data segments in the same batch, or the content to be adopted derived from the repair rules.

[0192] Understandably, confidence analysis is a process of quantitatively assessing the reliability of candidate content. Its output, the repair confidence score, characterizes the correlation between the repaired data segment and the original data segment, the stability of the content, and its acceptability. The preset threshold is a pre-configured decision boundary set by the system. Its value can be obtained from historical repair results and compared with the currently calculated repair confidence score to determine whether the repaired data segment meets the repair requirements. Repair is defined as the process of replacing or supplementing a failed data segment with a data segment that meets the preset repair requirements, and the repair result being accepted by the system.

[0193] In its implementation, after identifying a failed data segment in a standardized data packet, the agent processor first generates a repair data segment based on the field position, data type, timestamp consistency, and association with context fields of the failed data segment. Then, it calculates the confidence level of the generated repair data segment. The confidence level calculation can employ a weighted scoring method, summing the field consistency score, temporal continuity score, and rule matching score to obtain the corresponding repair confidence level. The weighting coefficients can be determined by preset model parameters and can be updated based on historical successful repair records.

[0194] For example, if the obtained repair confidence is higher than a preset threshold, the repaired data segment is written to the data position corresponding to the failed data segment to form the data content after repair, and the status of the failed data segment is marked as repair passed; if it is lower than the preset threshold, the failed status is maintained and it continues to be processed by subsequent repair logic.

[0195] This method first screens candidate repair content based on credibility before repair, ensuring that the adopted data segments maintain consistency with the semantic and structural characteristics of the original data. This allows the repair results to be confirmed by the system and included in subsequent quality assessments or database processing. Consequently, the repair process for data segments that fail can be automatically determined based on the confidence level, and the repair success status can be clearly recorded, thereby improving the controllability and consistency of the repair results.

[0196] This application performs confidence analysis on the repaired data segments and determines whether the repair passes based on preset thresholds. The underlying principle involves weighted scoring of the repaired data and the original data across three dimensions: field consistency, temporal continuity, and rule matching. A comprehensive confidence score is calculated and compared to the system threshold. If the score meets the threshold, the original abnormal segment is directly replaced; otherwise, it remains blocked. This mechanism filters candidate content for reliability before repair, ensuring that the adopted data segments maintain a high degree of semantic consistency with the original data. The repair pass status is explicitly recorded and proceeds to subsequent stages, improving the controllability, consistency, and efficiency of human-machine collaboration in the repair results.

[0197] Furthermore, if the repair confidence level is lower than a preset threshold, the repair data segment is used to repair the failed data segment, and the repair data segment is marked with questionable annotations, which are then fed back into the knowledge graph.

[0198] The repair confidence level is used to characterize the reliability of the matching between the repaired data segment and the failed data segment. The preset threshold can be pre-configured based on historical repair results, data type consistency requirements, and subsequent data entry standards. The failed data segment is a data fragment that has been determined to be missing, abnormal, or inconsistent through quality assessment. The repaired data segment is the candidate completion content calculated based on the same source data, time-series neighborhood data, or calibration parameters.

[0199] Specifically, questionable annotations are descriptive markers added to low-confidence repair data segments to preserve the uncertain attributes of the repair result and are stored in relation to the repair data segment. The knowledge graph receives questionable annotations and their corresponding repair information, and associates the low-confidence repair experience with the corresponding vehicle type, sensor type, field type, or repair rule node for subsequent queries and parameter updates.

[0200] In actual processing, when the repair confidence level is lower than the preset threshold, the system will still write the repair data segment into the location or field mapping relationship corresponding to the failed data segment to keep the standardized data packet structurally intact. Then, a questionable annotation will be attached to the repair data segment. The annotation may include the confidence level value, the repair source, the timestamp, and the corresponding field identifier.

[0201] Furthermore, after annotation is completed, the system feeds back the repaired data segments and their questionable information to the knowledge graph in a structured format. The knowledge graph updates the trust weights, repair priorities, or candidate parameter sets of the associated nodes based on the feedback. In practical applications, the knowledge graph can be implemented using a graph database or other data structures suitable for storing entity relationships; this application does not impose any limitations on this.

[0202] This approach retains the repair results even when the confidence level is insufficient, ensuring uninterrupted data processing. Simultaneously, it explicitly preserves uncertainty through questionable annotations and embeds relevant feedback into the knowledge graph. This allows subsequent repairs and queries of identical or similar data to reference the recorded low-confidence experience. Therefore, while maintaining continuous data processing, the system can continuously improve the relationships between repair knowledge and the foundation for parameter updates.

[0203] This application, when the repair confidence level is below a threshold, still uses the repair result but adds a questionable annotation and feeds it back to the knowledge graph. The underlying principle is to mark the low-confidence repair data with uncertainty attributes and retain it in the data packet. Simultaneously, the confidence level value, repair source, and anomaly characteristics are written into the associated nodes of the knowledge graph in a structured form, triggering dynamic updates to the graph weights. This approach explicitly isolates low-reliability content while maintaining the continuous flow of the data pipeline. At the same time, it continuously accumulates repair experience by feeding back questionable information into the knowledge graph, enabling the system to reference validated low-confidence handling strategies when encountering similar heterogeneous data later, achieving self-evolution of the processing chain.

[0204] S304. Feed the results of the quality assessment process back to the knowledge graph to update the parameters in the knowledge graph, and abstract the data processing strategy of the multi-source driving data package into reusable skills and store them in the preset skill library.

[0205] The quality assessment results characterize the overall status of standardized data packets in terms of integrity, consistency, field mapping accuracy, and format compliance. Results may include assessment conclusions, repair results for failed data segments, and alarm information. Parameters in the knowledge graph describe the structural characteristics, parsing constraints, field relationships, and processing rules of multi-source driving data packets. These parameters are updated upon receiving the quality assessment results to ensure the knowledge graph reflects the latest data processing conclusions and policy constraints. Data processing strategies describe the parsing, transformation, repair, and data storage logic employed for driving data packets from different sources. These strategies can be abstracted into reusable skills and written into a pre-defined skill library. This library stores accumulated processing capabilities for subsequent use on data packets of the same vehicle model, similar protocols, or similar data structures.

[0206] Understandably, skill abstraction refers to the process of extracting and encapsulating an effective data processing strategy into a reusable, standardized skill module.

[0207] In actual operation, after the agent processor completes the quality assessment of the standardized data packets, it writes the assessment conclusion and the handling results of the failed data segments into the knowledge graph update interface. The knowledge graph then recalculates the parameter weights, rule confidences, and associated edges of the corresponding nodes and simultaneously corrects the retrieval basis of subsequent planning parameters.

[0208] Simultaneously, the system abstracts the unpacking, field alignment, anomaly repair, and alarm linkage logic generated during this processing, extracts the transferable capabilities related to data structure, repair conditions, and output constraints, generates skill descriptions, and registers them in a preset skill library. The skill description may include the skill name, applicable data packet type, input / output constraints, trigger conditions, and execution result flags, for direct invocation in subsequent processing chains. In this application, the skill may correspond to different vehicle model protocols, sensor combinations, or anomaly types. In practical applications, the skill may also choose other encoding methods; this application does not impose any limitations on this.

[0209] For example, the system proactively collects two types of feedback: internal feedback (analyzing failed cases, repair records, quality scores) and external feedback (data issues reported by downstream toolchains, and implicit feedback obtained by monitoring downstream processing success rates and efficiency). For successful cases, effective processing strategies and parsing scripts are abstracted into reusable skills and stored in a skill library, and a "successful processing record" edge is added to the knowledge graph. For failed cases, the differences between failed and successful cases are compared to identify key factors, and the calibration parameters in the knowledge graph are corrected or supplementary protocol field descriptions are added. At the same time, a large amount of successful parsing case data is used to fine-tune the binary pattern to infer model parameters, and downstream efficiency feedback is used to adjust the hyperparameters of the DAG generation decision strategy to optimize the prompt word template of the Large Language Model (LLM).

[0210] By writing the quality assessment results back to the knowledge graph, the system can continuously correct the parameter expressions, ensuring that the subsequent processing is consistent with the actual data quality status. By precipitating data processing strategies into reusable skills and storing them in a preset skill library, the system can reuse historical processing experience and directly serve the processing of subsequent multi-source driving data packets, thereby improving the continuity and consistency of the processing chain.

[0211] In one alternative implementation, the results of the quality assessment are fed back to the knowledge graph to update the graph parameters. Further meta-learning skill generalization and high-value experience replay can also be performed. Specifically: the system performs meta-rule abstraction on sparse successful repair cases and protocol parsing cases, extracting parameter update gradients that can be quickly transferred instead of hard-coded scripts; the extracted results are stored in an experience replay buffer, which uses a priority ranking algorithm based on information gain and scene sparseness to dynamically manage sample weights; during fine-tuning, an elastic weight consolidation strategy is used to protect the mastered stable skill parameters from the impact of new data.

[0212] Furthermore, the system can perform shadow deployment parallel comparison and security rollback circuit breaker steps: establish a sandbox parallel zone isolated from the production environment, and canary release knowledge graph updates and agent policy versions in the form of shadow traffic; continuously collect the differences in indicators between the shadow zone and the production zone in terms of parsing success rate, task latency and downstream quality feedback; when the new policy causes performance degradation or abnormal indicators exceed the security boundary, the circuit breaker mechanism is automatically triggered, the update is immediately frozen and restored to the previous stable version, and a root cause diagnosis report is generated for manual review.

[0213] This application feeds back the quality assessment results to the knowledge graph update parameters and abstracts the data processing strategies into reusable skills stored in the skill library. The underlying principle involves converting the assessment conclusions and repair records into the credible weights and rule confidence levels of the graph nodes for recalculation. Simultaneously, it extracts transferable logic such as package decomposition, field alignment, and anomaly repair to generate skill descriptions containing input and output constraints, which are then registered in the library. This mechanism establishes a closed loop of "execution-verification-feedback-accumulation," enabling the knowledge graph to continuously refine its parameter expressions to align with actual data quality. Furthermore, the skill library reuses historical processing experience to directly serve subsequent data packets, improving the continuity of the processing chain and cross-vehicle adaptation efficiency.

[0214] In one possible embodiment, determining the analysis mode based on the acquisition of interface documents for multi-source driving data packets may further include:

[0215] If the interface documentation is obtained, the analysis mode is determined to be the document parsing mode;

[0216] Without obtaining the interface documentation, the analysis mode is determined to be binary mode recognition mode.

[0217] The "document parsing mode" refers to the structured parsing of the driving data packets sent by the central processor to the agent processor, based on the interface document's definitions of message frame format, field order, field length, encoding method, and verification rules, to generate a corresponding data description file. The "binary pattern recognition mode," when the interface document is missing, identifies frame headers, frame tails, separators, repeated byte segments, and field boundaries based on the original binary stream characteristics of the driving data packets, thus forming a data description file for subsequent analysis. This data description file records field positions, value ranges, and relationships, facilitating subsequent retrieval of planning parameters from the knowledge graph.

[0218] In its implementation, after receiving the data packet forwarded by the central processor, the agent processor first checks the metadata of the data packet to determine whether it carries an interface document index or document address corresponding to the vehicle model protocol. When the index or document address can be parsed and the document text is successfully obtained, the system sets the current analysis mode to document parsing mode and calls the document parsing engine to perform syntax segmentation, field mapping, and protocol constraint extraction on the document. When the document text cannot be obtained, the system sets the current analysis mode to binary pattern recognition mode and calls the binary recognition engine to perform clustering analysis, boundary detection, and pattern merging on the byte sequence of the data packet. Both modes are automatically switched within the system without manual intervention, and the data description files output by different modes maintain a consistent data structure.

[0219] During operation, the mode selection result directly determines the call path of subsequent analyzers. When a document exists, the system quickly builds a parsing template using the explicitly defined fields in the document and applies the template to the corresponding driving data packet. When a document is missing, the system generates field hypotheses based on stable features in the binary stream and then forms a usable structural description through multiple comparisons. Thus, the system can maintain continuous access to multi-source driving data packets in both documented and document-free scenarios, providing consistent input for subsequent planning parameter queries and dynamic workflow generation.

[0220] With this approach, when the interface documentation is available, parsing can be completed directly based on the documentation information, reducing unnecessary recognition overhead. When the interface documentation is unavailable, it can automatically switch to binary mode recognition, ensuring that heterogeneous driving data packets can still form data description files and enter the subsequent processing link, thereby improving the continuity of data access and the determinism of analysis mode switching.

[0221] This application determines the document parsing mode when the interface document is obtained, and determines the binary mode recognition mode when it is not obtained. The implementation principle lies in checking the parsability of the interface document index or address through metadata inspection, and then routing to the corresponding document parsing engine or binary recognition engine using Boolean logic. Both engines output a data description file with a unified structure. This step enables the system to quickly establish a parsing template based on the protocol definition in document-rich scenarios, and automatically switch to raw byte feature recognition in document-free scenarios. This ensures that heterogeneous driving data packets can form a unified structural description and enter subsequent links under different prior conditions, improving data access continuity and mode switching determinism.

[0222] Furthermore, Figure 4 Flowchart of the data processing method provided in the embodiments of this application Figure 3 .like Figure 4 As shown, with the interface documentation obtained, S202, analyzes the multi-source driving data packets according to the analysis mode, including:

[0223] S401. If the interface document is obtained, determine the analysis mode as document parsing mode.

[0224] S402. Using a large language model, analyze and extract multi-source driving data packets according to preset data extraction requirements to obtain a data description file.

[0225] The large language model is used to perform semantic parsing and structural extraction on the interface document and multi-source driving data packets when the interface document is obtained. Its input can include interface document text, data packet samples, field descriptions, and protocol descriptions. Its output is used to characterize the structural features and field relationships of the multi-source driving data packets. The preset data extraction requirements are constraints imposed on the model output, which limit the field names, field levels, data types, timestamps, signal sources, and protocol information corresponding to the interface document to be extracted, so that the output results meet the needs of subsequent querying and parsing.

[0226] In practical implementation, after the interface document is integrated, the intelligent agent processor inputs the document content along with multi-source driving data packets into the large language model. Based on preset data extraction requirements, the model's extraction scope is limited, enabling it to prioritize identifying message boundaries, field mapping relationships, encoding methods, and value rules within the data packets. The extracted structural information is then organized into a data description file. This data description file can be stored as structured text, key-value pairs, or a hierarchical configuration file. It includes field names, field offsets, field lengths, data units, optional enumeration values, and protocol identifiers corresponding to the interface document, facilitating subsequent retrieval of planning parameters from the knowledge graph.

[0227] The working principle of this approach is to first use the interface document to provide protocol semantic constraints for the model, and then use preset data extraction requirements to unify the extraction criteria of the model, so that driving data packets from different sources can be converted into data description files of the same description format. As a result, subsequent processing units can identify the data packet structure and match corresponding processing strategies based on this file, reducing reliance on fixed parsing scripts.

[0228] For example, after the cognitive agent in the intelligent agent processor retrieves the interface document from the data packet metadata area, knowledge graph and document management system, it loads the full text of the document, constructs a prompt containing preset data extraction requirements, specifies the output format as JSON Schema, and determines the analysis mode as document parsing mode.

[0229] Subsequently, the full text of the interface documentation and the prompt words are input into the large language model. The LLM analyzes the technical descriptions in the documentation and returns structured JSON information, including fields such as vehicle_model (vehicle model identifier), sensors array (configuration information such as type, number, format, and resolution of each sensor), timestamp_source (timestamp source), and can_matrix_version (CAN matrix version number). This JSON is the data description file, which serves as the input basis for the subsequent task planning by the planning and scheduling agent.

[0230] With this specific implementation, the structural correspondence between the interface document and the multi-source driving data packet can be stably extracted and standardized. The data description file can be directly used as the basis for subsequent planning parameter queries, so that data packets from different vehicle models and different protocol sources can maintain consistent analysis results when entering subsequent processing, thereby improving the consistency and reusability of data analysis and extraction.

[0231] This application employs a large language model to analyze and extract data from multi-source driving data packets according to preset data extraction requirements. The underlying principle involves inputting the interface document protocol semantics and preset field extraction constraints into the model. Natural language understanding is used to identify message boundaries, field mappings, and encoding rules. The extraction results are then organized into a data description file using a structured template. This approach unifies the model's extraction criteria through prior document constraints, ensuring that data packets from different sources are stably converted into the same description format. The data description file can be directly used as a basis for subsequent planning parameter queries, improving the consistency and reusability of multi-source protocol analysis and extraction.

[0232] Figure 5 Flowchart of the data processing method provided in the embodiments of this application Figure 4 .like Figure 5 As shown, in the absence of interface documentation, S202 analyzes the multi-source driving data packets according to the analysis mode, including:

[0233] S501. In the absence of interface documentation, determine the analysis mode as binary mode recognition mode.

[0234] S502. Perform binary stream analysis on the multi-source driving data packets, match the file header identifier and delimiter sequence of the multi-source driving data packets, and infer the encapsulation level and payload division to generate a data description file.

[0235] Binary stream analysis refers to feature identification and structure inference of the original byte sequence of driving data packets. The file header identifier is used to characterize the starting position or format category of the data packet, and the delimiter sequence is used to characterize the internal field, fragment or level boundary. The two are jointly matched in the binary stream to form an initial judgment on the organization of the data packet.

[0236] The encapsulation hierarchy is a hierarchical structure inferred from the occurrence position, repetition pattern, and nesting relationship of the file header identifier and delimiter sequence. The load division is determined by combining the hierarchical structure to determine the effective data range and boundary range. The data description file is used to record the above structural information and boundary relationships for subsequent querying of planning parameters.

[0237] Specifically, when there is no data interface documentation or the documentation is incomplete, the analysis mode used is to perform exploratory analysis on the raw binary data stream by calling a pre-trained neural network model in order to infer the encapsulation structure of unknown data through binary pattern analysis.

[0238] In actual processing, after the intelligent agent processor receives the multi-source driving data packets sent by the central processor, it first reads the data packets into a binary stream in a fixed-length window, then compares the byte patterns in the window to identify the feature strings that may correspond to the file header identifier, and simultaneously detects byte sequences with repetitive or delimiting significance.

[0239] Specifically, after identifying two types of features, the system infers whether the data packet has a multi-level encapsulation structure based on their relative positional relationship, length variation, and cross-packet consistency. It further divides the header, metadata area, payload area, and tail check area into boundaries, and finally writes the inferred level name, offset address, payload length, and delimiter position into a data description file. This data description file can be stored in structured text or key-value record format, and its field content maintains a correspondence with the planning parameter key-values ​​in the subsequent knowledge graph.

[0240] In this process, the binary stream analysis module can be implemented by a parser in memory. The parser performs sequential scanning and pattern matching on the received driving data packets. When the file header identifier and the delimiter sequence both match, the encapsulation level inference logic is triggered, and a description result is generated based on the payload boundaries. Since data packets from different sources may have different encapsulation methods, the generated data description file can transform the original packet structure into a queryable unified description, thereby providing input for subsequent parameter retrieval and workflow organization.

[0241] For example, a pre-trained neural network model reads the raw binary data stream and performs the following operations in sequence: header recognition (scanning the first bytes to match common header identifiers), delimiter sequence detection (searching for specific delimiter sequences to delineate data segment boundaries), length field parsing (reading the length field after the delimiter to determine the byte length of the data segment), and cyclic redundancy check (CRC) code recognition (detecting the position and type of the CRC checksum at the end of the data segment). Based on the above analysis results, the encapsulation layer, payload division, and possible encoding methods of the data packets are inferred, and a data description file in the same format as the document parsing mode is generated.

[0242] By adopting the above method, even when interface documentation is missing, the data packet structure can still be identified based on the original binary features, and a data description file that can be called for subsequent processing can be generated. This ensures that the analysis results of multi-source driving data packets have a consistent structural expression, thereby supporting subsequent planning parameter queries and dynamic workflow construction.

[0243] In an optional implementation, when the parsing mode is determined to be a binary pattern recognition mode, the structural identification and feature extraction of the data to be processed may also include a multimodal feature cross-validation and dynamic confidence calibration process. Specifically, the system uses a lightweight neural network to scan the file header features, delimiter sequence, and length field in parallel to generate three sets of independent structural inference results; then, a consistency verification engine cross-compares the three sets of results to identify conflicting feature fragments and mark low-confidence regions; combined with the historical protocol evolution patterns of the vehicle platform, an active detection request is initiated for low-confidence regions, sending specific test frames to the vehicle-side agent to obtain feedback verification. Further, the system can execute protocol version drift monitoring and incremental parsing steps: after generating the data description file, the feature hash values ​​of the current parsing result and the historical baseline file are automatically calculated. If the drift threshold is found to be exceeded, an incremental parsing mechanism is triggered, performing a deep scan only on the local data stream where fields have been added, deleted, or changed in type, rather than re-parsing the entire data, and recording the drift pattern in the version evolution map.

[0244] This application performs binary stream analysis on multi-source driving data packets and matches file header identifiers and delimiter sequences to infer encapsulation levels and payload division. Its implementation principle involves reading the original byte sequence in a fixed window for pattern comparison, locating the starting feature string and repeating delimiter markers, and inferring the multi-level encapsulation structure based on relative positions and cross-packet consistency. The level name, offset address, and boundary length are then written into a data description file. This mechanism can still complete structural reverse identification based on the original binary features even when interface documentation is missing, forming a unified description file that can be used subsequently. This ensures that the multi-source data packet analysis results have a consistent structural expression, supporting subsequent parameter retrieval and workflow construction.

[0245] Based on the above embodiments, optionally, the planning parameters are retrieved from the knowledge graph based on the generated data description file, including:

[0246] Based on the data description file, index information is generated to retrieve planning parameters from the knowledge graph; the knowledge graph contains the correspondence between various vehicle configuration information and various parsing strategies.

[0247] The index information is used to convert data packet identifiers, vehicle model identifiers, communication protocol characteristics, and field organization characteristics extracted from the data description file into search keys, which serve as the entry point to access the knowledge graph. Vehicle configuration information is used to characterize the controller model, sensor combination, bus protocol, encapsulation level, and field arrangement characteristics of different vehicle platforms. The parsing strategy is used to characterize the decryption method, unpacking method, field mapping rules, and output organization rules that match different vehicle configurations. The knowledge graph establishes a correspondence between vehicle configuration information and various parsing strategies, and further associates parsing priorities, adaptation conditions, and parameter constraints, enabling the same data description file to be mapped to a set of candidate planning parameters.

[0248] In practical implementation, the data description file can be generated from a large language model or binary stream analysis results, containing a normalized description of the original driving data packet structure. The system performs entity extraction and feature merging on this description file to form index information for querying. The index information includes at least vehicle type index, protocol family index, load structure index, and field pattern index.

[0249] Subsequently, the agent processor performs matching and retrieval in the knowledge graph based on the index information. First, it locates the vehicle configuration information node that matches the vehicle configuration. Then, it searches for the parsing strategy node that is suitable for the vehicle configuration along the corresponding relationship, and reads the planning parameters from the strategy node. The planning parameters may include the parsing order, field extraction rules, node execution priority, and output format constraints, thus providing a basis for the subsequent generation of the directed acyclic graph.

[0250] Optionally, in the construction of the knowledge graph, vehicle configuration information and parsing strategies can be stored using graph database nodes and edges. Node attributes include vehicle platform code, sensor type, communication port, protocol version, and payload structure, while edge attributes include adaptation conditions, adaptation confidence, and policy effectiveness scope. The mapping between index information and graph nodes is accomplished through unified encoding rules, such as encoding vehicle model, interface document features, and data segment organization features into fixed-length query vectors to improve retrieval consistency. After the planning parameters are queried, they are output to the subsequent workflow generation module to determine the dependencies and execution order between various parsing tasks.

[0251] By generating index information based on data description files and retrieving planning parameters from a knowledge graph containing the correspondence between vehicle configuration information and parsing strategies, the system can establish a stable mapping between the structural features of heterogeneous driving data and executable parsing strategies, thereby obtaining a set of processing parameters adapted to the current data packet. Consequently, subsequent data processing can organize the parsing order according to the actual data characteristics and directly transform query results into workflow constraints, improving the consistency and automation of planning parameter acquisition.

[0252] This application generates index information based on data description files and queries planning parameters in a knowledge graph. Its implementation principle involves mapping the structural features in the data description files to fixed-length search keys, performing node matching and edge traversal in a graph database storing the correspondence between vehicle configurations and parsing strategies, and reading the associated parsing priorities and constraint rules as planning parameters. This step establishes a stable mapping between the underlying structural features of heterogeneous data packets and executable parsing strategies. The acquisition of planning parameters does not rely on manual configuration item by item, and subsequent processing can organize the parsing order according to actual data characteristics, improving the consistency and automation of parameter acquisition.

[0253] Furthermore, Figure 6 Flowchart of the data processing method provided in the embodiments of this application Figure 5 .like Figure 6 As shown in S202, planning parameters are retrieved from the knowledge graph based on the generated data description file, including:

[0254] S601. Extract the vehicle model identification and sensor information from the data description file as index information.

[0255] The vehicle model identifier is used to identify the vehicle platform or model origin, and serves as a key retrieval key when querying the knowledge graph in this solution. Sensor information is data used to characterize the sensor types, configurations, or combinations within multi-source driving data packages; it, along with the vehicle model identifier, constitutes the foundation of the index information. Both the vehicle model identifier and sensor information originate from structured content in a data description file. This data description file can be generated from interface document parsing results or binary stream analysis results, and is recorded in the file in the form of fields, tags, hierarchical nodes, or key-value pairs.

[0256] In the specific implementation, after obtaining the data description file, the intelligent agent processor performs field parsing and semantic extraction. First, it locates the platform number, model code, vehicle configuration code or equivalent description field used to identify the vehicle model. Then, it locates the field used to characterize the sensor type, quantity, installation location, sampling frequency or channel mapping relationship, and normalizes the two into a unified index expression.

[0257] Specifically, normalization processing may include mapping synonymous field names, standard encoding of enumeration values, and completion and recognition of structural content with missing delimiters, so that vehicle identification and sensor information can be written into the index cache or index table with a fixed key-value structure.

[0258] In practical applications, the index table can take the form of a hash index, a key-value index, or a vectorized index, so that the vehicle configuration information and the corresponding parsing strategy in the knowledge graph can be quickly queried based on the vehicle identification and sensor information. In practical applications, the index structure can also be implemented in other ways, and this application does not limit it.

[0259] During operation, the system first extracts vehicle model identification and sensor information from the data description file, then combines the two into index information and sends it to the knowledge graph retrieval module. The retrieval module matches the corresponding planning parameters based on this information and uses the matching results for subsequent data processing sequence organization. Because the index information directly reflects the vehicle platform characteristics and sensor configuration characteristics, candidate parsing strategies in the knowledge graph can be accurately located, thereby enabling subsequent processing links to establish a correspondence based on the actual vehicle model and sensor combination.

[0260] After adopting the above implementation method, the key structural content in the data description file can be directly converted into index information, the vehicle source and sensor configuration can be uniformly expressed, the input of knowledge graph query is more explicit, and the matching planning parameters are more correlated with the current multi-source driving data package, thereby improving the accuracy and consistency of subsequent parsing and standardization processing.

[0261] This application extracts vehicle model identification and sensor information from the data description file as index information. The implementation principle involves parsing and semantically extracting fields from the description file, locating the platform number, vehicle model code, and sensor type / quantity / location fields. These are then normalized into a fixed key-value structure through synonym mapping and standard encoding before being sent to the knowledge graph retrieval module. Consequently, key structural content is directly transformed into a clear retrieval entry point, allowing for a unified expression of vehicle model origin and sensor configuration. This results in more accurate knowledge graph query input, stronger correlation between the matched planning parameters and the current data packet, and improved accuracy in subsequent parsing and standardization processing.

[0262] S602. Based on the index information, query the vehicle configuration information and parsing history in the knowledge graph to obtain planning parameters. The planning parameters include at least: historical processing data, recommendation parser plugin, and calibration parameter storage location.

[0263] Among them, vehicle configuration information is used to represent the basic configuration relationships corresponding to the vehicle model, and parsing history is used to record the historical results of the vehicle model in previous data access, field recognition, format conversion, and database processing. Together, they constitute the association basis for knowledge graph retrieval. Index information is extracted from the data description file and may include vehicle model identifier, sensor combination identifier, data packet type identifier, and parsing mode identifier. After receiving the index information, the knowledge graph associates and matches it with the vehicle configuration information node and the parsing history node, thereby outputting the planning parameters corresponding to the current multi-source driving data packet.

[0264] In the specific implementation, historical processing data is used to indicate the previous processing results, failure records, and repair records of the vehicle model or similar data packets, so that subsequent processing units can continue to use the verified data organization method; the recommended parser plugin is used to indicate the parsing capability components that are adapted to the current data packet structure. The plugin can be deployed as an independent software module and interface with the basic parsing framework to complete field extraction, protocol adaptation, and format conversion; the calibration parameter storage location is used to indicate the location information of the calibration parameters in the calibration library, object storage, or distributed file system, for subsequent reading during spatiotemporal synchronization, coordinate transformation, or sensor alignment.

[0265] Correspondingly, the knowledge graph performs a joint retrieval of vehicle configuration information and parsing history during the query, and encapsulates the query results as planning parameters for subsequent dynamic workflow generation and data packet processing.

[0266] This solution establishes a correspondence between data description files and vehicle configurations, parsing experience, and calibration resources in the knowledge graph through indexing information. This allows planning parameters to directly reflect the structural characteristics and historical processing basis of the current data packet, thus providing a unified input for parser plugin selection and calibration parameter invocation. Consequently, subsequent processing can organize the parsing chain based on the matched planning parameters, enabling data packets from different vehicle models and different sensor combinations to be processed according to corresponding historical experience.

[0267] In one optional implementation, planning parameters are retrieved from the knowledge graph using a search index, and multi-dimensional strategy scoring and dynamic resource game decision-making can be further performed. Specifically, after retrieving the candidate processing strategy set from the knowledge graph, the strategy scoring network is invoked to calculate the historical success rate, algorithm compatibility score, and current cloud cluster node load redundancy of each strategy in turn; the scores are weighted and fused using a lightweight game decision-maker to eliminate low-optimal strategies with resource contention risks; finally, a decision vector with priority ranking and resource binding suggestions is output. Furthermore, the system can perform bottleneck prediction and dynamic branch injection steps: before generating the directed acyclic graph, a lightweight performance simulation sandbox is built based on historical execution logs to virtually deduce the candidate DAG and identify link nodes that may cause I / O accumulation or computing node overload; if a bottleneck is predicted, a dynamic parallel branch or task splitting node is automatically inserted into the DAG, and resource allocation hints are attached to the instantiated task parameters.

[0268] This application obtains planning parameters based on querying vehicle configuration information and parsing history in a knowledge graph using indexed information. Its implementation principle involves jointly retrieving vehicle identification and sensor combination indexes with configuration nodes and historical record nodes in the graph. It reads past processing results along the associated edges, recommends parsing plugin identifiers and calibration parameters, stores and locates them, and then encapsulates and outputs them. The planning parameters directly reflect the current data packet structure characteristics and historical processing basis, providing a unified input for parser plugin selection and calibration resource invocation. This enables data packets with different vehicle models and sensor combinations to be processed according to corresponding historical experience, improving the accuracy of strategy matching.

[0269] Figure 7 Flowchart of the data processing method provided in the embodiments of this application Figure 6 .like Figure 7 As shown, in S203, based on the planning parameters, a directed acyclic graph (DAG) is generated to represent the data processing order. Then, according to the dynamic workflow represented by the DAG, the multi-source driving data packets are processed to generate standardized data packets, including:

[0270] S701. Extract data features from the data description file.

[0271] S702. Based on data characteristics and planning parameters, generate a directed acyclic graph to characterize the data processing order.

[0272] Data features are used to characterize the feature information related to the processing order in the data description file. As one of the inputs for generating the directed acyclic graph, they can be composed of vehicle model identification, sensor type, data segment boundaries, field dependencies, and load organization methods parsed from the data description file. The data description file can be obtained by parsing the interface document or analyzing the binary stream. After normalization, the semantic and structural tags of each field in the file are extracted into computable feature vectors for subsequent graph structure mapping.

[0273] In actual implementation, the system first performs field scanning and semantic extraction on the data description file, organizes the attributes related to the order of data processing into node candidate information, and then introduces the recommended parser plugin, historical processing data and calibration parameter storage location in the planning parameters into the graph construction rules to determine the dependency constraints, parallel constraints and pre- and post-relationships between each node.

[0274] Subsequently, a directed acyclic graph (DAG) is generated based on the constraints, with nodes in the graph corresponding to processing units such as decryption, unpacking, field extraction, format conversion, and validation, and edges corresponding to the data transmission order and triggering relationships between processing units. The generated DAG can be stored as an adjacency list or adjacency matrix and used as input for subsequent dynamic workflow scheduling.

[0275] In this implementation, the actual structural features in the data description file and the parsing strategy reflected by the planning parameters are jointly mapped to the same graph model, enabling the graph structure to be updated according to different vehicle protocols and data packet formats. After the graph is generated, the agent processor organizes and processes the multi-source driving data packets according to the topological order represented by the graph, and outputs a standardized processing sequence that matches the current data features.

[0276] After adopting the above method, the data processing order no longer depends on a fixed script, but is determined by the structural information and planning parameters in the data description file. The generated results can directly represent the processing path and dependencies of the current data packet, thereby ensuring that the subsequent processing links are consistent with the actual data characteristics and improving the processing continuity and standardization after multi-source driving data access.

[0277] This application extracts data features from data description files and generates a directed acyclic graph (DAG) based on these features and planning parameters. The underlying principle involves extracting field types, data segment boundaries, and load organization methods as node candidate information. This information is then combined with dependency constraints and parallel conditions in the planning parameters to determine the task sequence. Finally, processing units are mapped to graph nodes, and data flow is mapped to directed edges. The data processing order no longer depends on a fixed script but is jointly determined by the actual data structure characteristics and planning parameters. The generated graph structure can be dynamically updated according to changes in vehicle model protocols and data packet formats, ensuring that subsequent processing links remain consistent with the actual data characteristics and improving the continuity and standardization of processing after multi-source data access.

[0278] S703. Instantiate each node in the directed acyclic graph as a scheduling task.

[0279] S704. Based on the connection order of each node in the directed acyclic graph, multiple scheduling tasks are sequentially sorted to obtain a dynamic workflow.

[0280] In this context, nodes are used to form processing units in a directed acyclic graph, representing individual processing steps related to the processing of multi-source driving data packets. The connection order is used to represent the sequential dependencies between nodes. The scheduling task is used to carry the executable work corresponding to the node. The dynamic workflow is used to describe the ordered sequence of task execution.

[0281] In practical implementation, the system first reads the directed acyclic graph generated from data features and planning parameters, and maps each node in the graph to a task object. Each task object contains at least a task identifier, input data reference, processor type, and output result fields. For different nodes in the graph representing parsing, verification, transformation, or data entry, the task object can be bound to the corresponding parser plugin, rule configuration, or data verification logic. A one-to-one correspondence is established between nodes and task objects to transform abstract processing relationships into schedulable execution units.

[0282] After instantiating nodes, the system extracts dependency edges based on the connections between nodes in the directed acyclic graph and sorts task objects according to the topological constraint that parent nodes precede child nodes. For nodes with parallel relationships, the system generates concurrently executable task fragments while keeping dependency constraints unchanged, and combines them with preceding and subsequent tasks to form a complete scheduling sequence. The resulting dynamic workflow can be regenerated as the input data description file and planning parameters change, thus organizing processing links from different vehicle sources and under different protocol structures into executable links.

[0283] For example, during DAG generation, the required processing nodes are determined based on data characteristics (e.g., if H.265 video is included, an H.265 decoding node is needed). Parser plugins and processing sequences from the knowledge graph that have been successfully processed in the past are used preferentially. The order of nodes is determined based on the data processing logic (e.g., time synchronization must be performed after parsing and before format conversion; metadata generation can be performed in parallel with format conversion). The generated DAG is stored as a graph data structure, where each node contains task type and parameter configuration, and each directed edge represents a preceding dependency.

[0284] In this implementation, the mapping relationship between scheduling tasks and nodes allows the graph structure to be directly transformed into executable objects. The connection-driven sorting mechanism ensures that the task execution order remains consistent with data processing dependencies, while the dynamic workflow orchestrates the parsing, extraction, transformation, and output processes into a continuous execution chain. Using this approach, the system can quickly organize tasks based on the graph structure corresponding to different data packets, ensuring consistency and reconfigurability in the processing order of subsequent multi-source driving data packets.

[0285] In one alternative implementation, each processing node in the directed acyclic graph is instantiated as an independent scheduled task, and further state-aware task encapsulation and data lineage binding can be performed. Specifically, each logical node is encapsulated as a proxy instance with runtime state reporting capabilities, and an automated checkpoint snapshot mechanism is embedded within the instance; a unique data lineage identifier is bound to each task, and a link index is established between input data, processing code version, and output middleware; during instantiation, fault-tolerant retry strategies and memory leak detection probes are automatically injected.

[0286] Furthermore, the system can perform runtime DAG adaptive reconstruction and breakpoint resume steps: the scheduler continuously monitors the execution metrics of each instance node. If a node triggers a timeout or abnormal interruption, the lightweight routing engine immediately captures the fault context, dynamically trims the original DAG path based on the cached middleware snapshot and data lineage index, and generates an alternative flow topology to avoid the faulty node. The system continues to dispatch the remaining tasks according to the new topology and uses the breakpoint resume mechanism to restore data flow from the most recent checkpoint without resetting the entire pipeline.

[0287] This application instantiates each node in a directed acyclic graph (DAG) as a scheduled task and obtains a dynamic workflow based on the connection order. Its implementation principle involves reading the DAG topology, binding abstract nodes to specific task objects (including identifiers, input references, and processor types), performing topological sorting of task objects based on the dependency constraint that parent nodes precede child nodes, generating concurrent fragments for parallel nodes, and combining them into a complete scheduling sequence. This directly transforms the graph structure into executable objects. The connection order-driven sorting mechanism ensures that the task execution order strictly matches data dependencies. The dynamic workflow unifies the parsing, transformation, and other processing stages into a reconfigurable execution link, improving the stability and scheduling determinism of the processing order of data packets from different sources.

[0288] The scheduling tasks include at least: parsing tasks, spatiotemporal synchronization tasks, encoding tasks, and metadata generation tasks.

[0289] In this embodiment, the parsing task is used to disassemble, identify fields, and analyze content of the original driving data packet; the spatiotemporal synchronization task is used to align timestamps, unify sampling beats, and register spatial coordinates of the parsed multi-source data; the encoding task is used to convert the synchronized data into a unified encoding format and output a standard field sequence; and the metadata generation task is used to generate metadata carrying semantic tags based on the parsing results, synchronization results, and encoding results.

[0290] For example, scheduling tasks can be instantiated from nodes in a directed acyclic graph. The connections between nodes are used to define the execution order and dependencies of each task. The output of the parsing task serves as the input of the spatiotemporal synchronization task, the output of the spatiotemporal synchronization task serves as the input of the encoding task, and the encoding task and the parsing context together serve as the input of the metadata generation task, thus forming a continuous dynamic workflow.

[0291] The parsing task addresses the structured splitting of multi-source driving data packets. It can select the appropriate parser plugin based on vehicle type, sensor type, and data payload characteristics to convert binary, text, or mixed data into intermediate description results. The spatiotemporal synchronization task registers data from different sources based on vehicle acquisition time, sensor time reference, and spatial calibration parameters, outputting data fragments under a unified spatiotemporal reference. The encoding task uses preset encoding rules to encode numerical, string, and feature vector data into a unified data packet format for subsequent database entry and retrieval. The metadata generation task writes vehicle model identifier, acquisition device identifier, synchronization reference, encoding version, and data quality label into metadata fields, forming a semantic index for standardized data packets. All of these tasks are executed as scheduling nodes in a dynamic workflow. Nodes can dynamically adjust their execution order and input / output mapping based on planning parameters returned by the knowledge graph.

[0292] By incorporating four types of tasks—parsing, spatiotemporal synchronization, encoding, and metadata generation—into the scheduling tasks, the system can complete parsing, alignment, standardization, and semantic supplementation based on data characteristics, and output standardized data packets that are structurally consistent, searchable, and reusable. Because explicit dependencies are established between tasks through a directed acyclic graph, the workflow maintains a stable processing order when handling driving data packets from different sources, and supports subsequent quality assessment, data storage, and policy write-back.

[0293] The scheduling tasks defined in this application include at least parsing tasks, spatiotemporal synchronization tasks, encoding tasks, and metadata generation tasks. The implementation principle involves chaining these four types of tasks together according to data flow logic: the parsing task is responsible for frame-level decomposition and field identification, outputting atomic data; the spatiotemporal synchronization task aligns multi-path heterogeneous data based on a global time base and spatial extrinsic parameters; the encoding task encapsulates the synchronized data according to standard format rules; and the metadata generation task injects semantic indexes such as scene categories and target tags in parallel. These four types of tasks cover the core transformation process from raw data streams to standard assets. Explicit dependencies between nodes ensure a stable execution order when processing data from different sources, supporting subsequent quality assessment and direct data entry, thus improving data standardization efficiency.

[0294] S705. Process the multi-source driving data packets according to the dynamic workflow to obtain parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

[0295] S706. Generate standardized data packets based on parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

[0296] Here, parsed data refers to the structured result formed after parsing the raw payload in multi-source driving data packets. This structured result is used to characterize the data content after field mapping, message splitting, and content extraction. Spatiotemporal registration data refers to the alignment result obtained after performing spatiotemporal synchronization processing on the parsed data streams. It is used to represent the consistency relationship between different acquisition sources on the time axis and spatial coordinate system. Encoded data refers to the unified output data formed after converting the processed raw data into an industry-standard format file. This unified output data can be encapsulated using preset encoding rules. Metadata carrying semantic tags refers to data generated by the metadata generation task, which carries scene category, target category, road status, or other semantic information and establishes associations with corresponding data segments.

[0297] Standardized data packets refer to data packets that have undergone a series of standardized processes, such as parsing, spatiotemporal synchronization, format conversion, and metadata generation, on the original multi-source driving data packets by the intelligent agent processor. These processes result in data packets with a unified format, a unified coordinate system, a unified time reference, and rich metadata descriptions.

[0298] In the specific implementation, the scheduling agent first traverses each node in the DAG and generates a corresponding scheduling task instance based on the node type. Each task instance includes: task type (such as parsing task, spatiotemporal synchronization task, encoding task, or metadata generation task), input parameters (cognitive description file, data location in the buffer pool, calibration parameter storage path, etc.), dependencies (a list of prerequisite tasks that the task depends on), and expected output (the data type and format that should be produced after completion).

[0299] Secondly, the planning and scheduling agent executes a topology sorting algorithm on the DAG, outputting a linear execution sequence of tasks. During the sorting process, task nodes with no dependencies (such as nodes at the same level without edge connections) are marked as parallelizable and assigned to the same parallel batch in the workflow. After sorting, a complete dynamic workflow sequence is obtained.

[0300] Understandably, the central processor sends multi-source driving data packets from different vehicle processors into a dynamic workflow represented by a directed acyclic graph. The scheduled tasks in the workflow sequentially include parsing, spatiotemporal synchronization, encoding, and metadata generation. The parsing task performs field recognition, segmentation extraction, and format normalization on the received data packets, outputting parsed data; the spatiotemporal synchronization task aligns data from different sources by combining timestamps, sensor extrinsic parameters, and sampling periods, outputting spatiotemporal registration data; the encoding task writes the processed data into a preset standard container or standard file format, outputting encoded data; and the metadata generation task generates semantic tags based on the scene recognition results, forming metadata carrying these semantic tags.

[0301] In one specific embodiment, the parsing strategy agent retrieves a matching parsing script template from the skill library or generates parsing code on the fly, decodes the raw data stream frame by frame, and outputs atomic data such as raw image frames, point cloud frames, and CAN messages. The spatiotemporal synchronization agent performs time interpolation alignment based on GPS PPS time (synchronization error controlled within 5 milliseconds) and applies calibration extrinsic parameters to convert all sensor data to the vehicle coordinate system. The format conversion agent calls audio and video processing tools to encode images into JPEG and calls the point cloud library to convert point clouds into PCD format. The metadata agent executes in parallel, generating scene-level and sequence-level metadata files, calling computer vision models to automatically identify weather, scenes, key objects, etc., and calling scene understanding models to judge complex scene semantics.

[0302] Subsequently, the system combines the above four types of results according to their corresponding indexes, association identifiers, and storage paths, based on preset data packet encapsulation rules, to generate standardized data packets. For example, it collects the outputs of each executing agent, constructs a standard directory tree according to the "dataset-scene-sequence-frame" hierarchical structure, and organizes files such as JPEG images, PCD point clouds, standard CAN messages, scene metadata, and sequence metadata into the corresponding directory levels to generate complete standardized data packets.

[0303] This standardized data packet uses parsing results, spatiotemporal alignment results, standard encoding results, and semantic metadata as its content foundation. Each data item is organized through a unified header, associated key-value pairs, and version information, enabling different representations of the same driving event to be encapsulated within the same data structure. By directly aggregating the processing results of dynamic workflows into standardized data packets, subsequent database entry, retrieval, training, and simulation calls can all be executed based on a unified format.

[0304] By adopting the above method, the content structure of the standardized data packet corresponds one-to-one with the processing link. The results of parsing, alignment, encoding and semantic annotation can maintain the relationship within the same encapsulation body, thereby enabling the data packet to have a unified format and unified semantic expression, which is convenient for subsequent cloud processing units to directly call.

[0305] In one optional implementation, the spatiotemporal synchronization task can be further performed by multimodal time anchor fusion and drift compensation. Specifically, the system prioritizes parsing the GPS PPS hard synchronization signal; if the signal is lost or its quality degrades, it automatically switches to multimodal soft synchronization mode, extracting the wheel speed encoder pulse sequence, IMU inertial integral data, and visual odometry frame feature matching interval respectively; then, the three sets of soft anchors are dynamically weighted and their states are fused using a Kalman filter framework to generate a highly robust virtual time reference; finally, nonlinear interpolation alignment is performed based on the difference between the virtual reference and the original sensor timestamps.

[0306] Furthermore, the system can perform online calibration drift self-sensing and dynamic extrinsic parameter correction steps: after the spatiotemporal alignment is completed, the cross-sensor consistency evaluation module is started to continuously compare the smoothness and spatial overlap of the target tracking trajectory after multi-source data fusion; when the index deviates from the historical normal distribution range, the online calibration compensation algorithm is triggered, the feature point matching optimizer is used to fine-tune the gradient of the current extrinsic parameter matrix, and the corrected calibration parameters are output and cached in the knowledge graph.

[0307] In another optional implementation, the metadata generation task can be further performed by keyframe extraction and hierarchical semantic abstraction. Specifically, the system first evaluates the activity of video frames based on motion optical flow and scene variability indicators, and selects representative keyframes containing significant scene transitions or target mutations; the keyframes are then input into a scene understanding model for high-precision, fine-grained semantic parsing; subsequently, using a lightweight temporal propagation model, based on the semantic labels of the keyframes and the continuity of inter-frame states, the semantic information is smoothly interpolated to all intermediate frames through a temporal attention mechanism to complete full-sequence label filling.

[0308] Furthermore, the system can perform cross-modal semantic conflict resolution and physical consistency constraint generation steps: when the point cloud detects a static obstacle but the image fails to recognize it due to lighting or occlusion, or when there is a semantic contradiction between the two labeled categories, the cross-modal consistency verification network is invoked to perform evidence fusion; at the same time, a physical constraint generator is introduced to filter the rationality of the fusion result by combining the vehicle dynamics model and the light reflection law, eliminating label noise that violates physical common sense, and finally outputting structured semantic metadata with spatiotemporal consistency and physical credibility.

[0309] This application processes multi-source driving data packets according to a dynamic workflow to obtain four types of data and generate standardized data packets. Its implementation principle lies in sequentially executing parsing, synchronization, encoding, and metadata generation tasks. The parsing results, spatiotemporal alignment results, standard encoding results, and semantic metadata are aggregated and encapsulated using a unified header, associated key-value pairs, and version information. This binds the multi-dimensional representation of the same driving event to the same data structure. The content of the standardized data packet corresponds one-to-one with the processing chain. The parsing, alignment, encoding, and semantic annotation results remain related within the same encapsulation body, giving the data packets a unified format and unified semantic expression, facilitating direct retrieval, training, or simulation by subsequent cloud processing units.

[0310] Figure 8 Flowchart of the data processing method provided in the embodiments of this application Figure 7 .like Figure 8 As shown, before the S201 receives multiple driving data packets sent by the central processor, it also includes:

[0311] S801: Receive raw data packets transmitted back from different vehicles.

[0312] S802. Process the original data packet and verify its integrity.

[0313] S803. If the verification passes, the original data packet is stored in the data buffer pool to generate a multi-source driving data packet.

[0314] The raw data packets consist of basic data objects to be processed, transmitted from different vehicles. Their content may include vehicle operating status, sensor sampling segments, timestamp information, and communication identifiers. This data is temporarily stored and preprocessed at the central side before entering the subsequent unified analysis link. A data buffer pool is used to temporarily store raw data packets that have passed verification. It can be configured as a memory buffer, a queued buffer, or a partitioned cache table, accepting data based on the access rate and subsequent processing rate. Integrity is used to characterize whether the raw data packets meet the conditions for subsequent processing. This is specifically achieved by verifying the packet header identifier, length field, checksum, fragment sequence number, and whether key fields are missing. Multi-source driving data packets are a unified input object formed from the processed and integrity-verified raw data packets, used for subsequent parsing, querying, and workflow organization.

[0315] In practice, the original data packets returned by different vehicles are accessed by the central processor. The packet header, payload and check field are first split according to the preset format, and the timestamp, vehicle identifier and transmission sequence are standardized. Then, integrity judgment is performed based on length consistency, checksum consistency and field closure.

[0316] Understandably, if the original data packet contains fragmented transmissions, the reassembly can be confirmed based on the fragment number and reassembly identifier; if the original data packet contains compressed or encrypted content, it can be decompressed or decrypted first before proceeding to integrity verification. After successful verification, the original data packet is written to the corresponding storage unit in the data buffer pool, retaining the source vehicle identifier, reception time, and cache index, in order to form a multi-source driving data packet that can be uniformly scheduled.

[0317] This processing method introduces raw data packet access and buffer verification before the central processor sends multiple driving data packets. This ensures that confirmed and complete data enters a unified buffer, thus providing subsequent analysis objects with consistent input boundaries and traceable source information. Because multi-source driving data packets are aggregated in a buffer pool before entering the subsequent processing link, asynchronous backhaul data from different vehicles can be organized into a continuously usable data set.

[0318] By adopting this approach, the system can first complete the access screening in the case of concurrent transmission from multiple vehicles, transmission jitter, or partial packet loss, and then aggregate the data that meets the conditions into a unified multi-source driving data packet. This provides a stable input for subsequent interface identification, data description generation, and dynamic workflow scheduling, and reduces the probability of subsequent processing failures caused by incomplete original data.

[0319] This application receives the original data packets transmitted from vehicles before the receiving center processor sends data, verifies their integrity, and stores them in a buffer pool. Its implementation principle involves parsing the packet header, stripping the payload, and performing checksum comparison on the original packets. It verifies the timestamp, fragment sequence number, and field closure. Data that passes verification is written into a queued buffer based on its source identifier and reception time, forming a multi-source input set. This pre-buffering mechanism enables the system to complete access screening before receiving concurrent data from multiple vehicles or during transmission jitter, aggregating data that meets the criteria into a complete multi-source driving data packet. This provides stable input for subsequent interface identification, description generation, and dynamic workflow scheduling, reducing the probability of subsequent processing failures due to incomplete original data.

[0320] It should be noted that the technical solution of the present invention has been described in detail above through specific embodiments. Those skilled in the art should understand that the above embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention.

[0321] This application embodiment can divide the data processing device or main control device into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0322] Figure 9 This is a schematic diagram of the structure of the data processing apparatus provided in an embodiment of this application. Figure 9 As shown, the data processing device 900 is applied to the intelligent agent processor in the data processing system, which includes multiple vehicle processors and a central processor.

[0323] The central processor is connected to the agent processor and multiple vehicle processors to obtain driving data packets from the multiple vehicle processors and send them to the agent processor.

[0324] The data processing device 900 includes:

[0325] The receiving module 901 is used to receive multiple driving data packets sent by the central processor and determine the analysis mode based on the acquisition of the interface document of the driving data packets;

[0326] Analysis module 902 is used to analyze multi-source driving data packets according to the analysis mode in order to query planning parameters from the knowledge graph based on the generated data description file;

[0327] The generation module 903 is used to generate a directed acyclic graph (DAG) to represent the data processing order based on the planning parameters, and to process the multi-source driving data packets according to the dynamic workflow represented by the DAG to generate standardized data packets.

[0328] In one possible embodiment, after generating the standardized data packet, the data processing device 900 is further configured to:

[0329] Standardized data packets undergo quality assessment, and if the quality assessment is passed, the standardized data packets are stored in a standardized data lake to transform them into reusable data assets.

[0330] In one possible embodiment, the data processing device 900 is further configured to:

[0331] If the quality assessment fails, identify the data segments that failed in the standardized data package and repair them.

[0332] If the failed data segment cannot be repaired, an alarm report will be generated.

[0333] In one possible embodiment, the data processing device 900 is further configured to:

[0334] If a data segment is detected missing in the acquisition device that acquires the multi-source driving data packet corresponding to the standardized data packet, the missing data segment is estimated and the data segment is completed by using the data acquired by other acquisition devices at the same time and the calibration parameters corresponding to the current acquisition device.

[0335] In one possible embodiment, the data processing device 900 is further configured to:

[0336] Confidence analysis is performed on the repair data segments generated during the repair process to obtain the repair confidence level;

[0337] If the repair confidence level is higher than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair is confirmed to be successful.

[0338] In one possible embodiment, the data processing device 900 is further configured to:

[0339] If the repair confidence level is lower than the preset threshold, the repair data segment is used to repair the failed data segment, and the repair data segment is marked with questionable annotations, which are then fed back into the knowledge graph.

[0340] In one possible embodiment, the data processing device 900 is further configured to:

[0341] The results of the quality assessment are fed back to the knowledge graph to update the parameters in the knowledge graph, and the data processing strategy of multi-source driving data packets is abstracted into reusable skills and stored in the preset skill library.

[0342] In one possible embodiment, the receiving module 901 is further configured to:

[0343] If the interface documentation is obtained, the analysis mode is determined to be the document parsing mode;

[0344] Without obtaining the interface documentation, the analysis mode is determined to be binary mode recognition mode.

[0345] In one possible embodiment, the analysis module 902 is further configured to:

[0346] Using a large language model, multi-source driving data packets are analyzed and extracted according to preset data extraction requirements to obtain data description files.

[0347] In one possible embodiment, the analysis module 902 is further configured to:

[0348] Binary stream analysis is performed on multi-source driving data packets to match the file header identifiers and delimiter sequences of the multi-source driving data packets, and to infer the encapsulation layer and payload division in order to generate a data description file.

[0349] In one possible embodiment, the generation module 903 is further configured to:

[0350] Based on the data description file, index information is generated to retrieve planning parameters from the knowledge graph; the knowledge graph contains the correspondence between various vehicle configuration information and various parsing strategies.

[0351] In one possible embodiment, the generation module 903 is further configured to:

[0352] Extract vehicle identification and sensor information from the data description file as index information.

[0353] In one possible embodiment, the generation module 903 is further configured to:

[0354] Based on the index information, the vehicle configuration information and parsing history in the knowledge graph are queried to obtain planning parameters. The planning parameters include at least: historical processing data, recommendation parser plugin, and calibration parameter storage location.

[0355] In one possible embodiment, the generation module 903 is further configured to:

[0356] Extract data features from the data description file;

[0357] Based on data characteristics and planning parameters, a directed acyclic graph is generated to characterize the data processing order.

[0358] In one possible embodiment, the generation module 903 is further configured to:

[0359] Instantiate each node in the directed acyclic graph as a scheduled task;

[0360] Based on the connection order of each node in the directed acyclic graph, multiple scheduling tasks are sequentially sorted to obtain a dynamic workflow.

[0361] In one possible embodiment, the scheduling task includes at least: a parsing task, a spatiotemporal synchronization task, an encoding task, and a metadata generation task.

[0362] In one possible embodiment, the generation module 903 is further configured to:

[0363] According to the dynamic workflow, the multi-source driving data packets are processed to obtain parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags;

[0364] Standardized data packets are generated based on parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

[0365] In one possible embodiment, the data processing device 900 is further configured to:

[0366] Receive raw data packets transmitted back from different vehicles;

[0367] Process the original data packets and verify their integrity;

[0368] If the verification passes, the original data packet is stored in the data buffer pool to generate a multi-source driving data packet.

[0369] The data processing apparatus provided in this embodiment can execute the data processing method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0370] In the specific implementation of the aforementioned data processing device, each module can be implemented as a processor, which can execute computer execution instructions stored in the memory, thereby enabling the processor to perform the aforementioned data processing method.

[0371] Figure 10 A schematic diagram of the structure of the electronic device provided in this application. Figure 10As shown, the electronic device 1000 provided in this embodiment includes at least one processor 1001 and a memory 1002. Optionally, the electronic device 1000 further includes a communication component 1003. The processor 1001, the memory 1002, and the communication component 1003 are connected via a bus 1004.

[0372] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to perform the above-described method.

[0373] The specific implementation process of processor 1001 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0374] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0375] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0376] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0377] The above description of the functions implemented by the data processing device and the main control device illustrates the solutions provided by the embodiments of the present invention. It is understood that, in order to achieve the above functions, the data processing device or the main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0378] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described data processing method.

[0379] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0380] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in a data processing device or a host device.

[0381] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0383] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0385] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0386] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application 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 or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method, characterized in that, An intelligent agent processor applied to a data processing system, the data processing system including multiple vehicle processors and a central processor; The central processor is communicatively connected to the intelligent agent processor and multiple vehicle processors, and is used to obtain driving data packets from the multiple vehicle processors and send them to the intelligent agent processor. The method includes: Receive multiple driving data packets sent by the central processor, and determine the analysis mode based on the acquisition status of the interface documentation of the driving data packets; The multi-source driving data packets are analyzed according to the analysis mode to retrieve planning parameters from the knowledge graph based on the generated data description file; Based on the planning parameters, a directed acyclic graph is generated to characterize the data processing order, and the multi-source driving data packets are processed according to the dynamic workflow represented by the directed acyclic graph to generate standardized data packets.

2. The method according to claim 1, characterized in that, After generating the standardized data packet, the method further includes: The standardized data packets are subjected to quality assessment, and if the quality assessment is passed, the standardized data packets are stored in a standardized data lake to transform the standardized data packets into reusable data assets.

3. The method according to claim 2, characterized in that, The method further includes: If the quality assessment fails, identify the data segments that fail in the standardized data packet and repair them. If the failed data segment cannot be repaired, an alarm report is generated.

4. The method according to claim 3, characterized in that, The repair process for the failed data segments includes: If a data segment is detected missing in the acquisition device that acquires the multi-source driving data packet corresponding to the standardized data packet, the missing data segment is estimated and the data segment is completed by using the data acquired by other acquisition devices at the same time and the calibration parameters corresponding to the current acquisition device.

5. The method according to claim 3, characterized in that, The repair process for the failed data segments includes: Confidence analysis is performed on the repair data segments generated during the repair process to obtain the repair confidence level; If the repair confidence level is higher than a preset threshold, the repair data segment is used to repair the failed data segment, and the repair is determined to be successful.

6. The method according to claim 5, characterized in that, The method further includes: If the repair confidence level is lower than a preset threshold, the failed data segment is repaired using a repair data segment, and the repair data segment is marked with a question mark and fed back to the knowledge graph.

7. The method according to claim 2, characterized in that, After performing quality assessment on the standardized data packets, the method further includes: The results of the quality assessment process are fed back to the knowledge graph to update the parameters in the knowledge graph, and the data processing strategy of the multi-source driving data package is abstracted into reusable skills and stored in a preset skill library.

8. The method according to claim 1, characterized in that, The determination of the analysis mode based on the acquisition of interface documents from the multi-source driving data packets includes: If the interface documentation is obtained, the analysis mode is determined to be the document parsing mode; Without obtaining the interface documentation, the analysis mode is determined to be binary mode recognition mode.

9. The method according to claim 8, characterized in that, If the interface documentation is obtained, the step of analyzing the multi-source driving data packet according to the analysis mode includes: Using a large language model, the multi-source driving data packets are analyzed and extracted according to preset data extraction requirements to obtain the data description file.

10. The method according to claim 8, characterized in that, In the absence of interface documentation, the analysis of the multi-source driving data packet according to the analysis mode includes: Binary stream analysis is performed on multi-source driving data packets to match the file header identifiers and delimiter sequences of the multi-source driving data packets, and to infer the encapsulation layer and payload division in order to generate a data description file.

11. The method according to claim 1, characterized in that, The planning parameters are retrieved from the knowledge graph based on the generated data description file, including: Based on the data description file, index information is generated to query the planning parameters in the knowledge graph; the knowledge graph contains the correspondence between various vehicle configuration information and various parsing strategies.

12. The method according to claim 11, characterized in that, The step of generating index information based on the data description file includes: Extract the vehicle model identifier and sensor information from the data description file as index information.

13. The method according to claim 11, characterized in that, The planning parameters are retrieved from the knowledge graph based on the generated data description file, including: Based on the index information, the vehicle configuration information and parsing history in the knowledge graph are queried to obtain planning parameters. The planning parameters include at least: historical processing data, recommendation parser plugin, and calibration parameter storage location.

14. The method according to claim 1, characterized in that, The step of generating a directed acyclic graph to characterize the data processing order based on the planning parameters includes: Extract data features from the data description file; Based on the data characteristics and the planning parameters, a directed acyclic graph is generated to characterize the data processing order.

15. The method according to claim 1, characterized in that, The step of determining the dynamic workflow includes: Instantiate each node in the directed acyclic graph as a scheduling task; Based on the connection order of each node in the directed acyclic graph, the multiple scheduling tasks are sequentially sorted to obtain the dynamic workflow.

16. The method according to claim 15, characterized in that, The scheduling tasks include at least: parsing tasks, spatiotemporal synchronization tasks, encoding tasks, and metadata generation tasks.

17. The method according to claim 16, characterized in that, The generation of standardized data packets includes: According to the dynamic workflow, the multi-source driving data packets are processed to obtain parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags; Standardized data packets are generated based on parsed data, spatiotemporal registration data, encoded data, and metadata carrying semantic tags.

18. The method according to claim 1, characterized in that, Before receiving the multiple driving data packets sent by the central processor, the method further includes: Receive raw data packets transmitted back from different vehicles; Process the original data packets and verify their integrity; If the verification passes, the original data packet is stored in the data buffer pool to generate a multi-source driving data packet.

19. A data processing apparatus, characterized in that, An intelligent agent processor applied to a data processing system, the data processing system including multiple vehicle processors and a central processor; The central processor is communicatively connected to the intelligent agent processor and multiple vehicle processors, and is used to obtain driving data packets from the multiple vehicle processors and send them to the intelligent agent processor. The device includes: The receiving module is used to receive multiple driving data packets sent by the central processor, and determine the analysis mode based on the acquisition status of the interface documentation of the driving data packets; The analysis module is used to analyze multi-source driving data packets according to the analysis mode, so as to query planning parameters from the knowledge graph based on the generated data description file; The generation module is used to generate a directed acyclic graph (DAG) representing the data processing order based on the planning parameters, and to process the multi-source driving data packets according to the dynamic workflow represented by the DAG to generate standardized data packets.

20. A data processing system, characterized in that, The data processing system includes multiple vehicle processors and a central processor; The central processor is communicatively connected to the intelligent agent processor and multiple vehicle processors, and is used to obtain driving data packets from the multiple vehicle processors and send them to the intelligent agent processor. The agent processor in the data processing system is used to perform data processing using the method described in any one of claims 1-18.

Images