Data collection method, vehicle and data collection platform

Abstract

The application discloses a data collection method, a vehicle and a data collection platform. The data collection method comprises the following steps: obtaining a delivery requirement; decomposing the delivery requirement into one or more collection tasks, and issuing the collection tasks to corresponding target vehicles; wherein the identification of the delivery requirement, the identification of the collection tasks and the target vehicles are associated based on a metadata structure; during the execution of the collection tasks by the target vehicles, receiving vehicle-end state information sent by the target vehicles at intervals of a preset time; the vehicle-end state information comprises vehicle information, collector information and data collection state information; based on the vehicle-end state information, displaying and updating a data collection view of the target vehicle on a visual interactive interface; the collection view is used for representing the completion state of the delivery requirement. In this way, the real-time collection progress, coverage and completion degree can be counted according to the delivery requirement dimension, and the problem that the collection tasks are not connected with the delivery requirement is solved.

Description

Technical Field

[0001] This application relates to the field of automotive technology, specifically to a data acquisition method, a vehicle, and a data acquisition platform. Background Technology

[0002] With the rapid development of intelligent connected vehicles and autonomous driving technologies, large-scale, high-quality data collection from road and parking scenarios has become a crucial step in algorithm training and functional iteration. However, the isolated management of data collection activities and business needs leads to a severe break in the data process tracking chain, making it difficult to meet data quality management requirements. Moreover, during the data collection process, collection managers cannot monitor the task status and intermediate data processing status in real time, making project management, resource scheduling, and risk response highly reactive. Summary of the Invention

[0003] One objective of this application is to provide a data acquisition method to solve the problems in the prior art that lead to serious breaks in the data process tracking chain, making it difficult to meet the requirements of data quality management, and making it impossible for acquisition managers to grasp the task status and intermediate status of data processing in real time; a second objective is to provide a vehicle; and a third objective is to provide a data acquisition platform.

[0004] To achieve the above objectives, this application provides a data processing method. The technical solution adopted in this application is as follows: obtaining delivery requirements; breaking down the delivery requirements into one or more collection tasks and issuing them to the corresponding target vehicles; wherein, the identifier of the delivery requirements, the identifier of the collection tasks, and the target vehicles are associated based on a metadata structure; during the execution of the collection tasks by the target vehicles, receiving vehicle-side status information sent by the target vehicles at preset intervals; the vehicle-side status information includes vehicle information, collection personnel information, and data collection status information; based on the vehicle-side status information, displaying and updating the data collection view of the target vehicles on a visual interactive interface; the collection view is used to represent the completion status of the delivery requirements.

[0005] Based on the aforementioned technical methods, firstly, delivery requirements are broken down into one or more data collection tasks, which are then distributed to target vehicles. A metadata structure is used to establish the relationships between delivery requirement identifiers, collection task identifiers, and target vehicles. This allows each collection task to be clearly traced back to specific upstream business requirements, enhancing process traceability and providing a basis for troubleshooting in case of subsequent data quality issues. Secondly, during the execution of one or more collection tasks by the target vehicle, vehicle-side status information is received. Based on this information, a data collection view for the target vehicle is dynamically generated and updated on a visual interactive interface, intuitively presenting the completion progress of each delivery requirement. This allows data management personnel to statistically analyze real-time collection progress, coverage, and completion rates according to delivery requirements, resolving the disconnect between collection tasks and delivery requirements, understanding the overall status of data collection, and promptly identifying collection delays or anomalies, facilitating rapid resource scheduling or task adjustment decisions.

[0006] Furthermore, after breaking down the delivery requirements into one or more collection tasks and issuing them to the corresponding target vehicles, the method also includes: determining the corresponding task template based on the collection tasks; issuing the task template to the target vehicles; the task template is used to indicate the information of the data to be collected, as well as the scene label information entered by the collection personnel during the data collection process.

[0007] Based on the aforementioned technical methods, a corresponding task template is determined according to the data collection task. This template is then sent to the target vehicle, instructing it on the data collection process and directing the data collectors to input scene label information. By issuing the same task template to the same data collection task, data collected by different personnel, from different target vehicles, and at different times maintains consistency in structure, format, and parameter requirements, avoiding data heterogeneity and improving the efficiency of multi-source data fusion. Furthermore, data collectors only need to input scene label information according to the template prompts, reducing the probability of errors and improving the quality of data collection.

[0008] Furthermore, the method also includes: receiving the collection data sent by the target vehicle; adding an identifier to the collection data; wherein, the identifier of the collection data is associated with the identifier of the delivery requirement, the identifier of the collection task, the identifier of the vehicle, and the identifier of the collection personnel based on the metadata structure.

[0009] Based on the aforementioned technical means, the collected data sent by the target vehicle is further identified by adding data identifiers. These identifiers are linked to the delivery requirement identifier, the collection task identifier, the vehicle identifier, and the collection personnel identifier based on a metadata structure. In this way, through the metadata structure, a structured, multi-dimensional association is established between the data and its source (delivery requirement), execution unit (collection task), carrier (target vehicle), and operator (collection personnel). Based on this metadata structure, any collected data can be traced back to the specific delivery requirement, as well as the target vehicle and collection personnel involved in the collection process. When anomalies occur in the collected data, the source of the problem can be quickly located, shortening the investigation time for data instruction issues and significantly improving the efficiency of data governance. Furthermore, it supports multi-dimensional data retrieval and filtering, increasing the amount and dimensions of information that can be displayed on the visual interactive interface.

[0010] Furthermore, the method also includes: transmitting the collected data to the data processing platform; receiving the processing status information returned by the data processing platform; the processing status information includes processing progress, usage, effectiveness, and retention rate; and establishing a correlation between the processing status information and the identifiers of the delivery requirements and the collection tasks based on the metadata structure.

[0011] Based on the aforementioned technical methods, the collected data is transmitted to the data processing platform. The platform then returns processing status information, and based on the metadata structure, a correlation is established between the processing status information and the identifiers of the delivery requirements and the collection tasks. In this way, based on the processing status information, low-quality data can be identified promptly, and based on the metadata structure, the data source can be identified, allowing for timely location of data problems and forming an optimized closed loop, avoiding ineffective collection and storage.

[0012] Furthermore, in the event of an abnormal status information indication, the method also includes: determining the corresponding data collection task, target vehicle, and corresponding data collection personnel based on the collected data; re-issuing the corresponding data collection task to the target vehicle, instructing the data collection personnel to re-collect the data, and obtaining the updated data collection data; and receiving and storing the updated data collection data.

[0013] Based on the aforementioned technical methods and the collected data, the corresponding data collection tasks, target vehicles, and personnel are identified. The data collection tasks are then reissued to the target vehicles, instructing the personnel to recollect the data, resulting in updated data. This updated data is then received and stored. In this way, the recollection targets can be accurately located. Through metadata association, the corresponding tasks, vehicles, and personnel can be found from the non-compliant data without manual querying, significantly improving the efficiency of supplementary data collection. Furthermore, by repeatedly recollecting until the data is compliant, task template optimization and standardized operation by data collection personnel are driven, leading to a long-term improvement in the overall data compliance rate.

[0014] Furthermore, after receiving the processing status information returned by the data processing platform, the method also includes: updating the configuration parameters of the collection task based on the processing status information; the configuration parameters include the collection area, the number of collections, and the type of collected data; and updating one or more unissued collection tasks based on the updated configuration parameters of the collection task.

[0015] Based on the aforementioned technical methods, the configuration parameters of the data collection tasks are updated according to the processing status information. Furthermore, based on the updated configuration parameters of the data collection tasks, one or more unreleased data collection tasks are updated. In this way, the data collection platform can automatically adjust the configuration parameters of unreleased data collection tasks based on the processing status information from actual execution feedback, forming a closed loop of collection-feedback-optimization. This avoids repetitive and inefficient data collection, facilitates auditing and subsequent optimization strategy design, and improves the effectiveness of data collection.

[0016] Furthermore, after displaying and updating the data acquisition view of the target vehicle on the visual interactive interface based on the vehicle status information, the method also includes: receiving resource scheduling instructions input by the dispatcher; the resource scheduling instructions are input by the dispatcher based on the data acquisition view; and adjusting the metadata structure and / or one or more acquisition tasks based on the resource scheduling instructions.

[0017] Based on the aforementioned technical means, the data acquisition platform receives resource scheduling instructions input by dispatchers and adjusts the metadata structure and / or one or more acquisition tasks accordingly. In this way, dispatchers can proactively intervene in task scheduling decisions based on information displayed on a visual interactive interface, enabling rapid response to emergencies and improving the platform's flexibility.

[0018] Furthermore, the data acquisition view includes at least one of the following: a delivery requirement progress dashboard, which displays the completion progress of each delivery requirement; a data acquisition task monitoring dashboard, which displays the real-time task status of each target vehicle; and an asset database dashboard, which displays the distribution of collected parking lots and intersections.

[0019] Based on the aforementioned technical means, the data acquisition view includes one or more of the following: a delivery requirement progress dashboard, a collection task monitoring dashboard, and an asset database dashboard. In this way, schedulers can view the collection progress of each delivery requirement in real time based on the data acquisition view, supporting data-driven task planning and maximizing the efficiency and output of collected data.

[0020] A vehicle includes a vehicle-mounted data acquisition unit; wherein: the vehicle-mounted data acquisition unit is configured to receive one or more acquisition tasks, wherein the one or more acquisition tasks are obtained by a data acquisition platform by decomposing delivery requirements; wherein the identifier of the delivery requirement, the identifier of the acquisition task, and the vehicle are associated based on a metadata structure; the vehicle-mounted data acquisition unit is further configured to send vehicle-mounted status information to the data acquisition platform at preset intervals during the acquisition task process; the vehicle-mounted status information includes vehicle information, acquisition personnel information, and data acquisition status information; the vehicle-mounted status information is used to instruct the data acquisition platform to display and update the vehicle's data acquisition view on a visual interactive interface; the acquisition view is used to represent the completion status of the delivery requirements.

[0021] A data acquisition platform includes a control unit and a visual interactive interface. The control unit is configured to: acquire delivery requirements; break down the delivery requirements into one or more acquisition tasks and distribute them to corresponding target vehicles; wherein the identifiers of the delivery requirements, the identifiers of the acquisition tasks, and the target vehicles are associated based on a metadata structure; during the execution of acquisition tasks by the target vehicles, the control unit receives vehicle-side status information sent by the target vehicles at preset intervals; the vehicle-side status information includes vehicle information, acquisition personnel information, and data acquisition status information; based on the vehicle-side status information, the control unit displays and updates the data acquisition view of the target vehicles on the visual interactive interface; the acquisition view is used to represent the completion status of the delivery requirements.

[0022] The beneficial effects of this application are: (1) Decompose the delivery requirements into one or more collection tasks, distribute them to the target vehicles, and build the relationship between the identifiers of the delivery requirements, the identifiers of the collection tasks, and the target vehicles based on the metadata structure. In this way, each collection task can be clearly traced back to the specific business requirements upstream, enhancing process traceability and providing a basis for reviewing and locating problems when data quality issues occur later.

[0023] (2) During the execution of one or more data collection tasks by the target vehicle, the system receives vehicle status information sent by the target vehicle. Based on the vehicle status information, the system dynamically generates and updates the data collection view of the target vehicle on the visual interactive interface, intuitively presenting the completion progress of each delivery requirement. In this way, data management personnel can statistically analyze the real-time collection progress, coverage, and completion rate according to the delivery requirement dimension, solve the problem of the disconnect between collection tasks and delivery requirements, understand the overall status of data collection, and promptly detect collection delays or anomalies, facilitating rapid resource scheduling or task adjustment decisions. Attached Figure Description

[0024] Figure 1 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 1 ; Figure 2 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 2 ; Figure 3 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 3 ; Figure 4 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 4 ; Figure 5 A schematic diagram of the composition structure of a data acquisition platform provided in this application embodiment. Figure 1 ; Figure 6 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 5 ; Figure 7 A flowchart illustrating a data acquisition method provided in this application embodiment. Figure 6 ; Figure 8 A schematic diagram of the composition structure of a data acquisition platform provided in this application embodiment. Figure 2 . Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to be limiting of this application.

[0028] In the current data processing systems for intelligent driving, multimodal algorithms, and artificial intelligence, the data acquisition system, as the first link in the data production chain, directly impacts the efficiency of subsequent annotation, training, and model iteration. However, existing systems have significant shortcomings in data acquisition task management and data flow mechanisms: 1. Data collection tasks are disconnected from business requirements: The system only manages isolated data collection tasks and cannot be associated with upstream algorithms or labeled "delivery requirements". As a result, the collected data cannot be effectively traced back to its business source, and the completion progress of specific requirements cannot be statistically analyzed globally.

[0029] 2. Disconnection between data lineage and process traceability: After data collection, there is a lack of binding relationship between the uploaded data and the specific collection task, collection work order, and original requirements. When quality or quantity issues arise in subsequent processing, annotation, and acceptance stages, it is difficult to trace back to the specific collection vehicle, collector, or collection batch, making it difficult to locate the problem and review the process.

[0030] 3. Insufficient support for diverse tasks and complex processes: Autonomous driving data collection includes various modes such as routine driving data collection, multiple intersection trips, large parking maps, and Automated Valet Parking (AVP). Existing systems mostly adopt a general or single task distribution mode, which cannot adapt to the special processes of different task types (such as AVP parking, which requires two steps: "map creation" and "location," and also needs to be linked to parking lot asset information). This leads to the prevalence of offline manual management forms, which are inefficient and prone to errors.

[0031] 4. Lack of transparency in task progress and data status: For data collection and management personnel, it is impossible to monitor the task status (such as issued, received, in progress, uploaded, processing, completed, etc.) and the intermediate status of data processing (such as traditional counting, de-identification and declassification progress, conversion progress, and downstream usage rate) in real time. The "black box" status after data collection makes project management, resource scheduling, and risk response very passive.

[0032] 5. In the existing technology, the vehicle-side tag collection system is independent of the cloud-based tag processing and labeling system, and there is no automatic synchronization mechanism. This results in the need for manual re-labeling of collected data, low data reuse efficiency, and inconsistent labels that prevent accurate retrieval.

[0033] 6. Existing technologies only realize a one-way process of data collection-upload-storage, and the quality feedback in the testing / annotation stage cannot be used to optimize the configuration of the collection task.

[0034] Based on this, the embodiments of this application provide a data acquisition method, vehicle, and data acquisition platform, which improves the management of isolated task execution to an automated cloud management system that takes "delivery requirements" as the source, runs through the entire life cycle of "collection-processing-labeling-delivery", has a configurable multi-task mode, and has traceable data lineage. It aims to solve the technical problems of low management efficiency, poor traceability, insufficient flexibility, and lack of process transparency in the prior art.

[0035] In one embodiment of this application, a data acquisition method is provided. This method can be applied to a data acquisition platform, which can be deployed on a cloud server cluster or in a vehicle, such as... Figure 1 As shown, the method may include the following steps S101 to S104.

[0036] S101, Obtain delivery requirements.

[0037] In this embodiment, the data acquisition platform includes a task management layer for receiving and managing upstream delivery requests.

[0038] In this context, delivery requirements refer to high-level, business-oriented data or service requests for vehicle data obtained from users. These requests may include a textual description of the results or data the user wants (e.g., data type), the purpose of the data, and constraints such as the time, region, and scenario of the data. For example, a delivery requirement could be: "Collect road surface smoothness data for a certain highway entrance / exit under rainy conditions."

[0039] S102 breaks down the delivery requirements into one or more data collection tasks and distributes them to the corresponding target vehicles.

[0040] Among them, the identifiers of delivery requirements, the identifiers of collection tasks, and the target vehicles are associated with each other based on the metadata structure.

[0041] In this embodiment of the application, after receiving the delivery request from the upstream, the delivery request can be split into one or more collection work orders. Each collection work order can be further broken down into collection tasks oriented towards a single vehicle and a daily dimension, according to region, vehicle type, data type, etc. In this process, a three-level task tree structure of "delivery request - collection work order - collection task" is established.

[0042] Among them, the data collection work order can be created by the data collection management personnel, or it can be generated based on a preset splitting algorithm.

[0043] In this embodiment, after receiving a "delivery request" from the algorithm or annotation team, the request includes key information such as the vehicle type, scenario, volume, format, and cycle of the required data. A logical container is created for each delivery request, and a "collection work order" is created under this request. A collection work order typically corresponds to a collection plan for a specific scenario within a time period. For example, for the delivery request: "Data on rainy intersections in City A, 1000 minutes," a "July City A Rainy Intersection Collection Work Order" is created. Subsequently, the administrator breaks down this work order into specific, executable "collection tasks," such as "July 10th, vehicle VIN001, collect data from the City A rainy intersection, target volume 200 minutes." Each collection task is explicitly associated with a vehicle and a specific execution date.

[0044] Among them, the data acquisition task is an executable, dispatchable, and schedulable data acquisition task unit with clearly defined data acquisition time, scope, type, and other data requirements.

[0045] It should be noted that the metadata structure is a pre-defined metadata specification, including the identifier (ID) of the collection task, the ID of the collection work order, the ID of the delivery requirement, the batch number, vehicle information, tag code, etc. In the subsequent data flow process, the data is transferred based on the metadata structure. The identifier of each newly added data is added to the metadata structure and associated with the existing identifiers.

[0046] In this way, by establishing a three-level mapping of "delivery requirements - collection work orders - collection tasks", the final business use of any collected data can be traced back to the original requirements, thus solving the problem of the disconnect between business requirements and data collection.

[0047] In this embodiment of the application, after determining the data collection task, one or more data collection tasks are sent to the corresponding target vehicle. The target vehicle may include one or more vehicles.

[0048] S103: During the data collection process of the target vehicle, receive vehicle status information sent by the target vehicle at preset intervals.

[0049] The vehicle-side status information includes vehicle information, data collection personnel information, and data collection status information.

[0050] In this embodiment, the data acquisition platform may further include a task distribution and execution layer, used to distribute one or more acquisition tasks to the vehicle's in-vehicle terminal and then receive the vehicle's terminal status information returned by the target vehicle. This information may include task execution status, retrieval information (vehicle information such as VIN, acquisition personnel information such as acquisition personnel number), tagging, data acquisition status, and data upload batch information. This enables automatic task distribution and second-level transmission of vehicle status back to the cloud via the vehicle network.

[0051] In some embodiments, the above information can be bound to the ID of the collection task, the ID of the collection work order, the ID of the delivery requirement, etc., based on the metadata structure, using the "data processing link linkage module" and the "data lineage module".

[0052] In this embodiment, the "data processing link linkage module" and the "data lineage module" bind the data collection task, vehicle, and personnel information at the initial data upload stage, and these information accompanies the data flow to all subsequent stages. When data quality issues are discovered during processing or annotation, the specific collection batch, vehicle, collector, and even the scene description during collection can be immediately traced, greatly improving problem localization and closed-loop efficiency. This solves the data "black box" problem and the pain points of poor traceability, achieving end-to-end data traceability.

[0053] S104, based on vehicle status information, displays and updates the data acquisition view of the target vehicle on a visual interactive interface; the acquisition view is used to characterize the completion status of delivery requirements.

[0054] In this embodiment of the application, the visualization dashboard is used to dynamically display the real-time progress of the collected work orders / tasks, vehicle status, data processing status at each stage, asset library coverage, and global completion status based on the data provided by the above modules, such as in the dimension of delivery requirements, for example, in the form of progress statistics.

[0055] Based on the above, each module achieves data interoperability through a unified metadata specification (including task ID, work order ID, batch number, vehicle information, and tag code). The three-level task tree information generated by the task management layer is synchronized to the data lineage module. Based on the data lineage constructed based on the metadata structure, the vehicle status information of the task distribution and execution layer is pushed to the visualization dashboard in real time. Users can view the delivery requirements, collection work orders, collection tasks, target vehicles, collection personnel, and other information corresponding to the status information of each vehicle through the visualization panel based on the metadata structure.

[0056] In this embodiment, a visual dashboard displays the data collection view, enabling real-time statistics on the overall completion progress of each delivery request, thus achieving demand-driven, refined operations. This directly solves the problem of unclear "why collect data and for whom" in existing technologies.

[0057] This application provides a data acquisition method. First, delivery requirements are broken down into one or more acquisition tasks, which are then distributed to target vehicles. A metadata structure is used to construct the relationships between the identifiers of delivery requirements, the identifiers of acquisition tasks, and the target vehicles. This allows each acquisition task to be clearly traced back to specific upstream business requirements, enhancing process traceability and providing a basis for troubleshooting when data quality issues arise. Second, during the execution of one or more acquisition tasks by the target vehicles, vehicle-side status information is received. Based on this information, a data acquisition view for the target vehicles is dynamically generated and updated on a visual interactive interface, intuitively presenting the completion progress of each delivery requirement. This allows data management personnel to statistically analyze real-time acquisition progress, coverage, and completion according to delivery requirements, resolving the disconnect between acquisition tasks and delivery requirements, understanding the overall status of data acquisition, and promptly identifying acquisition delays or anomalies, facilitating rapid resource scheduling or task adjustment decisions.

[0058] In some embodiments, after step S102, which involves breaking down the delivery requirement into one or more collection tasks and sending them to the corresponding target vehicles, the method may further include steps S201 to S202.

[0059] S201, Based on the data collection task, determine the corresponding task template.

[0060] In this embodiment of the application, the task template is a structured data acquisition instruction manual, including a specific list of data to be acquired (which physical quantities and sensor data need to be recorded), acquisition parameter requirements (sampling frequency, resolution, data format, acquisition duration, etc.), scene label input specifications (when and how the data acquisition personnel need to input what kind of labels), and precautions during the acquisition process (triggering conditions, exception handling, safety prompts, etc.).

[0061] In some embodiments, the task template can be pre-configured in the target vehicle, or a task template matching the collection task can be issued when the collection task is issued.

[0062] The data collection task indicates "what kind of data needs to be obtained", while the task template indicates "how to collect the data".

[0063] It should be noted that if the data collection task includes new requirements (such as adding "collecting steering wheel angle" or "requiring marking whether there are obstacles in front"), the target vehicle can combine existing template fragments or create a new template.

[0064] S202, issue a task template to the target vehicle; the task template is used to indicate the information to be collected, as well as the scene label information entered by the data collector during the data collection process.

[0065] In this embodiment of the application, the information of the data to be collected may include requirements such as the data type and collection frequency.

[0066] In this embodiment, the task distribution and execution layer is responsible for real-time interaction with the target vehicle. When the task status is set to "Distributed," this layer pushes the task instructions and configuration information to the vehicle's in-vehicle intelligent terminal (vehicle infotainment system) via a message queue. Upon receiving the task, the data collection application on the vehicle infotainment system displays it in the task list. After logging in, the data collector clicks "Claim" to receive the task, records the claim time, the data collector's ID, and the vehicle identification number (VIN), and updates the task status to "Collecting," further binding this information to the metadata structure of the data collection task.

[0067] It should be noted that during the data collection process, based on the instructions of the task template, the data collector uses the vehicle-mounted marking tool (which supports single-point and interval marking) to add scene tags to the data. These tag information will be associated with the collected data stream.

[0068] In this embodiment, configurable task templates are used to adapt to different data collection modes. For example, for the "AVP parking" data collection task, the input function for parking lot information (name, number of floors, lighting, etc.) is integrated into the vehicle-side task interface, and this information is uploaded to the cloud along with the collected data and stored in the "parking lot asset database." For the "multiple intersections" data collection task, a geotagging function is integrated into the point-tracking tool. This design realizes the online and standardized processing of special processes, replacing error-prone manual form management, significantly improving the execution efficiency and accuracy of complex tasks, and supporting complex and multi-type tasks.

[0069] It should be noted that the scene tag information entered by the data collectors during the data collection process can adopt a three-level coding system: primary tag (scene category, such as 'parking' 'intersection'), secondary tag (scene subcategory, such as 'AVP parking' 'rainy day intersection'), and atomic tag (specific attribute, such as 'indoor parking lot' 'moderate rain'). The tag code corresponds one-to-one with the attribute fields in the cloud asset database. When the collectors are tagging during the collection process, they only need to select the tag name on the vehicle, and the code will be automatically associated. After uploading, the cloud does not need to convert it again and can be directly used for processing and annotation.

[0070] In some embodiments, the completion rate of each data collection task, the timeliness of data collection personnel's annotations, and data quality can be monitored in real time based on a visual interactive interface.

[0071] In some embodiments, there are corresponding collection templates for certain asset-related data collection tasks. For example, for an AVP parking data collection task in a parking lot, which requires multiple data collections for the same vehicle in the same parking lot, the collection template is configured for multiple collections of the target vehicle. Figure 2As shown, the AVP parking data acquisition task may include the following steps.

[0072] S301, Create an AVP mapping task.

[0073] S302, sent to the vehicle end.

[0074] In some embodiments, corresponding task templates may also be issued.

[0075] S303, vehicle-side map data collection is performed.

[0076] S304, Data collection complete. Enter parking lot attributes.

[0077] Parking lot attributes are included in the scene label information entered by the data collector.

[0078] S305, Data Upload, Create / Update Asset Records.

[0079] When the parking lot is first collected, the data collection platform creates asset records related to the parking lot; when the parking lot is collected again in subsequent collections, the data collection platform updates the asset records related to the parking lot.

[0080] S306, associated parking lot assets.

[0081] The parking lot asset database can store data by parking lot, including parking lot ID, name, and corresponding collected data.

[0082] S307, Create an AVP location task associated with the same asset.

[0083] S308, sent to the vehicle.

[0084] S309, vehicle-side location data collection.

[0085] For the second data collection, the vehicle-side device can use the task template and parking lot asset database to indicate the location of the parking lot, and then perform the location data collection.

[0086] S310, data upload.

[0087] S311, Task completed, asset status updated.

[0088] This application provides a data acquisition method. Based on the acquisition task, a corresponding task template is determined, and the task template is further issued to the target vehicle, instructing the target vehicle on the data acquisition process and instructing the acquisition personnel to input scene label information. In this way, by issuing the same task template to the same acquisition task, data collected by different acquisition personnel, different target vehicles, and at different times maintains consistency in structure, format, and parameter requirements, avoiding data heterogeneity and improving the efficiency of multi-source data fusion. Moreover, acquisition personnel only need to input scene label information according to the template prompts, reducing the probability of misoperation and improving the quality of data acquisition.

[0089] In some embodiments, the method may further include steps S401 to S402.

[0090] S401 receives the collected data sent by the target vehicle.

[0091] In the embodiments of this application, such as Figure 3 As shown, based on the aforementioned embodiments, the data acquisition platform obtains delivery requirements (including vehicle series, data type, project, volume, cycle, etc.), breaks them down into one or more acquisition work orders (including acquisition date, acquisition scenario, cycle, etc.), further determines one or more acquisition tasks corresponding to each acquisition work order (e.g., breaking down acquisition work orders by day to obtain corresponding acquisition tasks), and distributes the acquisition tasks to the target vehicles. The acquisition personnel receive the tasks on the vehicle's end: the acquisition personnel's ID and vehicle identification number are bound to the acquisition task. The system displays acquisition status, receipt status, and completion status.

[0092] Furthermore, the data collectors collect data based on the data collection tasks they receive and the task templates they are issued. The collected data is stored on the vehicle and then transmitted back to the data collection platform.

[0093] Finally, the data acquisition platform obtains and stores the data sent by the target vehicle. After the data is entered into the database, the acquisition work order is updated, and statistics on the amount of data collected and the progress of data upload are added to the work order.

[0094] In some embodiments, the updated data collection work order is displayed on a visual interactive interface.

[0095] S402, add an identifier for the collected data.

[0096] The relationships between the identifiers of the collected data and the identifiers of the delivery requirements, the identifiers of the collection tasks, the identifiers of the vehicles, and the identifiers of the collection personnel are established based on the metadata structure.

[0097] In this embodiment, based on the data lineage and asset management module and the metadata structure, a binding relationship is established and maintained between the collected data and the identifiers of various objects involved in the data flow process, such as collection tasks, work orders, delivery requirements, collection personnel, and target vehicles. For specific collection types (such as parking, multiple intersections), an asset database (such as parking lot database, intersection database) is established, and the collected scene (parking lot, intersection) information (name, GPS, attributes, etc.) is associated with the specific data batch and the original collection task and delivery requirements.

[0098] It should be noted that after data collection is completed, the data packet can have its corresponding collection task ID embedded in the metadata structure based on the corresponding relationship during upload. The progress status of upload, de-identification, and conversion will be synchronized back to the cloud in real time through callback interfaces, and the status of the corresponding task will be updated accordingly.

[0099] In this embodiment, the data lineage and asset management module is responsible for establishing and persisting the relationships between data entities. It maintains multiple relationship tables in the database, including a "delivery requirement-work order-task" relationship table, a "task-data batch" relationship table, and a "data batch-processing record" relationship table, etc.

[0100] In some embodiments, for specific data collection types, such as "parking," this module maintains a "parking lot asset table," recording the unique ID, name, GPS coordinates, administrative division, number of floors, indoor / outdoor status, lighting conditions, and ground material of each collected parking lot. Each record is associated with the "task ID" and "data batch" for that parking lot. Similarly, a "crossroads point asset table" can be created for "multiple intersections." This allows data users (algorithm engineers) to quickly retrieve all relevant historical data using scenario tags such as "indoor underground parking lot with two floors in a certain location."

[0101] This application provides a data acquisition method that receives acquisition data sent by a target vehicle and further adds an identifier to the acquisition data. The identifier of the acquisition data is associated with the identifiers of the delivery requirement, the acquisition task, the vehicle, and the acquisition personnel based on a metadata structure. Thus, through the metadata structure, a structured, multi-dimensional association is established between the data and its source (delivery requirement), execution unit (acquisition task), carrier (target vehicle), and operator (acquisition personnel). Based on the metadata structure, any acquisition data can be traced back to the specific delivery requirement, as well as the target vehicle and acquisition personnel involved in the acquisition process. When anomalies occur in the acquisition data, the source of the problem can be quickly located, shortening the troubleshooting time for data instruction issues and significantly improving the efficiency of data governance. Furthermore, it supports multi-dimensional data retrieval and filtering, increasing the amount and dimensions of information that can be displayed on the visual interactive interface.

[0102] In some embodiments, the method may further include steps S501 to S503.

[0103] S501 transmits the collected data to the data processing platform.

[0104] In this embodiment, the data processing platform may include downstream platforms for processing and labeling data, or neural network models trained based on the collected data.

[0105] It should be noted that the data acquisition platform includes a data processing link module, which provides a standard interface to transmit the acquired data and the associated information of the acquisition tasks, such as the corresponding metadata structure, including task ID, batch number, etc., to the downstream data processing and annotation platform.

[0106] S502 receives processing status information returned by the data processing platform; the processing status information includes processing progress, usage, effectiveness, and retention rate.

[0107] In this embodiment, after the data acquisition platform transmits the acquired data to the data processing platform, it receives processing status information returned by the downstream data processing platform, including metrics such as processing progress, usage, effectiveness, and retention rate. It should be noted that when the acquired data enters the data processing platform, the platform does not update the processing status item by item; instead, it can aggregate and statistically analyze the data according to dimensions such as acquisition task and delivery requirements.

[0108] It should also be noted that for each data collection task or delivery requirement, the data processing platform can generate one or more processing status records.

[0109] S503, based on the metadata structure, establishes a relationship between processing status information and the identifiers of delivery requirements and collection tasks.

[0110] In this embodiment, for processing status information, the data acquisition platform can write it into a dedicated status information table or time-series database, and use the same metadata specification during storage, associating it with the corresponding acquisition task and work order. Thus, based on the metadata structure, the status information of all acquisition tasks under a specific delivery requirement can be queried on the visual interactive interface using the delivery requirement identifier; the status changes of the task at different points in time can be viewed using the acquisition task identifier.

[0111] It should be noted that the downstream feedback data received by the data processing link linkage module is back-synchronized to the task management layer for dynamically adjusting the data acquisition task configuration and displaying it on the visual interactive interface, thus forming a closed-loop collaboration.

[0112] It's also worth noting that the data processing link module is crucial for connecting the data flow and the status flow. It provides standard data access interfaces for downstream cleaning and labeling platforms. When a batch of data is uploaded and enters the processing flow, this module transmits the "Collection Task ID," "Collection Work Order ID," and related business metadata (such as scene tags) to the downstream systems. When the downstream systems complete data processing, labeling, or quality inspection, they send the processing results (such as success rate, effectiveness rate, and details of problematic data) back to this system through the standard interface. By associating these results with the original collection task, the "Collection Task Details" page in the visual interactive interface not only displays the collection progress but also the progress of subsequent processing and data quality indicators, achieving true "full lifecycle" tracking.

[0113] This application provides a data acquisition method that transmits the acquired data to a data processing platform, receives processing status information returned by the platform, and establishes an association between the processing status information and the identifiers of delivery requirements and acquisition tasks based on a metadata structure. In this way, based on the processing status information, low-quality data can be identified in a timely manner, and its data source can be identified based on the metadata structure, allowing for timely location of data problems, forming an optimized closed loop, and avoiding ineffective acquisition and storage.

[0114] In some embodiments, when the processing status information indicates an anomaly, the method may further include steps S601 to S603.

[0115] S601 determines the corresponding data collection task, target vehicle, and corresponding data collection personnel based on the collected data.

[0116] Referring to the above embodiments, the collected data refers to the raw records collected by the target vehicle according to the task template and uploaded to the data processing platform, including sensor data, videos / images, scene tags, etc. This data is already associated with the collection task identifier, vehicle identifier, and collection personnel identifier in the metadata structure.

[0117] In this embodiment, an abnormal processing status information indication means that the collected data is determined to be unqualified, incomplete, or invalid. For example, this could be due to missing data, substandard data quality, or scene labels not conforming to specifications. In this case, the data acquisition platform can use information such as the acquisition task, target vehicle, and acquisition personnel associated with the collected data as defined in the metadata structure.

[0118] In some embodiments, other relevant information may also be determined, such as the data collection period of the batch and the reasons for non-compliance, which can be used as the basis for adjustment when the data collection task is reissued.

[0119] S602, the corresponding data collection task is reissued to the target vehicle, instructing the data collection personnel to recollect the data and obtain the updated data.

[0120] In this embodiment of the application, after locating the information such as the collection task, target vehicle, and collection personnel associated with the collected data, the data collection platform can reissue the same or modified collection task, instructing the collection personnel to re-collect the batch of data.

[0121] In this embodiment, the data acquisition platform can adjust or supplement the original acquisition task based on the reason for non-compliance, and then reissue the updated acquisition task and the corresponding task template. After issuance, the platform can push task reminders to the acquisition personnel through vehicle screens, handheld terminals, etc., instructing them to re-acquire data.

[0122] It should also be noted that after the updated data collection task is issued, abnormal data collection data can be marked as "re-collecting" in the visual interactive interface to avoid duplicate data collection.

[0123] In some embodiments, the data can be verified in real time during the data collection process based on the reason for the anomaly in the previous data collection, so as to avoid generating unqualified data again.

[0124] S603 receives and stores the updated collected data.

[0125] It should be noted that the data collection personnel collect and upload the updated data again according to the reissued data collection task. The updated data can overwrite the original data, or it can be stored as an updated version on the data collection platform and associated with the original data to facilitate auditing and traceability.

[0126] In some embodiments, after the updated collected data is uploaded, the updated collected data can be verified again. If it is still unqualified, the re-collection process can be triggered again (limiting the number of re-collections, for example, 3 times).

[0127] This application provides a data acquisition method. Based on the acquired data, the corresponding acquisition task, target vehicle, and corresponding acquisition personnel are determined. The acquisition task is then reissued to the target vehicle, instructing the acquisition personnel to re-acquire data, resulting in updated data. This updated data is then received and stored. This method accurately locates the re-acquisition target. Through metadata association, the corresponding task, vehicle, and personnel can be found from the non-compliant data without manual querying, significantly improving the efficiency of supplementary data acquisition. Furthermore, by repeatedly re-acquiring data until it is compliant, the method forces the optimization of task templates and the standardized operation of acquisition personnel, thereby improving the overall data compliance rate in the long term.

[0128] In some embodiments, after receiving the processing status information returned by the data processing platform in step S502, the method may further include the following steps S701 to S702.

[0129] S701 updates the configuration parameters of the data acquisition task based on the processing status information; the configuration parameters include the acquisition area, the number of acquisitions, and the type of data to be acquired.

[0130] In this embodiment, the configuration parameters of a data acquisition task refer to adjustable variables that describe "how to execute, where to execute, how many times to execute, and what to collect" of a data acquisition task. These parameters can be dynamically adjusted before the task is issued to adapt to feedback information during the actual execution process.

[0131] Among them, the collection area indicates the geographical range in which the target vehicle should perform data collection; the number of collections indicates the number of times the target vehicle needs to perform the collection task repeatedly; and the type of data to be collected indicates the specific types and contents of data required by the task.

[0132] In this embodiment of the application, the configuration parameters of unissued tasks are adjusted based on the feedback data of the processing status information, thereby improving the efficiency, coverage or resource utilization efficiency of subsequent data collection.

[0133] It's important to note that processing status information (processing progress, usage, effectiveness, retention rate) reflects the results and problems of executed data collection tasks from different perspectives. The data collection platform can use this information to determine which configuration parameters for currently unissued tasks need adjustment. For example, if the processing status information indicates that the effectiveness of data collection task T001 is only 45%, the reason is insufficient lighting causing video blurring. Therefore, updating configuration parameters could include reducing the collection area and excluding poorly lit sections.

[0134] S702 updates one or more unissued data collection tasks based on the updated configuration parameters of the data collection tasks.

[0135] In this embodiment of the application, after modifying the configuration parameters, these updates can be further applied to the unissued data collection tasks.

[0136] In some embodiments, if multiple undelivered tasks share the same task template, the task template can be updated first, and then all collection tasks corresponding to the task template will automatically obtain the updated configuration parameters.

[0137] It should be noted that after the update, the status of unassigned tasks remains unchanged (still "pending assignment"), but the configuration parameters have been updated. The scheduling system will use the latest configuration parameters when selecting tasks for assignment subsequently.

[0138] In some embodiments, if the updated task differs significantly from the original task (e.g., the region is completely different), the system may prompt the scheduler to reassess whether the delivery requirements need to be re-disassembled, rather than simply reusing the original task structure.

[0139] This application provides a data acquisition method that updates the configuration parameters of acquisition tasks based on processing status information, and further updates one or more unreleased acquisition tasks based on the updated configuration parameters of the acquisition tasks. In this way, the data acquisition platform can automatically adjust the configuration parameters of unreleased acquisition tasks based on the processing status information from actual execution feedback, forming a closed loop of acquisition-feedback-optimization. This avoids repetitive and inefficient acquisition, facilitates auditing and subsequent optimization strategy design, and improves the effectiveness of data acquisition.

[0140] In some embodiments, after step S104, which displays and updates the data acquisition view of the target vehicle on the visual interactive interface based on the vehicle status information, the method may further include the following steps S801 to S802.

[0141] S801 receives resource scheduling instructions input by the dispatcher; the resource scheduling instructions are input by the dispatcher based on the data acquisition view.

[0142] In this embodiment of the application, the data acquisition view refers to a comprehensive interface that displays information such as the target vehicle status, the progress of the acquisition task, the data quality overview, and the resource usage in real time on a visual interactive interface in the form of graphics, dashboards, or maps.

[0143] It should be noted that dispatchers are the operation and management personnel responsible for monitoring, coordinating and optimizing the entire data acquisition system. They have the authority to understand and make decisions and can manually intervene in the execution process of any target vehicle or any acquisition task through a visual interactive interface.

[0144] In this embodiment, the resource scheduling instruction is a structured instruction generated by the scheduler through interactive operations such as clicking, dragging, selecting, and filling in parameters on a visual interactive interface. This instruction is used to trigger adjustments to the metadata structure, collection tasks, etc.

[0145] In this embodiment, the dispatcher logs into the visualization interface, views the data acquisition view, and identifies situations requiring manual intervention by observing various visualization elements. After identifying the problem, the dispatcher inputs resource scheduling instructions through the interactive controls on the visualization interface. For example, resource scheduling instructions could include: pausing data acquisition task T007, reassigning tasks V005, V006, and V007 to vehicle T002, and adaptively reconstructing the corresponding metadata structure, etc.

[0146] S802, based on resource scheduling instructions, adjusts the metadata structure and / or one or more acquisition tasks.

[0147] In this embodiment of the application, after the scheduler completes the interactive operation on the visual interactive interface, a corresponding resource scheduling instruction is generated, and further adjustment operations are performed based on the instruction type.

[0148] It should be noted that if a conflict occurs in the resource scheduling instructions, the scheduler will be prompted to re-enter the resource scheduling instructions via a visual interactive interface.

[0149] It should also be noted that when the data acquisition platform performs corresponding adjustment operations, the content displayed on the visual interactive interface can be updated in real time. For example, the progress bar of a paused task is frozen, a vehicle whose acquisition task has been reassigned is moved to a new task area, and its corresponding metadata structure is updated.

[0150] In this embodiment, transparent process monitoring is provided: through the second-level feedback of task status (such as issued, received, collecting, completed, uploaded, processing, available), managers can grasp the precise status of each vehicle and each task in real time on a visual interactive interface. At the same time, the progress indicators of each stage of data processing are also synchronized in real time, making the entire process from data collection to final availability completely transparent, which facilitates resource scheduling, risk warning, and efficiency analysis.

[0151] This application provides a data acquisition method. The data acquisition platform receives resource scheduling instructions input by schedulers and adjusts the metadata structure and / or one or more acquisition tasks based on these instructions. In this way, schedulers can proactively intervene in task scheduling decisions based on information displayed on a visual interactive interface, enabling rapid response to emergencies and improving the platform's flexibility.

[0152] In some embodiments, the data acquisition view includes at least one of the following (1)-(3): (1) Delivery Requirement Progress Dashboard: The delivery requirement progress dashboard is used to display the completion progress of each delivery requirement.

[0153] (2) Data collection task monitoring dashboard: The data collection task monitoring dashboard is used to display the real-time task status of each target vehicle.

[0154] (3) Asset database dashboard: The asset database dashboard is used to display the distribution of collected parking lots and intersections.

[0155] In this embodiment, the visual interactive interface is an operating interface for management personnel. Based on data from all the aforementioned modules, it provides multi-dimensional, real-time updated views. For example, the "Delivery Request Progress Dashboard" displays the overall completion percentage of each request in card format; the "Collection Task Monitoring Dashboard" displays the real-time task status of all vehicles in list or map format; and the "Asset Library Dashboard" displays the distribution of collected parking lots and intersections in map-based point-and-dot format. These dashboards provide intuitive and real-time data support for management decisions.

[0156] It should be noted that the data acquisition view is a visual command platform for dispatchers and operations managers. It integrates and presents scattered information such as delivery requirements, acquisition tasks, vehicle status, and acquired assets through multiple professional dashboards.

[0157] Among them, for (1), the delivery requirement progress dashboard is a visual panel used to display the progress status of each delivery requirement from its inception to its completion. It helps schedulers understand the degree to which each business requirement is met and determine whether resource allocation needs to be adjusted or requirements need to be re-divided. The delivery requirement progress dashboard is used to display information such as basic requirement information, completion progress, time status, and resource usage.

[0158] Among them, for (2), the data collection task monitoring dashboard is a dynamic panel used to display the real-time task status of each target vehicle. It helps dispatchers to grasp the on-site situation of each task in real time from the perspective of the vehicle and the execution level, and quickly discover anomalies in the execution. The data collection task monitoring dashboard is used to display information in dimensions such as basic vehicle information, currently executed tasks, task execution status, real-time feedback of data instructions, and data collection personnel information.

[0159] Among them, for (3), the asset database dashboard is a spatial information panel used to display the distribution of collected parking lots and intersections. It helps dispatchers understand which key scenarios (parking lots, intersections) have been covered, the quality of the coverage, and which still have gaps, so as to plan subsequent data collection tasks in a targeted manner. The resource database dashboard is used to display information on parking lot distribution, intersection distribution, data collection coverage, and other dimensions.

[0160] This application provides a data acquisition method. The data acquisition view includes one or more of the following: a delivery requirement progress dashboard, a data acquisition task monitoring dashboard, and an asset database dashboard. In this way, schedulers can view the acquisition progress of each delivery requirement in real time based on the data acquisition view, supporting data-driven task planning and maximizing the efficiency and output of data acquisition.

[0161] In some embodiments, such as Figure 4 As shown, based on the above steps, a specific implementation process is explained: First, the delivery requirements were obtained: "Intersection data in rainy weather at location A, 1000 points". Based on dimensions such as vehicle series / data source / project / volume, the delivery requirements were broken down into two collection work orders, including: Collection Work Order 1: "Collection of intersection data in rainy weather in July XX" and Collection Work Order 2: "Supplementary collection of intersection data in rainy weather in August XX".

[0162] Furthermore, based on dimensions such as collection date, collection scenario, and cycle, collection work order 1 is broken down into collection tasks 1-3, and collection work order 2 is broken down into collection tasks 4-6. The name, collection progress, relevant vehicle identification number (VIN), collector, and collection progress of each collection task are displayed in real time on the visual interactive interface. For example, for collection task 4, the visual interactive interface displays: Collection time: 2025-08-01; Task content: Vehicle VIN004, target 400 minutes; Collection status: "Pending issuance"; Collection progress: "0%"; Vehicle identification number: VIN004; Collector: Wang Wu; Collection time: 08-01; Collection progress: "Not issued".

[0163] The data acquisition method, vehicle, and data acquisition platform provided in this application embodiment will be described in detail below, taking into account specific application scenarios.

[0164] This application provides a cloud-based management system for autonomous driving data acquisition tasks, such as... Figure 5 As shown, it includes: Task Management Layer: This layer includes delivery requirement management, collection work order management, and collection task management. It receives and manages upstream delivery requirements, decomposes each delivery requirement into one or more collection work orders, and further breaks down each collection work order into vehicle-specific, day-based collection tasks. This layer establishes a three-level task tree structure of "delivery requirement - collection work order - collection task".

[0165] Task distribution and execution layer: This layer includes task instruction encapsulation, vehicle-side communication interface, and status synchronization reception. The vehicle-side communication interface and status synchronization reception connect to the vehicle-side system to automatically distribute data collection tasks to the target vehicle's in-vehicle infotainment system and receive task status, retrieval information (VIN, data collector), data tagging, and data upload batch information returned by the vehicle-side system. This layer interacts with the vehicle-side system to achieve automatic task distribution and second-level back-to-cloud transmission of vehicle-side status via the vehicle network.

[0166] The data processing link linkage module includes upstream interfaces, downstream interfaces, and status synchronization. It provides standard interfaces. The upstream interface communicates with the upstream requester's algorithm / annotation team to receive delivery requirements. The downstream interface transmits the associated information of the collection task (such as task ID and batch number) to the downstream data processing and annotation platform, and receives indicators such as processing progress, usage, effectiveness, and retention rate returned by the downstream processing links, and associates them back to the corresponding collection task and work order.

[0167] Data lineage and asset management module: Based on the data lineage pathway, it maintains the same task database as the task management layer for data collection tasks, establishing and maintaining the binding relationship between collected data and collection tasks, work orders, and delivery requirements. It also includes parking lot asset databases and port asset databases. For specific collection types (such as parking, multi-intersection), asset databases (such as parking lot databases, intersection databases) are established, associating the collected scene (parking lot, intersection) information (name, GPS, attributes, etc.) with specific data batches and original tasks, and storing it in the user database.

[0168] Visual dashboards (interactive visual interface): These include delivery requirement dashboards, data acquisition and monitoring dashboards, asset database dashboards, and data residual dashboards. The asset database dashboard retrieves data from the user database. Based on the data provided by the above modules, it dynamically displays the real-time progress of acquisition work orders / tasks, vehicle status, data processing status at each stage, asset database coverage, and global completion progress statistics based on delivery requirements.

[0169] Each module achieves data interoperability through a unified metadata specification (including task ID, work order ID, batch number, vehicle information, and tag code). The three-level task tree information generated by the task management layer is synchronized to the data lineage module. The vehicle status data of the task issuance and execution layer is pushed to the visualization dashboard in real time. The downstream feedback data received by the data processing link linkage module is synchronized back to the task management layer to dynamically adjust the collection task configuration and form a closed-loop collaboration.

[0170] like Figure 3 As shown, the cloud management system of the present invention is deployed on a cloud server cluster, communicates with the vehicle through the Internet of Vehicles, and integrates with downstream data processing platforms and annotation platforms through internal APIs.

[0171] “The vehicle-to-cloud tagging system adopts a three-level coding system: first-level tags (major scene categories, such as ‘parking’ and ‘intersection’), second-level tags (sub-scene categories, such as ‘AVP parking’ and ‘intersection in rainy weather’), and atomic tags (specific attributes, such as ‘indoor parking’ and ‘moderate rain’). The tag codes correspond one-to-one with the attribute fields in the cloud asset library. When tagging on the vehicle, you only need to select the tag name, and the system will automatically associate the code. After uploading, there is no need for secondary conversion in the cloud, and it can be directly used for processing and labeling.” The task management layer is the logical core of the system. It receives "delivery requirements" from the algorithm or annotation team, which include key information such as the vehicle type, scenario, volume, format, and cycle of the required data. The system creates a logical container for each delivery requirement, and the data collection manager creates a "data collection work order" under this requirement. A data collection work order typically corresponds to a data collection plan for a specific scenario within a certain time period. For example, a "July Data Collection Work Order for Rainy Day Intersections in City A" is created for "Delivery Requirement: Data on Rainy Day Intersections in City A, 1000 minutes". Subsequently, the manager breaks down this work order into specific, executable "data collection tasks", such as "July 10th, Vehicle VIN001, Collect Rainy Day Intersection Data in City A, Target Volume 200 minutes". Each data collection task is clearly associated with a vehicle and a specific execution date.

[0172] The task distribution and execution layer is responsible for real-time interaction with the vehicle. When the task status is set to "Distributed," this layer pushes the task instructions and configuration information to the target vehicle's in-vehicle intelligent terminal (vehicle infotainment system) via a message queue. The data collection application on the vehicle infotainment system (such as the "StarRing APP") receives the task and displays it in the task list. After logging in, the data collector clicks "Claim" to receive the task. The system records the claim time, the data collector's ID, and the vehicle identification number (VIN), and updates the task status to "Collecting." During the data collection process, the data collector uses a vehicle-side tagging tool (supporting single-point and interval tagging) to add scene tags to the data. These tags are associated with the collected data stream. After collection is complete, the data packet embeds its corresponding data collection task ID during upload. The progress status of upload, desensitization, and conversion is synchronized back to the cloud in real time via callback interfaces, updating the status of the corresponding task.

[0173] The data processing link module is crucial for connecting data flow and status flow. It provides standard data access interfaces for downstream cleaning and labeling platforms. When a batch of data is uploaded and enters the processing flow, this module transmits the "Collection Task ID," "Collection Work Order ID," and related business metadata (such as scene tags) to the downstream system. When the downstream system completes data processing, labeling, or quality inspection, it sends the processing results (such as success rate, effectiveness rate, and details of problematic data) back to this system through the standard interface. This system associates these results with the original collection task, thus displaying not only the collection progress on the "Collection Task Details Page" but also the progress of subsequent processing and data quality indicators, achieving true "full lifecycle" tracking.

[0174] The Data Lineage and Asset Management module is responsible for establishing and persisting the relationships between data entities. It maintains multiple relationship tables in the database, including a "Delivery Request-Work Order-Task" relationship table, a "Task-Data Batch" relationship table, and a "Data Batch-Processing Record" relationship table. For special collection types, such as "parking," this module maintains a "Parking Lot Asset Table," recording the unique ID, name, GPS coordinates, administrative division, number of floors, indoor / outdoor status, lighting conditions, and ground material of each parking lot whose data has been collected. Each record is associated with the "Task ID" and "Data Batch" for that parking lot. Similarly, a "Intersection Point Asset Table" can be created for "Multiple Intersections." This allows data users (algorithm engineers) to quickly retrieve all relevant historical data using scenario tags such as "Indoor Underground Two-Level Parking Lot in a Certain Location."

[0175] Visual dashboards are user interfaces for managers. Based on data from all the modules mentioned above, they provide multi-dimensional, real-time updated views. For example, the "Delivery Request Progress Dashboard" displays the overall completion percentage of each request in card format; the "Data Acquisition Task Monitoring Dashboard" displays the real-time task status of all vehicles in list or map format; and the "Asset Library Dashboard" displays the distribution of collected parking lots and intersections in map point format. These dashboards provide intuitive and real-time data support for management decisions.

[0176] In some embodiments, taking an AVP parking data acquisition task as an example, this application details how it solves the management problem of complex processes.

[0177] Step S1: The algorithm team proposes the delivery requirement of "AVP parking lot mapping and positioning data" and enters it into the system.

[0178] Step S2: Create a "XX City AVP Parking Data Collection Work Order" and break down the task. He created a data collection task named "Parking Lot P Mapping Task" and assigned it to vehicle VIN002. The task template was "AVP Mapping Mode".

[0179] Step S3: Data collector Zhang San drives vehicle VIN002 and accepts the task via the vehicle's infotainment app. Upon arriving at parking lot P, he initiates the "mapping" data collection. After completion, the app displays an interface prompting him to input or select information such as the name, administrative district, number of floors, indoor / outdoor location, lighting conditions, and ground material of parking lot P. This information, along with the collected raw data (DAT file) and the "mapping" trajectory data, is packaged together.

[0180] Step S4: When uploading data, include the task ID and parking lot attribute information. After receiving the data, the cloud system first checks if "Parking Lot P" exists in the "Parking Lot Asset Table". If it does not exist, a new asset record is created, and the task ID, data batch number, GPS location, and all attribute information collected in this transaction are associated and stored. At the same time, the status of this "Mapping" task is updated to "Collection Completed, Awaiting Location".

[0181] Step S5: The next day, the data collection manager creates a "Parking Lot P Location Task," links it to yesterday's "Map Building Task" and "Parking Lot P Asset ID," and distributes it to the same vehicle (or vehicle on the same route). After Zhang San receives the task, the vehicle's APP automatically loads the parking lot P information and reference trajectory saved during yesterday's "Map Building." Zhang San then performs "location" data collection in the same parking lot.

[0182] Step S6: After the "location" data is uploaded, the system associates it with the "Parking Lot P Asset" and the corresponding "Mapping" task data. Only after both the "Mapping" and "location" data have been processed is the AVP parking data collection task considered complete. Throughout the entire process, asset information, task dependencies, and data status are all managed automatically online, completely avoiding the problems of information errors and lost dependencies inherent in traditional offline table management.

[0183] Example of exception handling: If data upload fails in step S4 (e.g., due to network interruption), the vehicle-side system automatically caches the data and metadata, and triggers a resume upload after the network is restored. If the upload fails after 3 retries, the vehicle-side system will synchronize the abnormal information (including the reason for failure and the cached data identifier) ​​to the cloud task distribution and execution layer, mark the task as 'upload abnormal' on the visual dashboard, and trigger an alarm for the operations personnel. The operations personnel can remotely view the failure details through the system or instruct the vehicle-side system to re-collect / upload the data.

[0184] If the downstream processing platform reports a 'data label error,' the data processing link module will synchronize the error information (including batch number and error label type) to the data lineage module, locating the corresponding collection task and collector. Operations personnel can then adjust the label configuration for that collector's subsequent tasks (e.g., adding label verification prompts) to achieve dynamic optimization. In some embodiments, such as Figure 6 The flowchart of the data acquisition method provided in the embodiments of this application is illustrated below.

[0185] S901, the task management layer creates a data collection task and generates a unique data collection task ID.

[0186] S902, the task is sent to the vehicle terminal and bound to the vehicle identification number / data collector ID.

[0187] S903, vehicle-side data collection and tagging are performed, and the data stream embeds task ID / scene tag.

[0188] S904, data is uploaded to the cloud, and the data lineage and asset management module generates a data batch number.

[0189] S905, Data lineage and asset management module, associates data batches with task IDs to establish lineage relationships.

[0190] S906, the data processing link linkage module triggers downstream processing and transmits the task ID / batch number.

[0191] S907 handles progress feedback and updates task status via callback.

[0192] S908, final delivery, dataset can be traced back.

[0193] In some embodiments, such as Figure 7 The flowchart of the data acquisition method provided in the embodiments of this application is illustrated below.

[0194] After the process begins, step S1101 is executed to create the task and generate a task ID. At this time, the status of the data collection task is "Status S1 Task Created".

[0195] S1102, Task Review, Operation Confirmation. At this time, the status of the data collection task is "Status S2 Task Review".

[0196] S1103, pending collection, waiting for the collector. The current status of the collection task is "Status S3 Pending Collection".

[0197] S1104, Determine whether to extract? If yes, proceed to step S1105; otherwise, change the status of the data collection task to "Abnormal E1 Task Expired" and return to step S1102.

[0198] S1105, Data Acquisition in Progress, Data Acquisition Execution. At this time, the data acquisition task status is "Status S4 Data Acquisition in Progress".

[0199] S1106, Determine whether the data collection task has been completed.

[0200] If completed, proceed to step S1107; if not completed, do not change the status of the data collection task, proceed to step S1106.

[0201] S1107, Data acquisition complete, data temporarily stored. At this time, the status of the acquisition task is "Status S5 Data acquisition complete".

[0202] S1108, determine if the collected data is abnormal.

[0203] If normal, continue to step S1109; if abnormal, the status of the acquisition task changes to "Abnormal E2 Acquisition Interruption", return to step S1102, or, in case of an abnormality, manually intervene to retry the upload. If the retry fails, the status of the acquisition task changes to "Abnormal E3 Upload Failed".

[0204] S1109, Uploading in progress, packaged and uploaded.

[0205] S1110, verification passed? If successful, continue to step S1111; if unsuccessful, the status of the data collection task changes to "Abnormal E3 Upload Failure".

[0206] S1111, In progress, desensitization / quality inspection. At this time, the status of the data collection task is "Status S7 In progress".

[0207] S1112, determine whether the quality inspection is qualified.

[0208] If qualified, continue to step S1113: under annotation, pre-annotation / manual, at this time the status of the data collection task is "Status S8 under annotation"; if unqualified, the status of the data collection task changes to "Abnormal E4 quality problem", and further determine whether it can be repaired. If it cannot be repaired, the status of the data collection task changes to "Abnormal E6 discarded", and the process ends; if it can be repaired, return to step S1111.

[0209] S1114, Has the acceptance been passed?

[0210] If successful, proceed to step S1115: Completed, deliver for archiving, the status of the data collection task changes to "Status S9 Completed", and the process ends; if unsuccessful, the status of the data collection task changes to "Abnormal E5 Acceptance Failed", and the process ends.

[0211] The key to this system lies in the collaboration of its modules and the closed-loop design of its data flow. The task management layer defines the workflow framework; the task issuance and execution layer digitizes physical world actions; the data processing link module acts like a nervous system, feeding back the status of each stage of the data acquisition process to the brain (management system); the data lineage and asset management module is the system's memory center, solidifying all relationships; and the visual dashboard provides the system's sensory presentation. These modules are tightly coupled through a unified database and API interface, enabling a simple "data upload" event to automatically trigger a series of chain reactions, including status updates, progress calculations, asset recording, and dashboard refreshes. This integrates previously scattered and manual processes into an intelligent, automated organic whole, ultimately solving the various technical problems raised in the background section efficiently and accurately.

[0212] The process by which this patent solves the technical problem through the above technical solution is as follows: 1. Resolving the disconnect between business needs and data collection: By establishing a three-tiered mapping of "delivery requirements - collection work orders - collection tasks," the final business use of any collected data can be traced back to the original requirement. A visual dashboard can track the overall progress of each delivery requirement in real time, enabling demand-driven, refined operations. This directly solves the problem of unclear "why collect data and for whom" in existing technologies.

[0213] 2. Achieve end-to-end data traceability: Through the "Data Processing Linkage Module" and the "Data Lineage Module," data collection tasks, vehicle, and personnel information are bound to the data at the initial upload stage and accompany the data flow to all subsequent stages. When data quality issues are discovered during processing or annotation, the specific collection batch, vehicle, collector, and even the scene description during collection can be immediately traced, greatly improving problem localization and closed-loop efficiency. This solves the pain points of data "black box" problems and poor traceability.

[0214] 3. Supports complex and diverse tasks: The system adapts to different data collection modes through configurable task templates. For example, for the "AVP parking" task, the system integrates input functionality for parking lot information (name, floor number, lighting, etc.) into the vehicle-side task interface, and uploads this information along with the collected data to the cloud, storing it in the "Parking Lot Asset Database." For the "Multiple Intersections" task, a geotagging function is integrated into the point-tracking tool. This design enables the online and standardized processing of special workflows, replacing error-prone manual form management and significantly improving the efficiency and accuracy of complex task execution.

[0215] 4. Provides transparent process monitoring: Through the second-level feedback of task status (such as issued, received, collecting, completed, uploaded, processing, available), managers can keep track of the precise status of each vehicle and each task in real time on the dashboard. At the same time, the progress indicators of each stage of data processing are also synchronized in real time, making the entire process from data collection to final availability completely transparent, which facilitates resource scheduling, risk warning and efficiency analysis.

[0216] The beneficial effects of this invention are as follows: Direct effects: Enables end-to-end automated management from demand to delivery, improves the efficiency of task distribution by 90% (second-level distribution), reduces data traceability time from hours to seconds, reduces manual management costs by 80%, and improves the execution accuracy of complex tasks (such as AVP parking) to 99%.

[0217] Indirect effects: By strengthening data lineage, the speed of tracing and closing the loop on data quality issues is improved, thereby ensuring the data quality used for training autonomous driving algorithms. Establishing a scene asset library improves scene data retrieval efficiency by 85%, providing data support for shortening the iteration cycle of autonomous driving algorithms by 30%.

[0218] In another embodiment of this application, a vehicle is provided, the vehicle including a vehicle-mounted data acquisition unit; wherein: The vehicle-side data acquisition unit is configured to receive one or more data acquisition tasks, wherein the one or more data acquisition tasks are obtained by the data acquisition platform by breaking down the delivery requirements; wherein the identifier of the delivery requirements, the identifier of the data acquisition tasks, and the vehicle are associated with each other based on the metadata structure.

[0219] The vehicle-mounted data acquisition unit is also configured to send vehicle status information to the data acquisition platform at preset intervals during the data acquisition task. The vehicle status information includes vehicle information, data acquisition personnel information, and data acquisition status information. The vehicle status information is used to instruct the data acquisition platform to display and update the vehicle's data acquisition view on the visual interactive interface. The acquisition view is used to represent the completion status of the delivery requirements.

[0220] In some embodiments, the vehicle-mounted data acquisition unit is further configured to receive a task template sent by the data acquisition platform; the task template is used to indicate information about the data to be collected, as well as scene label information entered by the data acquisition personnel during the data acquisition process; the task template is determined by the data acquisition platform based on the data acquisition task.

[0221] In some embodiments, the vehicle-mounted data acquisition unit is further configured to send acquired data to the data acquisition platform; wherein, the identifier of the acquired data is associated with the identifier of the delivery requirement, the identifier of the acquisition task, the identifier of the vehicle, and the identifier of the acquisition personnel based on a metadata structure.

[0222] In some embodiments, the vehicle-mounted data acquisition unit is further configured to receive a corresponding data acquisition task; the corresponding data acquisition task is determined based on the data acquisition data, and the corresponding data acquisition task is used to instruct the data acquisition personnel to re-acquire the data acquisition data to obtain updated data acquisition data.

[0223] In yet another embodiment of this application, as Figure 8 As shown, a data acquisition platform 800 is provided, which includes a control unit 8001 and a visual interactive interface 8002; wherein: The control unit 8001 is configured to acquire delivery requirements; break down the delivery requirements into one or more collection tasks and distribute them to the corresponding target vehicles; wherein, the identifier of the delivery requirement, the identifier of the collection task, and the target vehicle are associated based on a metadata structure; during the execution of the collection tasks by the target vehicle, the control unit receives vehicle-side status information sent by the target vehicle at preset intervals; the vehicle-side status information includes vehicle information, collection personnel information, and data collection status information; based on the vehicle-side status information, the control unit displays and updates the data collection view of the target vehicle on a visual interactive interface; the collection view is used to represent the completion status of the delivery requirements.

[0224] The control unit 8001 is also configured to determine the corresponding task template based on the data acquisition task; send the task template to the target vehicle; the task template is used to indicate the information of the data to be collected, as well as the scene label information entered by the data acquisition personnel during the data acquisition process.

[0225] The control unit 8001 is also configured to receive the collected data sent by the target vehicle; add an identifier to the collected data; wherein the identifier of the collected data is associated with the identifier of the delivery requirement, the identifier of the collection task, the identifier of the vehicle and the identifier of the collection personnel based on the metadata structure.

[0226] The control unit 8001 is also configured to transmit the collected data to the data processing platform; receive the processing status information returned by the data processing platform; the processing status information includes processing progress, usage, effectiveness, and retention rate; and establish a correlation between the processing status information and the identifiers of the delivery requirements and the collection tasks based on the metadata structure.

[0227] The control unit 8001 is also configured to determine the corresponding data collection task, target vehicle, and corresponding data collection personnel based on the collected data; to reissue the corresponding data collection task to the target vehicle, instructing the data collection personnel to recollect the data to obtain updated data; and to receive and store the updated data.

[0228] The control unit 8001 is also configured to update the configuration parameters of the acquisition task based on the processing status information; the configuration parameters include the acquisition area, the number of acquisitions, and the type of acquisition data; and to update one or more unissued acquisition tasks based on the updated configuration parameters of the acquisition task.

[0229] The control unit 8001 is also configured to receive resource scheduling instructions input by the scheduler; the resource scheduling instructions are input by the scheduler based on the data acquisition view; and based on the resource scheduling instructions, adjustments are made to the metadata structure and / or one or more acquisition tasks.

[0230] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. The computer-readable storage medium can be transient or non-transient.

[0231] This application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, implement some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0232] It should be noted that although the invention has been described in detail through embodiments, the relative arrangement of components, numerical expressions, values, and symbols set forth in these embodiments are merely illustrative and do not limit the scope of this application.

[0233] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

[0235] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the embodiments of this application, all functional units may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the integrated unit may be implemented in hardware or in a combination of hardware and software functional units.

[0236] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A data acquisition method, characterized in that, The method includes: Obtain delivery requirements; The delivery requirement is broken down into one or more collection tasks and sent to the corresponding target vehicles; wherein, the identifier of the delivery requirement, the identifier of the collection task, and the target vehicle are associated based on a metadata structure. During the process of the target vehicle performing the data collection task, the vehicle status information sent by the target vehicle is received at preset time intervals; the vehicle status information includes vehicle information, data collection personnel information, and data collection status information. Based on the vehicle status information, the data acquisition view of the target vehicle is displayed and updated on a visual interactive interface; the acquisition view is used to characterize the completion status of the delivery requirement.

2. The method according to claim 1, characterized in that, After breaking down the delivery requirement into one or more collection tasks and issuing them to the corresponding target vehicles, the method further includes: Based on the aforementioned data collection task, a corresponding task template is determined; A task template is issued to the target vehicle; the task template is used to indicate the information to be collected, as well as the scene label information entered by the data collector during the data collection process.

3. The method according to claim 1, characterized in that, The method further includes: Receive the collected data sent by the target vehicle; Add an identifier to the collected data; The identifiers of the collected data are associated with the identifiers of the delivery requirements, the collection tasks, the vehicles, and the personnel based on the metadata structure.

4. The method according to claim 3, characterized in that, The method further includes: The collected data is transmitted to the data processing platform; Receive processing status information returned by the data processing platform; the processing status information includes processing progress, usage, effectiveness rate, and retention rate; Based on the metadata structure, the processing status information is associated with the identifier of the delivery requirement and the identifier of the collection task.

5. The method according to claim 4, characterized in that, In the event that the processing status information indicates an anomaly, the method further includes: Based on the collected data, the corresponding collection task, the target vehicle, and the corresponding collection personnel are determined. The corresponding data collection task is reissued to the target vehicle, instructing the data collection personnel to recollect the data to obtain updated data. Receive and store the updated collected data.

6. The method according to claim 4, characterized in that, After receiving the processing status information returned by the data processing platform, the method further includes: Based on the processing status information, update the configuration parameters of the data acquisition task; the configuration parameters include the acquisition area, the number of acquisitions, and the type of data to be acquired. Based on the updated configuration parameters of the data collection task, update one or more unissued data collection tasks.

7. The method according to claim 3, characterized in that, After displaying and updating the data acquisition view of the target vehicle on the visual interactive interface based on the vehicle status information, the method further includes: Receive resource scheduling instructions input by the scheduler; the resource scheduling instructions are input by the scheduler based on the data acquisition view; Based on the resource scheduling instructions, the metadata structure and / or one or more acquisition tasks are adjusted.

8. The method according to any one of claims 1-7, characterized in that, The data acquisition view includes at least one of the following: Delivery Requirement Progress Dashboard, which is used to display the completion progress of each delivery requirement; A task monitoring dashboard is used to display the real-time task status of each target vehicle. The asset database dashboard is used to display the distribution of collected parking lots and intersections.

9. A vehicle, characterized in that, The vehicle includes a vehicle-mounted data acquisition unit; wherein: The vehicle-side data acquisition unit is configured to receive one or more data acquisition tasks, wherein the one or more data acquisition tasks are obtained by the data acquisition platform by breaking down delivery requirements; wherein the identifier of the delivery requirements, the identifier of the data acquisition tasks, and the vehicle are associated with each other based on a metadata structure. The vehicle-mounted data acquisition unit is further configured to send vehicle status information to the data acquisition platform at preset intervals during the data acquisition task. The vehicle status information includes vehicle information, data acquisition personnel information, and data acquisition status information. The vehicle status information is used to instruct the data acquisition platform to display and update the vehicle's data acquisition view on the visual interactive interface. The acquisition view is used to characterize the completion status of the delivery requirement.

10. A data acquisition platform, characterized in that, The data acquisition platform includes a control unit and a visual interactive interface; wherein: The control unit is configured to acquire delivery requirements; decompose the delivery requirements into one or more collection tasks and distribute them to the corresponding target vehicles; wherein the identifier of the delivery requirement, the identifier of the collection task, and the target vehicle are associated based on a metadata structure; during the execution of the collection task by the target vehicle, the control unit receives vehicle-side status information sent by the target vehicle at preset intervals; the vehicle-side status information includes vehicle information, collection personnel information, and data collection status information; based on the vehicle-side status information, the control unit displays and updates the data collection view of the target vehicle on the visual interactive interface; the collection view is used to characterize the completion status of the delivery requirements.

Images