Data burying point acquisition system and method for cross-brand vehicle models

Abstract

The invention provides a data burying point acquisition system and method for cross-brand vehicle models, and belongs to the technical field of vehicle data acquisition. Comprising a middleware adaptation layer, a data management layer, a data acquisition layer and a cloud platform module, wherein the middleware adaptation layer can execute adaptation operation of vehicle model data sources of different brands. When the middleware adaptation layer receives the CAN message, loading a corresponding brand plug-in to carry out analysis and data conversion on the CAN message, directly caching and filtering the CAN message, and uploading the CAN message to the cloud; when the middleware adaptation layer receives the product data, a corresponding brand plug-in is loaded, and the product data is uploaded to the data management layer for data mapping; after data mapping is completed, data conversion, caching and filtering are carried out, and the data are uploaded to the cloud. The method can be widely compatible with burying point acquisition schemes of different brands of vehicle models, so as to improve the universality, expandability and efficiency of data acquisition.

Description

Technical Field

[0001] This invention belongs to the field of vehicle data acquisition technology, and in particular relates to a data collection system and method for cross-brand vehicle models. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] With the rapid development of intelligent connected vehicles, the functions of the car cockpit are becoming increasingly diversified. Efficient and unified collection and analysis of multi-source heterogeneous data generated within the cockpit has become crucial for optimizing user experience, realizing personalized services, and iterating products.

[0004] However, when collecting automotive cockpit data, especially in large-scale applications involving multiple brands and models, existing technical solutions generally face the following prominent bottlenecks: (1) The CAN protocol, sensor interface and data format of different car manufacturers are very different and lack unified data rules, which leads to a lot of customized development required for the data acquisition process, which is not only inefficient but also increases development costs.

[0005] (2) User behavior data, vehicle status data, control command data, etc. of different brands of vehicles need to be processed differently, but most existing solutions use fixed frequency collection, which cannot meet the dynamic business needs of multiple brands. Summary of the Invention

[0006] To overcome the shortcomings of the prior art, the present invention provides a data collection system and method for cross-brand vehicle models, which can be widely compatible with data collection schemes of different brand vehicles, so as to improve the universality, scalability and efficiency of data collection.

[0007] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: The first aspect of this invention provides a data collection system for cross-brand vehicle models.

[0008] A data tracking system for cross-brand vehicle models includes: a middleware adaptation layer, a data management layer, a data filtering layer, and a cloud platform module; The middleware adaptation layer is used to perform adaptation operations for different vehicle model data sources based on the received vehicle system data: When the middleware adaptation layer receives a CAN message from the vehicle's infotainment system, it parses and converts the CAN message by loading the corresponding brand plugin, then converts it again by the unit conversion module, and directly uploads the converted standard data to the data filtering layer. The data filtering layer is used to cache and filter the obtained standard data and upload it to the cloud platform module. When the middleware adaptation layer receives data from the vehicle system that does not require parsing (i.e., unparsed data), it loads the corresponding brand plugin and uploads the data to the data management layer for data mapping. Then, it performs data transformation on the mapped data, converting it into the unit uniformly specified by the system, and uploads the transformed standard data to the data filtering layer. After being cached and filtered by the data filtering layer, it is then uploaded to the cloud platform module.

[0009] Furthermore, the middleware adaptation layer includes: an interface adaptation module, a plugin management module, and a brand plugin module; wherein, the interface adaptation module is used to provide a unified data access interface, the plugin management module is used to dynamically load and manage brand plugins, and the brand plugin module includes multiple brand-specific plugins for parsing and mapping brand-specific data.

[0010] Furthermore, the plugin management module enables hot-swapping of brand plugins through class loaders and reflection mechanisms; it identifies brands based on vehicle identifiers and dynamically loads corresponding brand plugins to convert brand-specific data into standard data, thereby achieving unified collection of cross-brand data points.

[0011] Furthermore, the data management layer includes: a data modeling module, a unit conversion module, and a data synchronization module; wherein, the data modeling module is used to perform multi-dimensional modeling of product data and CAN messages and establish cross-dimensional association rules, the unit conversion module is used to manage the conversion of data units, and the data synchronization module is used to synchronize configuration and data changes with the cloud platform module.

[0012] Furthermore, the multidimensional modeling of the data modeling module supports expansion to 256 dimensions, including: The product uses data dimensions to model user interaction events and application startup records; The vehicle infotainment system's environmental data dimension is used to model CPU temperature, memory usage, and power supply voltage. CAN message data dimensions are used to model vehicle speed, tire pressure, and fault codes.

[0013] Furthermore, the data filtering layer includes: a data caching module, a filtering algorithm module, and a data uploading module; wherein, the data caching module is used to temporarily store the collected data, the filtering algorithm module is used to filter the data according to filtering rules, and the data uploading module is used to compress the filtered data and upload it to the cloud platform module.

[0014] Furthermore, the cloud platform module includes: a configuration management module, a data storage module, and a data analysis module; wherein, the configuration management module is used to issue configuration updates to update brand plugins and data fields; the data storage module is used to store uploaded data; and the data analysis module is used to perform visualization analysis and big data analysis on the data.

[0015] The second aspect of this invention provides a method for collecting data points across different vehicle brands.

[0016] A method for collecting data tracking points across vehicle brands includes: Configuration commands are issued via the cloud platform module, including updating brand plugins, adjusting data fields, and modifying filtering strategies. Based on the received vehicle system data, perform adaptation operations for different brand and vehicle model data sources. Specifically: When a CAN message is received from the vehicle's infotainment system, the corresponding brand plugin is loaded to parse and convert the CAN message. The converted standard data is then cached, filtered, and uploaded to the cloud platform module. When receiving data from the vehicle's infotainment system that does not require parsing, the system loads the corresponding brand plugin and maps the product data. After the data mapping is completed, the system performs data transformation, caches and filters the transformed standard data, and then uploads it to the cloud platform module. Furthermore, the non-parsed data includes product usage data and vehicle environment data.

[0017] Furthermore, the loading of the brand plugin includes: scanning the plugin directory when the system starts; subsequently, parsing the plugin configuration file and loading the class file; finally, instantiating the plugin and registering the plugin to the middleware adaptation layer.

[0018] The above one or more technical solutions have the following beneficial effects: (1) The data collection system provided by this invention includes a middleware adaptation layer, a data management layer, a data filtering layer, and a cloud platform module that work together. The middleware adaptation layer is used to perform adaptation operations for different brand and model data sources based on the received vehicle data. By designing the middleware adaptation layer and adopting a modular plug-in mechanism, brand-specific logic is encapsulated into independent plug-ins. Through a unified interface adaptation and dynamic loading mechanism, "one-time development, multi-brand adaptation" is achieved. This architecture shields the differences in underlying hardware and protocols, greatly reduces the workload of customized development for different brand and model vehicles, and significantly improves the universality, scalability, and development efficiency of data collection.

[0019] (2) This invention introduces a configurable data collection and filtering algorithm module in the data filtering layer, and combines it with a cloud-based configuration management module to support dynamic adjustment of the data collection strategy according to business needs. By issuing configuration commands, the data collection strategy can be flexibly adapted, meeting the differentiated and adaptive data collection needs of multi-source heterogeneous data such as user behavior data, vehicle status data, and control command data, and improving the system's business adaptability and the level of intelligent data collection in multi-brand scenarios.

[0020] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0021] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0022] Figure 1 This is a modular structure diagram of the data embedding and acquisition system in Embodiment 1 of the present invention.

[0023] Figure 2 This is a flowchart of the data reporting timing of the data embedding acquisition system in Embodiment 1 of the present invention.

[0024] Figure 3 This is a flowchart of the plugin registration and loading process in Embodiment 1 of the present invention.

[0025] Figure 4 This is a flowchart of the configuration update in Embodiment 1 of the present invention. Detailed Implementation

[0026] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, 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 invention pertains.

[0027] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0028] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0029] Example 1 This embodiment discloses a data collection system for cross-brand vehicle models.

[0030] A data tracking system for cross-brand vehicle models includes: a middleware adaptation layer, a data management layer, a data filtering layer, and a cloud platform module; The middleware adaptation layer is used to perform adaptation operations for different brand and vehicle model data sources based on the received vehicle system data: When the middleware adaptation layer receives a CAN message from the vehicle's infotainment system, it parses and converts the CAN message by loading the corresponding brand plugin, and then directly uploads the converted standard data to the data filtering layer. The data filtering layer is used to cache and filter the obtained standard data and upload it to the cloud platform module. When the middleware adaptation layer receives unparsed data from the vehicle's infotainment system, it loads the corresponding brand plugin and uploads the data to the data management layer for data mapping. After the data mapping is completed, the data is transformed, and the transformed standard data is uploaded to the data filtering layer. After being cached and filtered by the data filtering layer, the data is then uploaded to the cloud platform module.

[0031] Based on the above systematic design, this invention is widely compatible with data collection schemes for different car brands, thereby improving the universality, scalability, and efficiency of data collection. To facilitate understanding of the technical solution of this invention, the specific implementation methods are further explained and described below.

[0032] like Figure 1 As shown, a data collection system for cross-brand vehicle models includes: a middleware adaptation layer, a data management layer, a data filtering layer, and a cloud platform module.

[0033] 1) Middleware adaptation layer (adapts to data reporting for different car models and brands).

[0034] The middleware adaptation layer, through a modular plug-in mechanism, can shield the hardware and protocol differences between different brand and vehicle models, achieving "develop once, adapt to multiple brands." The core design principles of this layer are: standardized interfaces + dynamic loading (hot updates, new plug-ins do not require device restarts) + separation of responsibilities. Brand-specific logic is encapsulated as independent plug-ins, uniformly scheduled through the middleware adaptation layer. Specifically, the middleware adaptation layer includes: an interface adaptation module, a plug-in management module, and a brand plug-in module.

[0035] 1.1) Interface adapter module, used to provide a unified data access interface, such as obtaining vehicle speed, battery status, etc.

[0036] 1.2) Plugin management module, used for dynamically loading and managing brand plugins.

[0037] The plugin management module comprises two core functions: plugin management and data routing. Plugin management involves defining basic functional plugin interfaces, data conversion interfaces, and protocol parsing interfaces such as CAN signals for lower-level plugins to implement. Data routing automatically matches the corresponding brand plugin based on the data source.

[0038] 1.3) The Brand Plugins module includes multiple brand-specific plugins for parsing and transforming brand-specific data.

[0039] In the brand plugin module, each brand only needs to implement its own adaptation plugin to add brand-specific logic through dynamic loading. Specifically, the plugin management module enables hot-swapping of brand plugins through class loaders and reflection mechanisms; it identifies brands based on vehicle identifiers and dynamically loads the corresponding brand plugins to convert brand-specific data into standard data, achieving unified collection of cross-brand data tracking points.

[0040] In the specific implementation process, the following method can be used: First, identify the brand based on the vehicle's VIN code; then, load the corresponding brand's protocol parsing adapter and data conversion adapter from the plugin repository; next, call the corresponding protocol parsing adapter to parse the CAN message data into raw data; finally, use the data conversion adapter to convert the unique identifier code corresponding to these raw data into a unique identifier code after unified modeling by the platform, that is, to standardize the data ID. Finally, the unit conversion module of the data management layer will uniformly convert the data unit to the unit specified by the platform, that is, to standardize the data unit. At this point, the data has completed the standardization conversion and can be transmitted to the cloud for analysis through the data filtering layer.

[0041] The hot-swappable plugin steps include: First, placing the plugin: placing the plugin APK in the specified location; Second, loading the plugin: loading the APK using DexClassLoader; Third, creating an instance: creating an object of the plugin class using reflection; Fourth, mapping resources: creating a Resources object that can access the plugin resources using reflection; Fifth, proxy execution: starting and running the plugin component through a proxy component (service, activity, etc.), and completing specific business functions by calling its lifecycle through reflection.

[0042] The unified data collection process includes: First, parsing data based on different CAN message parsing protocols according to the corresponding brand's CAN message parsing protocol; second, converting the unique identifiers corresponding to different functions to the unique identifiers specified after unified modeling on the platform, and categorizing the data according to the platform's unique identifiers; third, converting the data to the units specified by the platform through the unit conversion module according to the data units corresponding to different brands. Data processed through these three steps becomes standardized data.

[0043] 2) Data management layer.

[0044] The data management layer includes a data modeling module, a unit conversion module, and a data synchronization module. The data modeling module performs multi-dimensional modeling on product data and CAN message data, establishing cross-dimensional association rules (linking different dimensions of data by building tags or aliases). The unit conversion module converts different units under the same ID into platform-specified units. The data synchronization module synchronizes configurations and data changes with the cloud platform module. Specifically, each data entry must contain two pieces of information: an information point ID (stored as a long integer) and a value (a string type, supporting complex formats such as JSON). The information point ID occupies 64 bits, with the first eight bits corresponding to dimension information: it can contain a maximum of 256 dimensions, where 0 corresponds to component signals, 1 corresponds to cockpit product embedded data, 2 corresponds to sales data, etc. The last 56 bits can be further categorized and hierarchically labeled according to the characteristics of each dimension, such as first-level, second-level, and third-level. For example, in cockpit product data tracking, bits 8 to 16 correspond to the app category, bits 17 to 22 correspond to the app's first-level functional category, and bits 23 to 63 indicate the specific ID value. Data from different dimensions are further linked by labeling (giving data aliases) to establish interrelation rules (for example, the "battery health" label associates multiple signal IDs of component signals with the battery health tracking point in the product function tracking). Due to redundancy reserves for each bit, expansion for different dimensions can support up to 256 dimensions, and data IDs can be expanded up to powers of 2. Data field expansion and change information are all stored in the cloud; the client only needs to synchronize the rule definition and report according to the rules.

[0045] 3) Data filtering layer.

[0046] The data filtering layer includes a data caching module, a filtering algorithm module, and a data upload module. The data caching module is used to temporarily store the collected data, the filtering algorithm module is used to filter the data according to filtering rules, and the data upload module is used to compress the filtered data and upload it to the cloud platform module.

[0047] In actual filtering, data can be filtered according to different filtering rules: for example, filtering data at different frequencies, keeping only the first data within 1 second and filtering out the rest, or taking only the data within the first second every ten seconds and filtering out the rest.

[0048] 4) Cloud platform module.

[0049] The cloud platform module includes a configuration management module, a data storage module, and a data analysis module. The configuration management module is used to issue configuration updates to update brand plugins and data fields. The data storage module is used to store uploaded data, and the data analysis module is used to perform visualization analysis and big data analysis on the data.

[0050] When issuing specific configuration updates, they can be sent to the vehicle application via HTTP or MQTT. Different model algorithms can be selected for big data analysis and visualization analysis depending on the specific business, such as using a driver health model to perform health analysis and monitoring of drivers.

[0051] like Figure 2 As shown, when the middleware adaptation layer performs adaptation operations for different brand and vehicle model data sources based on the received vehicle system data, the data reporting sequence is as follows: When the middleware adaptation layer receives a CAN message from the vehicle's infotainment system, it parses and converts the CAN message by loading the corresponding brand plugin, and uploads the converted standard data to the data filtering layer through the unit conversion module. The data filtering layer is used to cache and filter the obtained standard data and then upload it to the cloud platform module. When the middleware adaptation layer receives unparsed data from the vehicle's infotainment system, it loads the corresponding brand plugin and uploads the data to the data management layer for data conversion (establishing a one-to-one correspondence or mutual conversion relationship between data fields with different names corresponding to the same function); after the data conversion is completed, the data is converted by the unit conversion module and then uploaded to the data filtering layer; after being cached and filtered by the data filtering layer, it is then uploaded to the cloud platform module.

[0052] To enable the middleware adaptation layer to load plugins from different brands, the following methods can be used: The first step is to define the brand-compatible SDK. First, define the interface templates, including standardized interfaces such as basic function plugin interfaces, data conversion interfaces, and CAN signal parsing interfaces. Then, provide a reference implementation and package the SDK. Finally, deliver it to the brand manufacturer for development and adaptation.

[0053] The second step is to develop brand plugins. This involves obtaining relevant SDK development documentation and protocol documentation, implementing the relevant plugin interfaces (including data conversion plugins, CAN signal protocol parsing plugins, etc.), and finally conducting integration testing.

[0054] The third step is plugin registration and loading. The developed brand plugin is integrated into the system's designated path. Upon system startup, it will scan and load the corresponding class files. For example... Figure 3 As shown, the plugin registration and loading process is as follows: system startup, scanning the plugin directory, parsing the configuration file, loading the class file, instantiating the plugin, and registering it to the middleware.

[0055] like Figure 4 As shown, the overall process of downloading plugins and parameters from the cloud and updating their configuration includes: cloud management platform - data synchronization module - parsing configuration instructions - determining configuration type (updating filtering algorithms, adjusting collection fields, plugin configuration) - if it is a plugin configuration, downloading and updating the new plugin - loading class files - instantiating the plugin - registering it to the middleware module - completing the function execution. The specific steps are as follows: 1) Receive cloud instructions: The data synchronization module obtains and verifies the signed configuration update instructions from the cloud; 2) Parse and route: Parse the instructions and route them to different processing logics according to the configuration type field; 3) Download resources: If it is a plugin configuration, download the new version of the plugin package to the local machine from the link in the instructions and verify the file integrity; 4) Create class loader: Create a class loader for the new plugin JAR file; 5) Instantiate plugin: Load the plugin entry class through the new class loader and create an instance of its implementation class through reflection; 6) Register service: Call the plugin's initialization method and register its instance with middleware (such as event bus, filter chain); 7) Hot switch: After registration is completed, new business requests / data will be automatically processed by the new plugin instance to achieve smooth hot update; 8) Status reporting: Report the success or failure status of this configuration update operation to the cloud to complete the entire process.

[0056] Example 2 This embodiment discloses a method for collecting data points across different vehicle brands.

[0057] A method for collecting data tracking points across vehicle brands includes: Configuration commands are issued via the cloud platform module, including updating brand plugins, adjusting data fields, and modifying collection strategies. Based on the received vehicle system data, perform adaptation operations for different brand and vehicle model data sources. Specifically: When a CAN message is received from the vehicle's infotainment system, the system parses and converts the CAN message by loading the corresponding brand plugin, then performs a conversion based on the unit conversion module, caches and filters the converted standard data, and uploads it to the cloud platform module. When receiving unparsed data from the vehicle's infotainment system, the corresponding brand plugin is loaded and the data is converted. After the data conversion is completed, the data is further converted based on the unit conversion module. The converted standard data is then cached, filtered, and uploaded to the cloud platform module. Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0058] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A data collection system for cross-brand vehicle models, characterized in that, include: Middleware adaptation layer, data management layer, data filtering layer, and cloud platform module; The middleware adaptation layer is used to perform adaptation operations for different brand and vehicle model data sources based on the received vehicle system data: When the middleware adaptation layer receives a CAN message from the vehicle's infotainment system, it parses and converts the CAN message by loading the corresponding brand plugin, then converts it again by the unit conversion module, and uploads the converted standard data to the data filtering layer. The data filtering layer is used to cache and filter the obtained standard data and upload it to the cloud platform module. When the middleware adaptation layer receives unparsed data from the vehicle system, it loads the corresponding brand plugin and uploads the data to the data management layer for data mapping. After the data mapping is completed, the data is converted by the unit conversion module, and then the converted standard data is uploaded to the data filtering layer. After being cached and filtered by the data filtering layer, it is uploaded to the cloud platform module.

2. The data collection system for cross-brand vehicle models as described in claim 1, characterized in that, The middleware adaptation layer includes: an interface adaptation module, a plugin management module, and a brand plugin module; wherein, the interface adaptation module is used to provide a unified data access interface, the plugin management module is used to dynamically load and manage brand plugins, and the brand plugin module includes multiple brand-specific plugins for parsing and transforming brand-specific data.

3. A data collection system for cross-brand vehicle models as described in claim 2, characterized in that, The plugin management module enables hot-swapping of brand plugins through class loaders and reflection mechanisms; it identifies brands based on vehicle identifiers and dynamically loads corresponding brand plugins to convert brand-specific data into standard data, thereby achieving unified collection of cross-brand data points.

4. A data collection system for cross-brand vehicle models as described in claim 1, characterized in that, The data management layer includes: a data modeling module, a unit conversion module, and a data synchronization module; wherein, the data modeling module is used to perform multidimensional modeling on data of different dimensions and establish cross-dimensional association rules, the unit conversion module is used to uniformly convert data of the same field with different units into the platform-specified unit, and the data synchronization module is used to synchronize configuration and data changes with the cloud platform module.

5. A data collection system for cross-brand vehicle models as described in claim 4, characterized in that, The multidimensional modeling of the data modeling module includes: The product uses data dimensions to model user interaction events and application startup records; The vehicle infotainment system's environmental data dimension is used to model CPU temperature, memory usage, and power supply voltage. CAN message data dimensions are used to model vehicle speed, tire pressure, and fault codes.

6. A data collection system for cross-brand vehicle models as described in claim 1, characterized in that, The data filtering layer includes: a data caching module, a filtering algorithm module, and a data uploading module; wherein, the data caching module is used to temporarily store the collected data, the filtering algorithm module is used to filter the data according to filtering rules, and the data uploading module is used to compress the filtered data and upload it to the cloud platform module.

7. A data collection system for cross-brand vehicle models as described in claim 1, characterized in that, The cloud platform module includes: a configuration management module, a data storage module, and a data analysis module; wherein, the configuration management module is used to issue configuration updates to update brand plugins and data fields; the data storage module is used to store uploaded data; and the data analysis module is used to perform visualization analysis and big data analysis on the data.

8. A method for data collection and tracking across vehicle brands, used in the data collection and tracking system as described in any one of claims 1-7, characterized in that, include: Configuration commands are issued via the cloud platform module, including updating brand plugins, adjusting data fields, and modifying collection strategies. Based on the received vehicle system data, perform adaptation operations for different brand and vehicle model data sources. Specifically: When a CAN message is received from the vehicle's infotainment system, the corresponding brand plugin is loaded to parse and convert the CAN message. The data is then converted by the unit conversion module, and the converted standard data is cached, filtered, and uploaded to the cloud platform module. When receiving unparsed data from the vehicle's infotainment system, the corresponding brand plugin is loaded and the data is mapped. After the data mapping is completed, the data is converted based on the unit conversion module, and the converted standard data is cached, filtered, and then uploaded to the cloud platform module.

9. A data collection method for cross-brand vehicle models as described in claim 8, characterized in that, The non-parsed data includes product usage data and vehicle environment data.

10. A data collection method for cross-brand vehicle models as described in claim 8, characterized in that, The loading of the brand plugin includes: scanning the plugin directory when the system starts; then parsing the plugin configuration file and loading the class file; finally, instantiating the plugin and registering the plugin to the middleware adaptation layer.

Images