A vehicle data acquisition method and acquisition system

Abstract

The embodiment of the application provides a vehicle data acquisition method and an acquisition system, and relates to the technical field of vehicle data acquisition. The method comprises the following steps: generating at least one data acquisition strategy based on a trigger condition of data acquisition; wherein the data acquisition strategy is dynamically configured based on a regulation requirement, a road network feature and / or a vehicle version number; and the data acquisition strategy is sent to a vehicle end. The acquisition strategy can be dynamically configured according to the regulation requirement, the road network feature and the vehicle version number, and the flexibility is high, so that the problem that the existing vehicle data acquisition strategy is relatively single is solved.

Description

Technical Field

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

[0002] As the level of autonomous driving increases, closed-loop vehicle data has become the core foundation for algorithm iteration. However, existing vehicle data collection strategies are relatively simple. The cloud cannot dynamically adjust the collection strategy according to model iteration needs, regulatory changes, or road network characteristics. Once deployed, the vehicle's data collection logic remains unchanged for a long time or can only be upgraded via OTA, which is costly and lacks flexibility. Summary of the Invention

[0003] The purpose of this application is to provide a vehicle data acquisition method and system that can dynamically configure the acquisition strategy according to regulatory requirements, road network characteristics, and vehicle version number, which is highly flexible and solves the problem that the existing vehicle data acquisition strategies are relatively simple.

[0004] In a first aspect, this application provides a method for collecting vehicle data, applied in the cloud, the method comprising: generating at least one data collection strategy based on data collection triggering conditions; wherein the data collection strategy is dynamically configured based on regulatory requirements, road network characteristics, and / or the vehicle version number; and sending the data collection strategy to the vehicle.

[0005] In the technical solution of this application embodiment, at least one data collection strategy is generated and sent to the vehicle based on the triggering conditions of data collection. The cloud can dynamically configure the collection strategy according to regulatory requirements, road network characteristics, and changes in the vehicle version number, which is highly flexible.

[0006] In some embodiments, the triggering conditions include data acquisition methods, and the step of generating a data acquisition strategy includes: generating the data acquisition strategy based on vehicle-side event triggering; generating the data acquisition strategy based on periodic acquisition triggered by a vehicle-side timer; and generating the data acquisition strategy based on a one-time acquisition command. Data acquisition methods include trigger-based (vehicle-side event triggering), periodic acquisition, and one-time acquisition, employing multiple acquisition methods to meet different business scenarios.

[0007] In some embodiments, the data acquisition strategy includes the data type to be acquired and a priority identifier corresponding to the data type. The step of generating at least one data acquisition strategy includes: determining the data type to be acquired based on the triggering condition; determining the urgency priority according to the data type to be acquired; and generating a data acquisition strategy with a priority identifier. Priority control can be implemented on the acquisition strategy. Given limited resources such as vehicle-side computing, storage, and bandwidth, setting priorities can ensure that high-value, high-timeliness, and high-compliance data receive resource allocation and are acquired preferentially.

[0008] In some embodiments, the data acquisition strategy includes road network characteristics, and the step of generating at least one data acquisition strategy includes: generating a differentiated data acquisition strategy based on the road network characteristics. Differentiated acquisition strategies are issued "tailored to local conditions" based on different road network characteristics, ensuring that the acquisition strategies meet the data acquisition requirements of regulations and road scenarios.

[0009] In some embodiments, the road network features include geofencing, and generating differentiated data collection strategies based on the road network features includes: switching to a data collection strategy corresponding to the anonymization level based on the boundary determination results of administrative regions; configuring the data collection strategy to pause collection based on the geofencing of sensitive areas; and configuring the data collection strategy to collect all data based on the electronic fence of data open areas. Different collection strategies are adopted based on geofencing to ensure that data collection meets regulatory requirements.

[0010] In some embodiments, the road network features include road network feature labels, and the step of generating a differentiated data collection strategy based on the road network features includes: obtaining road scene types based on the road network feature labels; and generating a data collection strategy based on the road scene types. Using road network feature labels ensures that data collection meets the data collection needs of different road scene types.

[0011] Secondly, this application provides a vehicle data acquisition method applied to the vehicle end. The method includes: receiving a data acquisition strategy sent from the cloud; obtaining a dynamic priority based on a priority identifier in the data acquisition strategy; and performing hierarchical acquisition and backhaul of the data to be acquired based on the dynamic priority. Calculating the dynamic priority based on the priority identifier enables hierarchical data acquisition and backhaul, solving the problem of low-value redundant data consuming large amounts of transmission resources and resulting in low backhaul efficiency in existing acquisition methods.

[0012] In some embodiments, the method further includes: obtaining the policy triggering domain and the data acquisition domain in the data acquisition strategy; if the policy triggering domain and the data acquisition domain are different, then performing cross-domain data acquisition. Cross-domain data acquisition, based on multi-domain collaboration, enables accurate triggering of high-value scenarios and avoids the omission of valid data.

[0013] Thirdly, this application provides a vehicle data acquisition system. The system includes a cloud and a vehicle terminal. The cloud is used to generate at least one data acquisition strategy based on data acquisition triggering conditions and send the data acquisition strategy to the vehicle terminal. The data acquisition strategy is dynamically configured based on regulatory requirements, road network characteristics, and / or the vehicle version number. The vehicle terminal is used to obtain a dynamic priority based on a priority identifier in the data acquisition strategy and to perform hierarchical acquisition and transmission of the data to be acquired based on the dynamic priority. The system allows for dynamic configuration of the acquisition strategy according to regulatory requirements, road network characteristics, and the vehicle version number, offering high flexibility and solving the problem of existing vehicle data acquisition strategies being relatively simple. Calculating the dynamic priority based on the priority identifier enables hierarchical data acquisition and transmission, solving the problem of low-value redundant data consuming large amounts of transmission resources and resulting in low transmission efficiency in existing acquisition methods.

[0014] Fourthly, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program to enable the electronic device to perform the above-described vehicle data acquisition method.

[0015] Fifthly, this application provides a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described vehicle data acquisition method. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a vehicle data acquisition method provided in this application embodiment; Figure 2 This is a schematic diagram of cloud policy configuration provided in an embodiment of this application; Figure 3 A flowchart illustrating the generation of one data acquisition strategy provided in an embodiment of this application; Figure 4 A flowchart illustrating the generation of differentiated data collection strategies based on road network characteristics is provided in this application embodiment. Figure 5 This application provides a flowchart of the strategy distribution control process in its embodiments. Figure 6 A flowchart illustrating another vehicle data acquisition method provided in this application embodiment; Figure 7 This is a flowchart illustrating the cross-domain data acquisition process provided in an embodiment of this application. Figure 8 A detailed flowchart of cross-domain data acquisition provided in this application embodiment; Figure 9 This is a structural block diagram of a vehicle data acquisition system provided in an embodiment of this application.

[0018] icon: 110 - Cloud-based; 120 - Vehicle-based. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0020] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] With the development of intelligent driving, closed-loop vehicle data has become the foundation of intelligent driving research and development. Given the convergence of algorithmic frameworks, the upper limit of a model's intelligence primarily depends on the richness and multi-dimensional alignment of the training data. The essence of closed-loop vehicle data is the ability to sift effective information from massive amounts of driving data, feed it back into the model, and achieve continuous iteration through OTA (Over-The-Air) updates. Automakers with closed-loop capabilities will create a "data flywheel" effect—the more data, the faster the model evolves, forming a competitive barrier that is difficult to replicate. However, current data collection methods, such as cloud-based 110 (data acquisition) systems, cannot meet the needs of model iteration and cannot dynamically adjust the vehicle-side 120 (data acquisition) rules based on regulatory changes or road network characteristics. Once deployed, the vehicle-side 120 data acquisition logic remains unchanged for a long time or can only be upgraded via OTA, which is costly and lacks flexibility.

[0022] To address the aforementioned technical issues, this application provides a method for collecting vehicle data. This method can dynamically configure the collection strategy based on regulatory requirements, road network characteristics, and vehicle version number, offering high flexibility and solving the problem of the relatively singular nature of existing vehicle data collection strategies.

[0023] Please refer to Figure 1 , Figure 1 A flowchart of a vehicle data acquisition method provided in this application embodiment, the method including the following steps: S110: Based on the triggering conditions for data acquisition, generate at least one data acquisition strategy; wherein, the data acquisition strategy is based on regulatory requirements, road network characteristics, and / or, dynamic configuration of the vehicle version number; S120: Send the data acquisition strategy to vehicle terminal 120.

[0024] For example, different regions have different regulations. For the same vehicle model, the software version for vehicles sold in the EU is different from the software version sold in China. The desensitization requirements also vary in different cities or regions within the same country. Therefore, dynamic configuration can be performed as needed.

[0025] Since the vehicle-side 120 may meet multiple triggering conditions at the same time, multiple data collection strategies can be generated. Some data collection strategies may be dynamically configured based on regulatory requirements, road network characteristics and vehicle version number at the same time, while others may be dynamically configured based on only one of the regulatory requirements, road network characteristics and vehicle version number.

[0026] Based on regulatory requirements and road network characteristics, the dynamic configuration and collection strategy for vehicle version numbers offers high flexibility.

[0027] Please refer to Figure 2 , Figure 2 A schematic diagram for configuring a cloud-based 110 policy. In some embodiments, the triggering condition includes a data collection method, and the steps for generating a data collection policy include: The data collection strategy is generated based on the vehicle-side 120 event trigger. The data acquisition strategy is generated based on periodic data collection triggered by the vehicle-side 120 timer. The data acquisition strategy is generated based on a one-time acquisition command.

[0028] The application scenarios corresponding to different data acquisition strategies are shown in the table below:

[0029] Traditional trigger-based data collection methods are limited and cannot meet the data collection needs of various business scenarios. The data collection strategy in this application includes trigger-based collection, periodic collection, and one-time pull collection, which can meet different business collection scenarios.

[0030] In some embodiments, the data collection strategy includes strategy version control, and sending the data collection strategy to the vehicle terminal 120 includes: Based on the region code and vehicle version number reported by the vehicle terminal 120, a data collection strategy corresponding to the desensitization level and sensor configuration is issued.

[0031] The regulatory compliance level of the data collection strategy can be configured to vary depending on the software version and region. For example, the software version of vehicles of the same model sold in the EU (GDPR compliant) and the version sold in China (according to the "Regulations on the Management of Automotive Data Security") have different vehicle version numbers based on the different regulatory requirements of the two regions; the anonymization requirements also differ between different cities or regions within the same country (such as political centers and remote areas). Correspondingly, the EU version requires irreversible blurring of pedestrian faces and license plates and prohibits the collection of in-vehicle videos; the Chinese version may allow collection but requires immediate anonymization.

[0032] Based on the region code and legal version number reported by the vehicle terminal 120, the cloud-based 110 system issues a collection strategy with corresponding desensitization levels, setting the data type of the cockpit domain camera to "collect only skeleton points" instead of the original image.

[0033] The sensor configurations also differ. For example, some vehicles are equipped with forward-facing lidar, while others only have cameras and millimeter-wave radar; the number of cockpit cameras also varies (such as monocular DMS or binocular OMS).

[0034] Adaptation Requirements: The data source referenced in the acquisition strategy must match the actual existing sensors. For example, "Scene Acquisition" requires LiDAR point clouds; if no LiDAR is available, it should be replaced with a list of millimeter-wave radar targets.

[0035] Therefore, the corresponding data specification definition field (data_spec field) can be issued according to the vehicle configuration code (such as lidar_present=true / false) to avoid the vehicle-side 120 requesting a non-existent signal.

[0036] Through the coordinated control of the cloud-based 110 strategy version number and the vehicle-side 120 vehicle version number, differentiated data collection strategies can be distributed for different configurations and software versions of the same vehicle model.

[0037] Please refer to Figure 3 , Figure 3 A flowchart is generated for one of the data acquisition strategies. In some embodiments, the data acquisition strategy includes the data type to be acquired and a priority identifier corresponding to the data type. The step of generating at least one data acquisition strategy includes: S121: Determine the data type to be collected based on the triggering conditions; S122: Based on the data type to be collected, determine the urgency priority and generate a data collection strategy with priority identifier.

[0038] Each trigger rule of the data collection strategy carries a priority identifier (priority field) and is sent to vehicle terminal 120. Vehicle terminal 120 can then make weighted adjustments based on the real-time status. See the following process for generating dynamic priorities of vehicle terminal 120.

[0039] A continuous value from 0 to 100 is used to represent the priority range, with lower values ​​indicating higher priority.

[0040] The specific priorities are shown in the table below:

[0041] In the vehicle data closed-loop system, the cloud-based 110 system simultaneously issues multiple collection strategies (such as multiple trigger rules for different scenarios and data needs), and the vehicle-side 120 system also simultaneously meets multiple trigger conditions. The purpose of using strategy priority control is: Given the limited computing, storage, and bandwidth resources on the vehicle side, priority can be used to determine which collection strategy should be triggered first, which collected data should be processed first, and the types of data to be transmitted back first under limited bandwidth. Ensure that high-value, time-sensitive, and compliant data receive resource allocation, and prevent low-value data from crowding out critical resources such as transmission resources; Cloud-based 110 can optimize data collection and transmission globally by adjusting priority weights.

[0042] In some embodiments, the data acquisition strategy includes road network features, and the step of generating at least one data acquisition strategy includes: Generate differentiated data collection strategies based on road network characteristics.

[0043] Cloud110 can issue differentiated data collection strategies "tailored to local conditions" based on different road network characteristics. Cloud110 mainly uses two methods to configure strategies for different road network characteristics: road network feature tags and geofencing.

[0044] In some embodiments, road network features include geofencing, and a differentiated data collection strategy is generated based on the road network features, including: Based on the boundary determination results of the administrative region, switch to the data collection strategy corresponding to the desensitization level; Based on the geofence of the sensitive area, the data collection strategy is configured to pause collection; Based on the electronic fence of the data open area, the data collection strategy is configured to collect all data.

[0045] The electronic fence here can be drawn on the map by marking points in the cloud, and different data collection strategies can be implemented for each area.

[0046] The table below shows geofencing and its corresponding policy behaviors:

[0047] By leveraging geofencing information from road network features, regionalized data collection strategies can be adapted. The cloud-based 110 system can automatically adjust the content collected and the anonymization level according to different regional regulations, eliminating the need for vehicle-side 120 software upgrades and meeting data export and privacy protection requirements.

[0048] Please refer to Figure 4 , Figure 4 A flowchart illustrating the generation of differentiated data collection strategies based on road network characteristics. In some embodiments, road network characteristics include road network characteristic labels, and generating differentiated data collection strategies based on road network characteristics includes: S123: Obtain the road scene type based on road network feature labels; S124: Generate a data collection strategy based on the road scene type.

[0049] Based on road network feature labels such as road geometry and topology, the system will automatically identify the type of road scene where the vehicle is currently located, and then issue different road network feature label collection strategies.

[0050] The specific network feature labels and policy behaviors are shown in the table below:

[0051] By combining geofencing and road network tags, the system enables proactive detection and collection of dynamic changes based on road network information. When changes occur in the road network (such as construction or repainting of road markings), the dynamic change detection of the high-precision map can immediately trigger the vehicle-mounted 120 system to collect differentiated data, thus achieving a closed loop of "changes are detected and collection strategies are automatically adapted".

[0052] Please refer to Figure 5 , Figure 5 The flowchart for policy distribution control is as follows. Policy distribution modes include two methods: active retrieval and cloud-based push (110). To ensure the vehicle-side 120 collects the latest policies, the vehicle-side 120 reports the vehicle version number and the vehicle-side 120 policy version number to the cloud-based 110 every time it powers on. The cloud-based 110 determines whether the policy version number is the latest version. If it is not the latest version, it re-distributes the latest version of the collection policy to the vehicle-side 120, thus achieving policy version verification.

[0053] In the cloud 110 push mode, when the cloud 110 distributes the policy, it will obtain the list of vehicles with the corresponding policy type and distribute the collection policy of that type to the vehicle terminal 120.

[0054] Unified policy management is implemented in the cloud, supporting fine-grained configuration at the vehicle level (such as using different collection strategies for vehicles of different models and routes), reducing the complexity of the vehicle-side software.

[0055] Please refer to Figure 6 , Figure 6 A flowchart illustrating another vehicle data acquisition method provided in this application. The method includes: S210: Receives data collection strategies sent from the cloud (110); S220: Obtain dynamic priority based on the priority identifier in the data acquisition strategy; S230: Based on the dynamic priority, the data to be collected is collected and transmitted in a hierarchical manner.

[0056] Upon receiving the data acquisition strategy, based on the priority identifier defined in the acquisition strategy and the current resource situation (such as storage space, computing load, network bandwidth, and the degree of duplication of similar data), differentiated acquisition is performed according to different dynamic priorities, thereby improving the efficiency of data acquisition and transmission.

[0057] In some embodiments, obtaining dynamic priority based on the priority identifier in the data acquisition strategy includes: The dynamic priority is obtained based on the priority identifier, remaining storage space, CPU utilization, and data duplication rate of the same type. The remaining storage space is determined based on the remaining storage space, and the data duplication rate of the same type is determined based on the number of times the current vehicle triggers data collection within a set time period.

[0058] An arbitrator can be run on the vehicle side 120 to periodically (e.g., every 1 second) execute the following process: S11: Get the static priority of all currently active policies (Priority identifier in the collection strategy issued by 110 in the cloud). S12: Read the real-time resource status of vehicle terminal 120 to obtain the remaining storage space (currently used / available storage percentage), computing load (CPU utilization), and the degree of duplication of similar data; Storage factors corresponding to different remaining storage space As shown in the table below:

[0059] Weight values ​​corresponding to different CPU utilization rates As shown in the table below:

[0060] Weight values ​​of deduplication factors corresponding to the repetition of similar data As shown in the table below:

[0061] S13: Calculate the dynamic priority for each rule to be decided. : ; in, Indicates static priority. Indicates the storage factor weight value. This represents the weight value corresponding to different CPU utilization rates. This represents the weight value of the deduplication factor.

[0062] S14: Determine whether to trigger and how to collect data based on dynamic priority.

[0063] For tiered data acquisition, for example, the acquisition levels can be divided into three levels based on the magnitude of dynamic priority, as shown in the table below:

[0064] Please refer to Figure 7 , Figure 7 This is a flowchart of cross-domain data acquisition. In some embodiments, the method further includes: S240: Obtain the policy triggering domain and data acquisition domain in the data acquisition strategy; S250: If the policy trigger domain and the data acquisition domain are different, then cross-domain data acquisition is performed.

[0065] The vehicle-side 120 system operates through a combination of multiple domain controllers. Traditional single-domain policy distribution and data collection rely on a single triggering mechanism, making it prone to missing high-value scenarios. In real-world driving scenarios, many high-value corner cases occur precisely when multiple domain anomalies occur simultaneously—such as complex events like "driver distraction + sudden cutting in front + sharp vehicle turn." These cannot be accurately identified using only FCW or single-domain signals, resulting in a significant amount of missed valid data and low collection efficiency.

[0066] The vehicle-side 120 is divided into multiple domain controllers, including intelligent driving domain, cockpit domain, chassis domain, body domain, electronic control domain, and powertrain domain. The vehicle-side 120 pre-defines the domain to which each signal and each acquisition action belongs. The cloud-based 110 configures strategies separately for triggering logic and acquisition logic to distinguish the source domain. When the strategy triggering domain and the acquisition execution domain are not in the same domain, a cross-domain acquisition action is performed. For example, a certain algorithm parameter in the chassis triggers data acquisition; the corresponding acquisition strategy belongs to the chassis domain. After triggering, road condition data is acquired, but this road condition data belongs to the intelligent driving domain.

[0067] Cross-domain data acquisition and control refers to the vehicle-side 120 accessing data from multiple controllers, including the intelligent driving domain, cockpit domain, chassis domain, and body domain, in real time based on the multi-domain joint strategy issued by the cloud 110.

[0068] By dynamically configuring cross-domain joint triggering conditions through cloud-based 110, instead of a fixed threshold in a single dimension, the capture rate of high-value scenarios (especially corner cases) is significantly improved, and invalid collection is reduced.

[0069] Please refer to Figure 8 , Figure 8 This is a flowchart illustrating the specific process of cross-domain data collection. Cross-domain data collection includes the following steps: S251: Receive and parse the data collection strategy issued by 110 in the cloud; The vehicle-side 120 receives the data collection strategy package sent by the cloud 110 through the vehicle-cloud channel, parses the array in the strategy, extracts each rule, stores the parsed rules into the local strategy library, and registers the required signals in the subscription module.

[0070] S252: Multi-domain signal subscription and real-time data stream reception; The signal subscription module initiates subscriptions to each domain controller based on the list of signals required by all activation policies; each domain controller pushes data frames at a fixed frequency, carrying its own hardware timestamp.

[0071] S253: Time alignment and hierarchical data acquisition; The gPTP protocol is used to synchronize the master clock of the intelligent driving domain with the slave clocks of each domain, with an accuracy of nanosecond level. For each set of data frames to be judged, the master clock is used as the reference, and the sample with the timestamp of each domain closest to the master clock time is selected. A data frame with a unified timestamp is generated by linear interpolation. By calculating dynamic priorities, different levels of data collection can be achieved, such as whether data collection is triggered, which domains of data to collect, and which collection level (Level 1 / Level 2 / Level 3) to use.

[0072] Finally, the aligned multi-domain feature vector group is output (e.g., TTC value at the same time point, driver's line-of-sight deviation time, steering wheel angle rate, etc.).

[0073] S254: Data anonymization, packaging, and return.

[0074] By collecting cross-domain data, it breaks through the limitations of traditional "single signal triggering" and uses multi-domain related information to accurately identify high-value complex scenarios; it supports dynamic configuration of cross-domain triggering rules in the cloud to achieve flexible iteration of collection logic; and under the premise of limited computing resources on the vehicle side, it achieves low-latency, low-overhead real-time joint inference and hierarchical collection, thereby improving collection efficiency.

[0075] Please refer to Figure 9 , Figure 9 The structural block diagram of the vehicle data acquisition system provided in this application should be understood to be related to... Figure 1 The method embodiment executed in the middle is capable of performing the steps involved in the aforementioned method. The specific functions of this device can be found in the description above; to avoid repetition, detailed descriptions are appropriately omitted here. The system includes a cloud terminal 110 and a vehicle terminal 120; wherein: The cloud-based 110 is used to generate at least one data collection strategy based on the triggering conditions for data collection, and send the data collection strategy to the vehicle-side 120; wherein, the data collection strategy is dynamically configured based on regulatory requirements, road network characteristics, and / or the vehicle version number. The vehicle terminal 120 is used to obtain dynamic priority based on the priority identifier in the data acquisition strategy, and to perform hierarchical acquisition and transmission of the data to be collected based on the dynamic priority.

[0076] The cloud-based 110 generates a collection strategy by configuring the collection method (triggering, periodic, and one-time), the adaptation version (the strategy version needs to meet regulatory requirements, sensor configuration, etc.), the priority configuration, the road network feature configuration, and the collection range configuration (cross-domain collection), and then distributes it to the vehicle-side 120 through the vehicle-cloud channel.

[0077] The vehicle-side 120 uses a cross-domain acquisition subsystem to collect data from multiple domains and package it into data packets for hierarchical backhaul via dynamic priority. Backhaul methods include merged backhaul and breakpoint resumption. By using edge node caching and merging, and breakpoint resumption, the high-frequency connection requirements for direct backhaul to the central cloud are reduced, lowering traffic costs while ensuring low-latency delivery of critical data.

[0078] This system achieves vehicle data collection based on cloud-based cross-domain strategy configuration, vehicle-side joint triggering and collection, and hierarchical differentiated backhaul. Specifically: the cloud dynamically configures cross-domain collection strategies according to model requirements, regulatory scenarios, and road network characteristics; the vehicle-side achieves accurate triggering of high-value scenarios based on multi-domain collaboration; and the collected data is carried out in a value-driven hierarchical backhaul under vehicle-cloud collaboration, optimizing bandwidth and storage utilization.

[0079] This application provides an electronic device including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the methods in any of the aforementioned optional implementations.

[0080] This application provides a readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the methods in any of the aforementioned optional implementations.

[0081] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0083] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0085] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0087] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or 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 limitations, 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 said element.

Claims

1. A method for acquiring vehicle data, characterized in that, Applied to the cloud, the method includes: Based on the triggering conditions for data acquisition, at least one data acquisition strategy is generated; wherein, the data acquisition strategy is based on regulatory requirements, road network characteristics, and / or, the vehicle version number is dynamically configured. The data acquisition strategy is sent to the vehicle.

2. The vehicle data acquisition method according to claim 1, characterized in that, in, The triggering conditions include the data acquisition method. The steps for generating a data acquisition strategy include: The data collection strategy is generated based on vehicle-side event triggering; The data acquisition strategy is generated based on periodic data collection triggered by a vehicle-side timer. The data acquisition strategy is generated based on a one-time acquisition command.

3. The vehicle data acquisition method according to claim 1, characterized in that, in, The data acquisition strategy includes the data type to be acquired and the priority identifier corresponding to the data type. The step of generating at least one data acquisition strategy includes: The data type to be collected is determined based on the triggering conditions; Based on the data type to be collected, determine the urgency priority and generate a data collection strategy with priority identifiers.

4. The vehicle data acquisition method according to claim 1, characterized in that, in, The data acquisition strategy includes road network characteristics. The step of generating at least one data acquisition strategy includes: Generate differentiated data collection strategies based on road network characteristics.

5. The vehicle data acquisition method according to claim 4, characterized in that, in, The road network features include geofencing. The differentiated data collection strategy based on road network characteristics includes: Based on the boundary determination results of the administrative region, switch to the data collection strategy corresponding to the desensitization level; Based on the geofence of the sensitive area, the data collection strategy is configured to pause collection; Based on the electronic fence of the data open area, the data collection strategy is configured to collect all data.

6. The vehicle data acquisition method according to claim 4, characterized in that, in, The road network features include road network feature labels. The differentiated data collection strategy based on road network characteristics includes: Based on the road network feature labels, the road scene type is obtained; A data collection strategy is generated based on the road scene type.

7. A method for acquiring vehicle data, characterized in that, Applied to the vehicle end, the method includes: Receive data collection strategies sent from the cloud; Dynamic priority is obtained based on the priority identifier in the data acquisition strategy; Based on the dynamic priority, the data to be collected is collected and transmitted in a hierarchical manner.

8. The vehicle data acquisition method according to claim 7, characterized in that, The process of obtaining dynamic priority based on the priority identifier in the data acquisition strategy includes: The dynamic priority is obtained based on the priority identifier, remaining storage space, CPU utilization, and data duplication rate of the same type. The remaining storage space is determined based on the remaining storage space, and the data duplication rate of the same type is determined based on the number of times the current vehicle triggers data collection within a set time period.

9. The vehicle data acquisition method according to claim 7, characterized in that, The method further includes: Obtain the policy trigger domain and data acquisition domain from the data acquisition strategy; If the policy trigger domain and the data acquisition domain are different, cross-domain data acquisition will be performed.

10. A vehicle data acquisition system, characterized in that, The system includes: cloud and vehicle terminals; The cloud is used to generate at least one data collection strategy based on the triggering conditions for data collection, and send the data collection strategy to the vehicle; wherein, the data collection strategy is dynamically configured based on regulatory requirements, road network characteristics, and / or the vehicle version number; The vehicle-mounted device is used to obtain a dynamic priority based on the priority identifier in the data acquisition strategy, and to perform hierarchical acquisition and transmission of the data to be collected based on the dynamic priority.

Images