Internet of vehicles data warehouse method and device, electronic equipment and storage medium

Abstract

The invention discloses an Internet of Vehicles data warehouse method and device, electronic equipment and a storage medium, and relates to the field of data processing, and the method comprises a data carding step, a data scene analysis step, a data application demand analysis step, a data set warehouse architecture design step and a data warehouse development step. Wherein the data sorting step comprises the following steps of: determining data stored in a data warehouse; the data scene analysis comprises the following steps: determining a subject domain to which data belongs; the data application demand analysis comprises the following steps: determining various indexes; the data set warehouse architecture design comprises the following steps: defining hierarchical division of a data warehouse; the data warehouse development step comprises designing a full-link data calculation process. According to the scheme, the problem of data islands formed by scattered storage of Internet of Vehicles data and the problem of resource waste caused by repeated calculation of indexes in different business scenes are solved. Unified data acquisition, cleaning and management are realized, and centralized calculation and sharing multiplexing of general indexes are realized.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to methods, devices, electronic equipment, storage media, and computing platforms for vehicle-to-everything (V2X) data warehouses. Background Technology

[0002] With the rapid development of information technology, automotive companies are increasingly demanding big data analytics. By deeply mining vehicle, road, and user data, they can leverage core value across multiple dimensions, including safety enhancement, user experience, and business operations. However, the use of connected vehicle data faces two major technical bottlenecks: First, millions of vehicles generate over 3TB of data daily, which is scattered across different systems, leading to low retrieval efficiency and severely restricting analytical efficiency. Second, common metrics across various business scenarios, such as average daily fuel consumption and average speed, are frequently calculated repeatedly, resulting in significant resource waste and cost redundancy. Reducing the time developers spend retrieving data and minimizing resource consumption are key challenges facing these companies.

[0003] To address the aforementioned issues, this invention provides a design for a vehicle-to-everything (V2X) data warehouse. This method starts with the core business scenarios and operational strategies of V2X, determines the scope of data to be accessed in the data warehouse, and eliminates data redundancy through centralized storage and standardized management. Based on business objectives, it constructs a subject domain division and indicator system, logically decoupling the data processing flow into multiple levels, and using automatic scheduling tools to achieve timed automated calculation of data at each level. This improves data analysis efficiency and helps enterprises efficiently unlock the potential value of V2X data.

[0004] By designing a vehicle-to-everything (V2X) data warehouse, we can solve the problem of data silos caused by scattered storage of V2X data, as well as the resource waste caused by repeated calculation of indicators in different business scenarios. We can achieve unified data collection, cleaning, and management, enabling centralized calculation and shared reuse of common indicators, thereby improving data processing efficiency and reducing resource consumption. Summary of the Invention

[0005] The purpose of this invention is to provide a method, device, electronic equipment, storage medium and computing platform for a vehicle-to-everything (V2X) data warehouse, which at least solves the problem of data silos caused by the scattered storage of V2X data and the problem of resource waste caused by repeated calculation of indicators in different business scenarios.

[0006] This invention provides the following solution:

[0007] According to a first aspect of the present invention, a method for a vehicle-to-everything (V2X) data warehouse is provided, the method comprising: a data sorting step, a data scenario analysis step, a data application requirement analysis step, a dataset warehouse architecture design step, and a data warehouse development step;

[0008] in,

[0009] The steps of data processing include determining the data to be stored in the data warehouse;

[0010] The steps in data scenario analysis include determining the subject area to which the data belongs;

[0011] The steps in data application requirements analysis include identifying various indicators;

[0012] The steps in designing a dataset warehouse architecture include: clearly defining the data warehouse hierarchy;

[0013] The steps involved in developing a data warehouse include designing a complete data computation process.

[0014] Further steps in data processing include:

[0015] To obtain the business needs and operational strategies of the Internet of Vehicles (IoV);

[0016] Based on business needs and operational strategies, select the data that needs to be stored in the data warehouse;

[0017] Based on the data that needs to be stored in the data warehouse, determine the data to be stored in the data warehouse;

[0018] This includes classifying the data to be stored in the data warehouse by type and format;

[0019] Based on the classification of type and format, match the corresponding access method for the vehicle network;

[0020] Based on the data to be stored in the data warehouse and the corresponding access method, the raw data of the data warehouse is constructed.

[0021] Furthermore, the steps in data scenario analysis also include:

[0022] Pre-plan the data application functions of the data warehouse;

[0023] Based on data application functions as the dividing dimension, a hierarchical vehicle-to-everything (V2X) theme domain system is constructed;

[0024] Obtain relevant information about data application functions;

[0025] Based on the correlation of data application functions, data is aggregated into a unified theme;

[0026] Among these, a primary subject area is established as the initial scope;

[0027] Based on establishing a primary subject area as the initial scope, subdivide its sub-topics;

[0028] Each subject area defines metadata information.

[0029] Furthermore, the steps in data application requirements analysis also include:

[0030] Pre-plan the scope of data application for the data warehouse;

[0031] The design of the vehicle-to-everything (V2X) indicator system is based on the scope of data application.

[0032] The primary classification is determined based on vehicle-related, user-related, and behavior-related information.

[0033] Based on the primary classification, the secondary, tertiary and quaternary classifications are developed sequentially.

[0034] The indicators are designed based on a four-level classification.

[0035] Furthermore, the steps in designing a dataset warehouse architecture also include:

[0036] Acquire and organize the characteristic information of vehicle network data;

[0037] Based on the characteristics of vehicle-to-everything (V2X) data and business needs, the V2X data warehouse is divided into five levels;

[0038] The five layers include: data preparation layer, data detail layer, data service layer, data application layer, and dimensional data layer.

[0039] in,

[0040] Design a data preparation layer to provide a data foundation for upper-level data cleaning and processing;

[0041] Design a data detail layer as an isolation layer between the business layer and the data warehouse;

[0042] Design a data service layer to realize the aggregation and analysis of subject domain data;

[0043] Design a dimensional data layer to provide multi-dimensional descriptions for subject domain data;

[0044] Design a data application layer to support specific business scenarios.

[0045] Furthermore, the steps in data warehouse development also include:

[0046] Based on the steps of dataset warehouse architecture design, the vehicle network data warehouse is layered, and the full-link data computing process is designed.

[0047] Specifically, a task scheduler is deployed to handle ETL and metric calculation tasks in the data warehouse and the dependencies between tasks, enabling automated scheduling and retrying in case of failure.

[0048] According to a second aspect of the present invention, a vehicle-to-everything (V2X) data warehouse device is provided, the V2X data warehouse device comprising: a data sorting module, a data scenario analysis module, a data application requirement analysis module, a dataset warehouse architecture design module, and a data warehouse development module;

[0049] in,

[0050] The data sorting module is used to determine the data to be stored in the data warehouse;

[0051] The data scenario analysis module is used to determine the subject area to which the data belongs;

[0052] The data application requirements analysis module is used to determine various indicators;

[0053] The module for dataset warehouse architecture design is used to define the hierarchical division of the data warehouse;

[0054] The data warehouse development module is used to design the entire data computation process.

[0055] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0056] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the steps of the vehicle-to-everything (V2X) data warehouse method.

[0057] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle network data warehouse method.

[0058] According to a fifth aspect of the present invention, a computing platform is provided, comprising:

[0059] An electronic device for implementing the steps of the vehicle-to-everything (V2X) data warehouse method;

[0060] The processor runs a program that, when running, executes the steps of the vehicle-to-everything (V2X) data warehouse method from data output by the electronic device.

[0061] A storage medium for storing a program that, when running, executes the steps of the vehicle-to-everything (V2X) data warehouse method on data output from an electronic device.

[0062] The above solution achieves the following beneficial technical effects:

[0063] This application starts from the core business scenarios and operation strategies of the Internet of Vehicles, determines the scope of data access for the data warehouse, and eliminates data redundancy through centralized storage and standardized management.

[0064] This application constructs a subject domain division and indicator system based on business objectives, logically decouples the data processing flow into multiple levels, and uses automatic scheduling tools to realize the timed automatic calculation of data at each level, thereby improving data analysis efficiency. Attached Figure Description

[0065] Figure 1 This is a flowchart of a vehicle network data warehouse method provided by one or more embodiments of the present invention.

[0066] Figure 2 This is a structural diagram of a vehicle network data warehouse device provided in one or more embodiments of the present invention.

[0067] Figure 3 This is a schematic diagram of the design process of a vehicle network data warehouse provided in a specific embodiment of the present invention.

[0068] Figure 4 This is a schematic diagram of the vehicle network data warehouse hierarchy architecture provided in a specific embodiment of the present invention.

[0069] Figure 5 This is a block diagram of an electronic device structure for a vehicle network data warehouse method provided in one or more embodiments of the present invention. Detailed Implementation

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

[0071] Figure 1 This is a flowchart of a vehicle network data warehouse method provided by one or more embodiments of the present invention.

[0072] like Figure 1 The illustrated vehicle-to-everything (V2X) data warehouse method includes the following steps: data sorting, data scenario analysis, data application requirements analysis, dataset warehouse architecture design, and data warehouse development.

[0073] in,

[0074] The steps of data processing include determining the data to be stored in the data warehouse;

[0075] The steps in data scenario analysis include determining the data subject domain;

[0076] The steps in data application requirements analysis include identifying various indicators;

[0077] The steps in designing a dataset warehouse architecture include: clearly defining the data warehouse hierarchy;

[0078] The steps involved in developing a data warehouse include designing a complete data computation process.

[0079] Specifically, in one particular embodiment, such as Figure 3 The illustrated design process for a vehicle-to-everything (V2X) data warehouse involves determining the data in the data warehouse, identifying the subject domains to which each data belongs, defining various indicators, clarifying the hierarchical division of the data warehouse, and then designing the entire data computation process.

[0080] In this embodiment, the data sorting step further includes:

[0081] To obtain the business needs and operational strategies of the Internet of Vehicles (IoV);

[0082] Based on business needs and operational strategies, select the data that needs to be stored in the data warehouse;

[0083] Based on the data that needs to be stored in the data warehouse, determine the data to be stored in the data warehouse;

[0084] This includes classifying the data to be stored in the data warehouse by type and format;

[0085] Based on the classification of type and format, match the corresponding access method for the vehicle network;

[0086] Based on the data to be stored in the data warehouse and the corresponding access method, the raw data of the data warehouse is constructed.

[0087] Specifically, based on business needs and operational strategies, data that needs to be stored in the data warehouse is selected and determined. Then, according to the differences in data types and formats, the corresponding access methods are matched to construct the raw data of the data warehouse.

[0088] In one specific embodiment, common sources of vehicle-to-everything (V2X) data include vehicle operation data and third-party interface data. Vehicle operation data includes real-time operating condition data collected by sensors such as those for the engine, transmission, and tire pressure; standardized diagnostic information such as vehicle fault codes, emissions data, and mileage; and real-time location, speed, and driving trajectory data from the positioning system. This type of data has high real-time requirements in business needs; therefore, real-time stream processing access can be achieved by using Flink to read the Kafka message queue at the gateway.

[0089] Third-party interface data refers to non-vehicle terminal native data obtained through integration with external systems, including manufacturing system data, road and environmental data, and after-sales maintenance system data. This type of data does not have high real-time requirements and is typically updated daily or weekly; therefore, Spark is used to enable batch processing and access.

[0090] In this embodiment, the data scenario analysis steps further include:

[0091] Pre-plan the data application functions of the data warehouse;

[0092] Based on data application functions as the dividing dimension, a hierarchical vehicle-to-everything (V2X) theme domain system is constructed;

[0093] Obtain relevant information about data application functions;

[0094] Based on the correlation of data application functions, data is aggregated into a unified theme;

[0095] Among these, a primary subject area is established as the initial scope;

[0096] Based on establishing a primary subject area as the initial scope, subdivide its sub-topics;

[0097] Each subject area defines metadata information.

[0098] Specifically, a hierarchical vehicle-to-everything (V2X) theme domain system is constructed based on application functions, grouping functionally related modules into a unified theme. First, a primary theme domain is established as the initial scope, and then further subdivided layer by layer. The names of sub-theme domains, hierarchical structure, and the number of themes at each level are clearly defined. Simultaneously, metadata information such as theme description, module composition, data source, and update frequency is defined for each theme domain.

[0099] In one specific embodiment, based on the widespread application scenarios of vehicle-to-everything (V2X) data in automakers' full lifecycle management and user services, the primary subject domain can be systematically divided into six major areas: planning, R&D, manufacturing, marketing, quality assurance, and service. Specifically, the planning area focuses on market trend analysis and product planning, integrating industry reports, user needs surveys, and other content; the R&D area covers fault monitoring, operating condition analysis, and other content to help optimize product performance; the manufacturing area collects production equipment parameters, quality inspection reports, and other data; the marketing area integrates user profiles, online and offline sales data, and other data to support precision marketing and channel optimization; the quality assurance area gathers vehicle after-sales repair cases and component life statistics to build quality traceability and risk warning; and the service area covers V2X APP user interaction logs, remote diagnostic data, and other data to drive upgrades in user service experience.

[0100] During the subject area division process, a primary subject area serves as the initial scope, with progressively smaller sub-sub ...

[0101] The subject area should be updated on time according to new business needs, generally once a month or quarter. At the same time, the original subject area should be evaluated, and invalid or erroneous content should be removed and optimized.

[0102] In this embodiment, the data application requirements analysis step further includes:

[0103] Pre-plan the scope of data application for the data warehouse;

[0104] The design of the vehicle-to-everything (V2X) indicator system is based on the scope of data application.

[0105] The primary classification is determined based on vehicle-related, user-related, and behavior-related information.

[0106] Based on the primary classification, the secondary, tertiary and quaternary classifications are developed sequentially.

[0107] The indicators are designed based on a four-level classification.

[0108] Specifically, the vehicle-to-everything (V2X) indicator system is designed based on application scope, with vehicles, users, and behaviors as primary categories. Each primary category is further subdivided into secondary, tertiary, and quaternary categories: secondary categories are further subdivided into statistical and detailed categories; statistical categories are further divided into atomic, derived, and distributed indicators; and detailed categories are divided into basic and dynamic attribute indicators. Indicators are designed based on these four categories, with names chosen according to business needs and the experience of relevant personnel.

[0109] Simultaneously, the indicator calculation logic needs to be defined. Indicator types include numerical and distributed types. Numerical indicators refer to those that can be expressed using a single numerical value and are calculated through statistical methods or formulas. Distributed indicators refer to the proportion of each interval in a field. First, confirm the segmentation dimension, segmentation range, and step size, and then calculate using the ratio of the number of statistical intervals to the total number.

[0110] In one specific embodiment, the three primary categories—vehicle, user, and behavior—are defined as follows, along with their respective secondary categories:

[0111] Vehicle category: Focusing on vehicles, this section analyzes the basic attributes of vehicles after they are put into the market, including vehicle configuration, vehicle status, and vehicle services. User category: Focusing on people, this section analyzes the basic attributes of users, including human-vehicle relationship, natural attributes, social attributes, and location attributes. Behavior category: Focusing on behavior, this section analyzes the performance of products under different working conditions or scenarios, including driving behavior and business behavior.

[0112] Each secondary category is further divided into two tertiary categories: statistical and detailed. The functions of the different categories are as follows: Statistical category: Based on big data, it statistically analyzes the performance of the range in the context of big data, removes differences, and reflects the average attributes of the range; Detailed category: Used for individual analysis, it investigates and analyzes the causes of anomalies in users, products, and events, and can support the attributes of statistical analysis.

[0113] Each of the three-level categories is further divided into four-level categories. The statistical category includes three types of four-level categories: atomic indicators, derived indicators, and distribution indicators. The detailed category includes two types of four-level categories: basic attribute indicators and dynamic attribute indicators.

[0114] Indicators are designed based on the above four categories, and the indicator names are based on business needs and the experience of relevant staff.

[0115] For example, under the primary category of "Vehicles," there are three secondary categories: Vehicle Configuration, Vehicle Status, and Vehicle Services. Within Vehicle Status, statistical atomic indicators include the number of vehicle model failures and the number of software version updates; statistical derived indicators include the model with the highest failure rate and the frequency of software updates; and statistical distribution indicators include the distribution of vehicle model failure rates and software version information. Detailed basic attribute indicators include the production date and engine model; and detailed dynamic attribute indicators include the software version number and data version number.

[0116] Simultaneously, the indicator calculation logic needs to be defined. Indicator types include numerical and distributed types. Numerical indicators refer to those that can be expressed using a single numerical value and are calculated through statistical methods or formulas. Distributed indicators refer to the proportion of each interval in a field. First, confirm the segmentation dimension, segmentation range, and step size, and then calculate using the ratio of the number of statistical intervals to the total number.

[0117] Numerical indicators, such as the highest speed of the day, are obtained from the speed values ​​by removing those greater than 200 km / h. Distributive indicators, such as speed-mileage distribution, are obtained by statistically analyzing the ratio of mileage traveled in each speed (in km / h) interval [0,5), [5,10), ... [125,130] to the total mileage of the day.

[0118] In this embodiment, the steps of dataset warehouse architecture design further include:

[0119] Acquire and organize the characteristic information of vehicle network data;

[0120] Based on the characteristics of vehicle-to-everything (V2X) data and business needs, the V2X data warehouse is divided into five levels;

[0121] The five layers include: data preparation layer, data detail layer, data service layer, data application layer, and dimensional data layer.

[0122] in,

[0123] Design a data preparation layer to provide a data foundation for upper-level data cleaning and processing;

[0124] Design a data detail layer as an isolation layer between the business layer and the data warehouse;

[0125] Design a data service layer to realize the aggregation and analysis of subject domain data;

[0126] Design a dimensional data layer to provide multi-dimensional descriptions for subject domain data;

[0127] Design a data application layer to support specific business scenarios.

[0128] Specifically, based on subject areas and indicators, a bottom-up approach is adopted to design the hierarchical structure of the vehicle-to-everything (V2X) data warehouse. Dividing the V2X data warehouse into five levels is the optimal solution, based on the characteristics of V2X data and business requirements.

[0129] The design includes a data preparation layer that stores raw data received from the data source, providing a data foundation for upper-level data cleaning and processing; a data detail layer that acts as an isolation layer between the business layer and the data warehouse, maintaining the granularity of the raw data layer while performing standardized operations such as empty data removal and dirty data cleaning; a data service layer that, based on the data detail layer, integrates business segment data such as vehicles and users by subject domain, constructing wide tables and a common indicator system through aggregation operations to achieve summary analysis of subject domain data; a dimensional data layer that independently stores dimensional data such as road information and fault types, optimizing query efficiency through fact table and dimension table splitting, and providing multi-dimensional descriptions of subject domain data; and a data application layer that stores indicator data to directly support specific business scenarios.

[0130] In one specific embodiment, such as Figure 4 The diagram shows the hierarchical architecture of the vehicle-to-everything (V2X) data warehouse. Based on the characteristics of V2X data and business requirements, dividing the V2X data warehouse into five levels is the optimal solution. The definitions and stored data content of each level are as follows:

[0131] Data Preparation Layer (OBS Layer): Data from the data source is extracted, processed simply, and transmitted before entering this layer. It provides raw data to the upper layers of the data warehouse. To ensure traceability data requirements, excessive data cleaning is avoided.

[0132] Data Detail Layer (DWD Layer): Stores the data generated after extracting, transforming, and loading all the data from the Data Preparation Layer. It also stores the characteristics and attributes of the data used for further data analysis, such as anomaly annotations and segmentation markers. This provides reliable data for subsequent data processing.

[0133] Data Service Layer (DWS Layer): This layer stores common indicator data formed by light aggregation and summarization based on the subject area and segmentation identifiers, building upon the data detail layer. Examples include basic vehicle driving information statistics tables and speed-mileage distributions. Simultaneously, it extracts event information, such as sharp turn events and fault reporting events, to form data tables.

[0134] Data Application Layer (ADS Layer): This layer stores statistical indicator data that is deeply aggregated based on the data detail layer or data service layer to meet actual data needs, such as speed-gear-mileage distribution and actual torque-speed-mileage distribution. It is used for data dashboard display and data query services.

[0135] Dimensional Data Layer (DIM Layer): Stores dimensional data, which are factual characteristics independent of data tables in other layers and are not easily changed. Examples include road information, location information, and fault types.

[0136] If there are special requirements for the stored data, data warehouse layers can be added as needed, or unnecessary layers can be reduced to simplify the architecture, ensuring that the data warehouse can flexibly adapt to business development and technological evolution.

[0137] In this embodiment, the data warehouse development steps further include:

[0138] Based on the steps of dataset warehouse architecture design, the vehicle network data warehouse is layered, and the full-link data computing process is designed.

[0139] Specifically, a task scheduler is deployed to handle ETL and metric calculation tasks in the data warehouse and the dependencies between tasks, enabling automated scheduling and retrying in case of failure.

[0140] Specifically, based on the layered architecture of the data warehouse, a full-chain data computation process is designed. A mainstream storage-compute separation architecture is adopted to achieve elastic scaling of storage and computing resources. For tasks such as ETL and metric calculation in the data warehouse, and the dependencies between tasks, a task scheduler is deployed to achieve automated scheduling and failure retries.

[0141] In one specific embodiment, a full-chain data computation process is designed based on a layered data warehouse architecture. A mainstream storage-compute separation architecture is adopted, with the storage layer using distributed file systems such as HDFS or object storage to achieve low-cost storage of massive amounts of data, and the computation layer using distributed computing engines such as Spark and Flink to achieve elastic resource scheduling, supporting independent scaling of storage capacity and computing power.

[0142] For data that is highly relevant to business operations, has a large volume, and needs to be read frequently in the data service layer and data application layer, ClickHouse columnar database can be selected. With the help of columnar storage compression technology and vectorized computing engine, the response time of multidimensional analysis queries can be optimized from minutes to seconds. It is especially suitable for scenarios such as driving behavior distribution analysis and multidimensional fault code analysis in the Internet of Vehicles, thereby enhancing the timeliness of data.

[0143] For data processing tasks that require scheduled operations and involve dependencies between them, such as exporting online data, triggering data processing, and importing data to the business platform, it is necessary to streamline the process logic and deploy a task scheduler, such as Airflow or Azkaban, to manage the data processing workflow and avoid manual operations.

[0144] Figure 2 This is a structural diagram of a vehicle network data warehouse device provided in one or more embodiments of the present invention.

[0145] like Figure 2 The vehicle-to-everything (V2X) data warehouse device shown includes: a data sorting module, a data scenario analysis module, a data application requirement analysis module, a dataset warehouse architecture design module, and a data warehouse development module;

[0146] in,

[0147] The data sorting module is used to determine the data to be stored in the data warehouse;

[0148] The data scenario analysis module is used to determine the data subject domain;

[0149] The data application requirements analysis module is used to determine various indicators;

[0150] The module for dataset warehouse architecture design is used to define the hierarchical division of the data warehouse;

[0151] The data warehouse development module is used to design the entire data computation process.

[0152] It is worth noting that although this system / device only discloses modules for data sorting, data scenario analysis, data application requirement analysis, dataset warehouse architecture design, and data warehouse development, this does not mean that this device is limited to the above-mentioned basic functional modules. Rather, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technologies to form an infinite number of embodiments or technical solutions. In other words, this system / device is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be interpreted as the scope of protection of the claims of this invention being limited to the above-disclosed basic functional modules.

[0153] Figure 5 This is a block diagram of an electronic device structure for a vehicle network data warehouse method provided in one or more embodiments of the present invention.

[0154] like Figure 5 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0155] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the vehicle-to-everything (V2X) data warehouse method.

[0156] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle network data warehouse method.

[0157] This application also provides a computing platform, including:

[0158] Electronic devices used to implement the steps of a vehicle-to-everything (V2X) data warehouse method;

[0159] The processor runs a program, and when the program runs, it executes the steps of the vehicle-to-everything (V2X) data warehouse method based on data output from electronic devices.

[0160] Storage medium used to store programs that, when running, execute the steps of the vehicle-to-everything (V2X) data warehouse method on data output from electronic devices.

[0161] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0162] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0163] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0164] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0165] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0166] For ease of description, the above devices are described separately according to their functions, divided into various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0167] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0168] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0169] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

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

Claims

1. A method for building a vehicle-to-everything (V2X) data warehouse, characterized in that: The vehicle-to-everything (V2X) data warehouse method includes the following steps: data sorting, data scenario analysis, data application requirement analysis, dataset warehouse architecture design, and data warehouse development. in, The steps of data processing include determining the data to be stored in the data warehouse; The steps in data scenario analysis include determining the subject area to which the data belongs; The steps in data application requirements analysis include identifying various indicators; The steps in designing a dataset warehouse architecture include: clearly defining the data warehouse hierarchy; The steps involved in developing a data warehouse include designing a complete data computation process.

2. The vehicle-to-everything (V2X) data warehouse method according to claim 1, characterized in that, The steps of data processing also include: To obtain the business needs and operational strategies of the Internet of Vehicles (IoV); Based on business needs and operational strategies, select the data that needs to be stored in the data warehouse; Based on the data that needs to be stored in the data warehouse, determine the data to be stored in the data warehouse; This includes classifying the data to be stored in the data warehouse by type and format; Based on the classification of type and format, match the corresponding access method for the vehicle network; Based on the data to be stored in the data warehouse and the corresponding access method, the raw data of the data warehouse is constructed.

3. The vehicle-to-everything (V2X) data warehouse method according to claim 2, characterized in that, The steps of data scenario analysis also include: Pre-plan the data application functions of the data warehouse; Based on data application functions as the dividing dimension, a hierarchical vehicle-to-everything (V2X) theme domain system is constructed; Obtain relevant information about data application functions; Based on the correlation of data application functions, data is aggregated into a unified theme; Among these, a primary subject area is established as the initial scope; Based on establishing a primary subject area as the initial scope, subdivide its sub-topics; Each subject area defines metadata information.

4. The vehicle-to-everything (V2X) data warehouse method according to claim 3, characterized in that, The steps in data application requirements analysis also include: Pre-plan the scope of data application for the data warehouse; The design of the vehicle-to-everything (V2X) indicator system is based on the scope of data application. The primary classification is determined based on vehicle-related, user-related, and behavior-related information. Based on the primary classification, the secondary, tertiary and quaternary classifications are developed sequentially. The indicators are designed based on a four-level classification.

5. The vehicle-to-everything (V2X) data warehouse method according to claim 4, characterized in that, The steps in designing a dataset warehouse architecture also include: Acquire and organize the characteristic information of vehicle network data; Based on the characteristics of vehicle-to-everything (V2X) data and business needs, the V2X data warehouse is divided into five levels; The five layers include: data preparation layer, data detail layer, data service layer, data application layer, and dimensional data layer. in, Design a data preparation layer to provide a data foundation for upper-level data cleaning and processing; Design a data detail layer as an isolation layer between the business layer and the data warehouse; Design a data service layer to realize the aggregation and analysis of subject domain data; Design a dimensional data layer to provide multi-dimensional descriptions for subject domain data; Design a data application layer to support specific business scenarios.

6. The vehicle-to-everything (V2X) data warehouse method according to claim 5, characterized in that, The steps in data warehouse development also include: Based on the steps of dataset warehouse architecture design, the vehicle network data warehouse is layered, and the full-link data computing process is designed. Specifically, a task scheduler is deployed to handle ETL and metric calculation tasks in the data warehouse and the dependencies between tasks, enabling automated scheduling and retrying in case of failure.

7. A vehicle-to-everything (V2X) data warehouse device, characterized in that, The vehicle-to-everything (V2X) data warehouse device includes: a data sorting module, a data scenario analysis module, a data application requirement analysis module, a dataset warehouse architecture design module, and a data warehouse development module. in, The data sorting module is used to determine the data to be stored in the data warehouse; The data scenario analysis module is used to determine the subject area to which the data belongs; The data application requirements analysis module is used to determine various indicators; The module for dataset warehouse architecture design is used to define the hierarchical division of the data warehouse; The data warehouse development module is used to design the entire data computation process.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the vehicle-to-everything (V2X) data warehouse method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle-to-everything (V2X) data warehouse method as described in any one of claims 1 to 6.

10. A computing platform, characterized in that, include: An electronic device for implementing the steps of the vehicle-to-everything (V2X) data warehouse method as described in any one of claims 1 to 6; A processor that runs a program that, when the program is running, performs the steps of the vehicle-to-everything (V2X) data warehouse method as described in any one of claims 1 to 6 from data output by an electronic device. A storage medium for storing a program that, when running, performs the steps of the vehicle-to-everything (V2X) data warehouse method as described in any one of claims 1 to 6 on data output from an electronic device.

Images