Vehicle data pushing method and device, server, medium and program product
By receiving and parsing vehicle data in real time during the test drive and performing correlation and aggregation calculations in the data warehouse, the problem of insufficient computing power of Java tools when processing massive test drive data is solved, and the efficient generation and timely push of test drive reports are realized.
Patent Information
- Application Number
- CN202511611614.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-05
- Publication Date
- 2026-02-27
AI Technical Summary
In existing technologies, when using Java tools to process massive amounts of test drive data, the computing power is insufficient, resulting in low timeliness of test drive report generation, inability to obtain analysis results in a timely manner, and impacting test drive conversion efficiency.
By receiving and parsing vehicle operation data reported by the in-vehicle terminal in real time during the test drive, business information is synchronized to the data warehouse. Streaming computing and offline scheduling tasks are used to perform correlation and aggregation calculations in the data warehouse to generate trip report indicators, which are then pushed to the business database.
It enables stable, efficient, and timely processing of massive amounts of vehicle data, ensuring that report data is pushed out shortly after the test drive ends, significantly improving data timeliness and meeting the business's need for rapid feedback.
Smart Images
Figure CN121579489A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, server, medium and program product for pushing vehicle data. Background Technology
[0002] With the rapid development of the automotive industry and increasingly fierce market competition, test drives have become a crucial step for car dealers to acquire potential customers and improve sales conversion rates. To scientifically evaluate test drive effectiveness, optimize customer experience, and support sales decisions, more and more automakers are focusing on collecting and analyzing vehicle operation data during test drives.
[0003] In related technologies, test drive data processing methods typically employ a traditional Java application architecture. During the test drive, the in-vehicle terminal (such as a T-BOX) collects vehicle operating status data (such as speed, mileage, and battery level) and reports this data to a backend server. The backend server then uses Java programs to parse and process the received data, ultimately storing the results in a relational database such as MySQL. Based on this database, a test drive report is generated for dealers to view on their business platform.
[0004] However, since the data is directly stored in the MySQL database, the efficiency of performing complex queries and aggregation calculations based on MySQL drops sharply when the data volume accumulates to a certain scale. This can easily lead to a serious delay in the generation of test drive reports, making it impossible to obtain analysis results in a timely manner after the test drive ends, thus affecting the test drive conversion efficiency. Summary of the Invention
[0005] This application provides a method, device, server, medium, and program product for pushing vehicle data, in order to solve the problems of insufficient computing power and low timeliness of test drive report generation when using Java tools to process massive test drive data in related technologies.
[0006] The first aspect of this application provides a method for pushing vehicle data, comprising the following steps: writing test drive business information into a business database, the business information including the vehicle identification number of the test drive vehicle and the test drive time period; receiving vehicle operation data reported by the vehicle terminal of the test drive vehicle through a message queue during the test drive time period; generating a trip report index for the test drive vehicle based on the vehicle operation data and the business information, and pushing the trip report index to the business database.
[0007] Optionally, the vehicle operation data is raw hexadecimal data. Before generating the test drive vehicle's trip report indicators based on the vehicle operation data and synchronized business information, the process includes: parsing the raw hexadecimal data through a streaming computing task; storing the parsed vehicle operation data into a first target table in the data warehouse; and synchronizing the business information in the business database to a second target table in the data warehouse.
[0008] Optionally, the trip report indicators for the test drive vehicle are generated based on vehicle operation data and synchronized business information, including: performing association and aggregation calculations on the first target table and the second target table based on a preset script to generate trip report indicators.
[0009] Optionally, the trip report indicators include at least one of the following: mileage, average speed, maximum speed, remaining battery power, remaining fuel, tire pressure, and driving trajectory. Mileage is calculated as the total mileage of the last vehicle data point minus the total mileage of the first vehicle data point within the test drive period. Average speed is calculated as the arithmetic mean of the average speeds across all vehicle data points within the test drive period. Maximum speed is calculated as the maximum speed across all vehicle data points within the test drive period. Remaining battery power is the remaining battery power value in the last vehicle data point within the test drive period. Remaining fuel is the remaining fuel level in the last vehicle data point within the test drive period. Tire pressure includes the pressures of the left front, right front, left rear, and right rear tires, with each tire pressure value corresponding to the pressure value in the last vehicle data point within the test drive period. The driving trajectory is the set of the location longitude and latitude of all vehicle data points within the test drive period.
[0010] Optionally, pushing the trip report metrics to the business database also includes: storing the trip report metrics in a third target table in the data warehouse; writing the trip report metrics in the third target table into the business database through an offline scheduling task, wherein the business platform calls the target interface to access the business data and visualizes the trip report metrics.
[0011] A second aspect of this application provides a vehicle data push device, comprising: a writing module for identifying a code and a test drive time period; a receiving module for receiving vehicle operation data reported by the vehicle terminal of the test drive vehicle through a message queue during the test drive time period; and a push module for generating a trip report index for the test drive vehicle based on the vehicle operation data and synchronized business information, and pushing the trip report index to the business database.
[0012] Optionally, the vehicle operation data is raw hexadecimal data. The vehicle data push device further includes: a processing module, used to parse the raw hexadecimal data through a streaming computing task before generating the test drive vehicle's trip report indicators based on the vehicle operation data and synchronized business information; store the parsed vehicle operation data into a first target table in the data warehouse; and synchronize the business information in the business database to a second target table in the data warehouse.
[0013] Optionally, the push module is further used to: perform association and aggregation calculations on the first target table and the second target table based on a preset script to generate trip report indicators.
[0014] Optionally, the trip report indicators include at least one of the following: mileage, average speed, maximum speed, remaining battery power, remaining fuel, tire pressure, and driving trajectory. Mileage is calculated as the total mileage of the last vehicle data point minus the total mileage of the first vehicle data point within the test drive period. Average speed is calculated as the arithmetic mean of the average speeds across all vehicle data points within the test drive period. Maximum speed is calculated as the maximum speed across all vehicle data points within the test drive period. Remaining battery power is the remaining battery power value in the last vehicle data point within the test drive period. Remaining fuel is the remaining fuel level in the last vehicle data point within the test drive period. Tire pressure includes the pressures of the left front, right front, left rear, and right rear tires, with each tire pressure value corresponding to the pressure value in the last vehicle data point within the test drive period. The driving trajectory is the set of the location longitude and latitude of all vehicle data points within the test drive period.
[0015] Optionally, the push module is further used to: store the trip report metrics to a third target table in the data warehouse; write the trip report metrics in the third target table to the business database through an offline scheduling task, wherein the business platform calls the target interface to access the business data and visualizes the trip report metrics.
[0016] A third aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the vehicle data push method as described in the above embodiments.
[0017] A fourth aspect of this application provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed, are used to implement the vehicle data push method as described in the above embodiments.
[0018] A fifth aspect of this application provides a computer program product, including: a computer program or instructions, which, when executed, implement the vehicle data push method as described in the above embodiments.
[0019] Therefore, this application has at least the following beneficial effects: This application embodiment receives and parses vehicle operation data reported by the in-vehicle terminal in real time during the test drive, and simultaneously synchronizes the business information written to the business database to the data warehouse. In the data warehouse, the vehicle operation data and synchronized business information are correlated and aggregated, thereby achieving stable, efficient, and timely processing of massive amounts of vehicle data. This ensures that report data can be pushed out shortly after the test drive ends, significantly improving data timeliness. This solves the problems of insufficient computing power and low timeliness of test drive report generation when using Java tools to process massive test drive data in related technologies. Additional aspects and advantages of this application 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 application. Attached Figure Description
[0020] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a vehicle data push method according to an embodiment of this application; Figure 2 This is a flowchart of test drive data processing according to an embodiment of this application; Figure 3 This is an example diagram of a vehicle data push device provided according to an embodiment of this application; Figure 4 This is a schematic diagram of the server structure according to an embodiment of this application. Detailed Implementation
[0021] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0022] The following description, with reference to the accompanying drawings, outlines a method, apparatus, server, and storage medium for pushing vehicle data according to embodiments of this application. Addressing the problems mentioned in the background section, this application provides a method for pushing vehicle data. In this method, vehicle operation data reported by the in-vehicle terminal is received and parsed in real time during a test drive. Simultaneously, business information written to a business database is synchronized to a data warehouse. In the data warehouse, the vehicle operation data and synchronized business information are correlated and aggregated, thereby achieving stable, efficient, and timely processing of massive amounts of vehicle data. This ensures that report data can be pushed shortly after the test drive ends, significantly improving data timeliness. This solves the problems of insufficient computing power and low timeliness of test drive report generation when using Java tools to process massive amounts of test drive data in related technologies.
[0023] Specifically, Figure 1 This is a flowchart illustrating a vehicle data push method provided in an embodiment of this application.
[0024] like Figure 1 As shown, the method for pushing vehicle data includes the following steps: In step S101, the test drive business information is written into the business database. The business information includes the vehicle identification number of the test drive vehicle and the test drive time period.
[0025] Understandably, the test drive service platform responds to a user's (such as a salesperson or customer) initiation of a test drive on a mobile device by generating and recording the service information for this test drive, and then writing this information into the service database. The service information includes at least: the Vehicle Identification Number (VIN) of the test drive vehicle, and the automatically recorded test drive time period, which is defined by the test drive start time (start_time) and test drive end time (end_time). Specifically, when the user clicks "Start Test Drive," the current time is immediately captured as the start_time, and a record containing the drive_id (test drive order ID), VIN, and start_time is created and stored in the service database (e.g., the mysql_drive_test table in MySQL). When the user clicks "End Test Drive" after the test drive ends, the current time is captured again as the end_time, and the end_time field in the aforementioned record is updated, thus completely defining the time boundaries of this test drive.
[0026] In step S102, during the test drive period, the vehicle operation data reported by the vehicle terminal of the test drive vehicle through the message queue is received.
[0027] The vehicle operation data is in hexadecimal raw data.
[0028] Understandably, during the test drive period, the vehicle's onboard terminal (e.g., T-BOX) continuously collects real-time vehicle operating status data. This data is encapsulated in hexadecimal raw message format and pushed in real-time to a designated topic (e.g., topic_carinfo) in a distributed message queue (e.g., Kafka) via the onboard communication module. Vehicle operating data includes, but is not limited to, the following items: total mileage, remaining driving range, remaining battery power (SOC), remaining fuel, average energy consumption, average fuel consumption, vehicle speed, tire pressure (front left, front right, rear left, rear right), GPS latitude and longitude, and reporting time. Because the data is continuously generated at high frequency and with high concurrency, using a message queue as a buffer layer effectively decouples data production and consumption, ensuring reliable reception and orderly flow of massive amounts of raw data, laying the foundation for subsequent real-time analysis and interpretation.
[0029] In step S103, a trip report index for the test drive vehicle is generated based on vehicle operation data and business information, and the trip report index is pushed to the business database.
[0030] In one embodiment of this application, before generating the test drive vehicle's trip report index based on vehicle operation data and synchronized business information, the method further includes: parsing the hexadecimal raw data through a streaming computing task; storing the parsed vehicle operation data into a first target table in a data warehouse; and synchronizing the business information in the business database to a second target table in the data warehouse.
[0031] Specifically, this embodiment of the application can continuously consume hexadecimal raw data reported by the vehicle terminal from a message queue (such as the Kafka topic_carinfo) through a streaming computing task (e.g., a real-time computing job built on Apache Flink) deployed on a big data platform. This streaming computing task parses each hexadecimal message in real time, converting it into structured field data, as shown in Table 1, including but not limited to: total mileage, vehicle speed, remaining battery power (SOC), remaining fuel, tire pressure, GPS latitude and longitude, and reporting time. After parsing, this structured vehicle operation data is written into the first target table (e.g., the hive_carinfo table) in a data warehouse (e.g., Hive), achieving standardized storage of the raw vehicle data.
[0032] Secondly, through an offline scheduling platform (such as Apache Airflow), a periodic data synchronization task is configured (e.g., executed every 30 minutes) to extract and load the test drive business information written to the business database (such as the mysql_drive_test table in MySQL) in the above embodiment into a second target table (such as the hive_drive_test table) in the data warehouse. This synchronization process ensures that key business context information such as test drive order ID (drive_id), vehicle VIN, test drive start time (start_time), and end time (end_time) can be correlated and analyzed with vehicle operation data in the same data environment.
[0033]
[0034] In one embodiment of this application, generating a test drive vehicle trip report index based on vehicle operation data and synchronized business information includes: performing association and aggregation calculations on a first target table and a second target table based on a preset script to generate the trip report index.
[0035] It is understood that in the data warehouse, this embodiment of the application can associate the first target table (hive_carinfo) and the second target table (hive_drive_test) by executing a preset HiveSQL script. The association conditions are usually the vehicle VIN and the time range (i.e., the reporting time of the vehicle operation data falls within the test drive time period defined by the business information). Based on this, according to the predefined business calculation criteria, the associated dataset is aggregated and calculated to generate multiple trip report indicators, as shown in Table 2.
[0036] The trip report indicators include at least one of the following: mileage, average speed, maximum speed, remaining battery power, remaining fuel, tire pressure, and driving trajectory. Mileage is calculated as the total mileage of the last vehicle data point minus the total mileage of the first data point within the test drive period. Average speed is calculated as the arithmetic mean of the average speeds across all vehicle data points within the test drive period. Maximum speed is calculated as the maximum speed across all vehicle data points within the test drive period. Remaining battery power is the remaining battery power value in the last vehicle data point within the test drive period. Remaining fuel is the remaining fuel level in the last vehicle data point within the test drive period. Tire pressure includes the pressures of the left front, right front, left rear, and right rear tires, with each tire pressure value corresponding to the pressure value in the last vehicle data point within the test drive period. The driving trajectory is the set of the location longitude and latitude of all vehicle data points within the test drive period.
[0037]
[0038]
[0039] In one embodiment of this application, pushing the trip report metrics to the business database further includes: storing the trip report metrics in a third target table in a data warehouse; writing the trip report metrics in the third target table into the business database through an offline scheduling task, wherein the business platform calls the target interface to access the business data and visualizes the trip report metrics.
[0040] It is understood that, in this embodiment of the application, a third target table (such as the hive_drive_report table) can be created and maintained in the data warehouse to centrally store the calculated trip report metrics. A periodically executed data exchange task is configured through an offline scheduling platform (such as Apache Airflow). This task, at preset time intervals (e.g., every 30 minutes), synchronously writes the trip report metric data from the third target table (hive_drive_report) to the business database of the test drive business platform (e.g., the mysql_drive_report table in a MySQL database) through an efficient data export and loading mechanism. This ensures that the report data is pushed out shortly after the test drive ends, significantly improving data timeliness and meeting the business's need for rapid feedback.
[0041] Furthermore, the test drive platform retrieves trip report metrics corresponding to a specified test drive order ID or vehicle VIN from the business database (mysql_drive_report table) by calling preset target data access interfaces (such as database query interfaces). After receiving this structured data, the platform's front-end module uses visualization components (such as ECharts, AntV, and other chart libraries) to visualize the trip report metrics. For example, it renders the driving trajectory as a map, displays speed change trends as a line graph, presents remaining battery and fuel levels as a dashboard, and lists key performance indicators in a table. Dealer users can intuitively and comprehensively understand the vehicle usage behavior and status during customer test drives through the platform interface, providing data support for subsequent sales follow-ups and customer communication, effectively improving test drive conversion rates.
[0042] The following is combined Figure 2 The method for pushing vehicle data according to the embodiments of this application will be described in detail, such as... Figure 2 As shown, it includes the following steps: Step 1: The MySQL database of the test drive service platform stores information about the test drive vehicles.
[0043] Step 2: Initiate the test drive action on the mobile operation platform.
[0044] Step 3: The test drive business platform adds a test drive start and end time synchronization interface. The start time of the test drive is start_time. When the test drive start action is triggered, the information is saved to the business database. A new MySQL table mysql_drive_test is added. A new record is added to the table, storing drive_id, vehicle vin code, and start_time test drive start time information.
[0045] Step 4: During the test drive, the test vehicle reports real-time vehicle data. The onboard TBOX collects the raw hexadecimal vehicle data and pushes the hexadecimal message to the Kafka topic_carinfo.
[0046] Step 5: On the mobile device, click "End Test Drive". The test drive start and end time synchronization interface is activated. The end time is passed in as end_time. At the same time as triggering the end test drive action, the information in the business database mysql_drive_test table is updated. The data information added in step 3 is updated, and the end_time field is updated.
[0047] Step 6: Using an offline scheduling platform, write the data from the mysql_drive_test table in the test drive business database to the hive_drive_test table via data exchange. The offline scheduling platform can be set to perform timed synchronization, such as once every half hour.
[0048] Step 7: The hexadecimal data of the vehicle reported in Step 4 is parsed. The data reported in real time by the test drive vehicle is parsed in real time by the Flink task and falls into the Hive table hive_carinfo. During the entire test drive trip, the vehicle will report multiple message data.
[0049] Step 8: Perform HiveSQL logical business processing on the hive_drive_test table from Step 6 and the hive_carinfo table from Step 7. Use the offline scheduling platform hivesql task to calculate the report indicators required for test drives, and store the resulting test drive trip report indicators into the hive_drive_report table.
[0050] Step 9: Using an offline scheduling platform, the data from the Hive table `hive_drive_report` (the trip report from Step 8) is written to the MySQL table `mysql_drive_report` on the business platform via data exchange. This data is then displayed on the test drive business platform page as corresponding performance metrics. An offline scheduling cycle is set to generate a test drive report every 30 minutes and synchronize it to the test drive business platform.
[0051] The vehicle data push method proposed in this application receives and parses vehicle operation data reported by the in-vehicle terminal in real time during the test drive, and simultaneously synchronizes business information written to the business database to the data warehouse. In the data warehouse, the vehicle operation data and synchronized business information are correlated and aggregated, thereby achieving stable, efficient, and timely processing of massive amounts of vehicle data. This ensures that report data can be pushed out shortly after the test drive ends, significantly improving data timeliness. Therefore, this solves the problems of insufficient computing power and low timeliness of test drive report generation when using Java tools to process massive test drive data in related technologies.
[0052] Next, the vehicle data push device according to the embodiments of this application is described with reference to the accompanying drawings.
[0053] Figure 3 This is a block diagram of a vehicle data push device according to an embodiment of this application.
[0054] like Figure 3 As shown, the vehicle data push device 10 includes: a writing module 100, a receiving module 200, and a push module 300.
[0055] The writing module 100 is used to write the test drive business information into the business database, including the vehicle identification number of the test drive vehicle and the test drive time period; the receiving module 200 is used to receive the vehicle operation data reported by the vehicle terminal of the test drive vehicle through the message queue during the test drive time period; the pushing module 300 is used to generate the trip report index of the test drive vehicle based on the vehicle operation data and business information, and push the trip report index to the business database.
[0056] In one embodiment of this application, the vehicle operation data is hexadecimal raw data. The vehicle data push device further includes: a processing module, used to parse the hexadecimal raw data through a streaming computing task before generating the test drive vehicle's trip report index based on the vehicle operation data and synchronized business information; store the parsed vehicle operation data into a first target table in the data warehouse; and synchronize the business information in the business database to a second target table in the data warehouse.
[0057] In one embodiment of this application, the push module 300 is further configured to: perform association and aggregation calculations on the first target table and the second target table based on a preset script to generate trip report indicators.
[0058] In one embodiment of this application, the trip report indicators include at least one of the following: mileage, average speed, maximum speed, remaining battery power, remaining fuel, tire pressure, and driving trajectory. The mileage is calculated as: the total mileage of the last vehicle operation data point minus the total mileage of the first vehicle operation data point within the test drive period. The average speed is calculated as: the arithmetic mean of the average speeds of all vehicle operation data points within the test drive period. The maximum speed is calculated as: the maximum speed of all vehicle operation data points within the test drive period. The remaining battery power is the remaining battery power value in the last vehicle operation data point within the test drive period. The remaining fuel is the remaining fuel value in the last vehicle operation data point within the test drive period. Tire pressure includes the pressures of the left front, right front, left rear, and right rear tires, with each tire pressure value corresponding to the pressure value in the last vehicle operation data point within the test drive period. The driving trajectory is the set of the positioning longitude and latitude of all vehicle operation data points within the test drive period.
[0059] In one embodiment of this application, the push module 300 is further configured to: store the trip report indicators to a third target table in the data warehouse; write the trip report indicators in the third target table into the business database through an offline scheduling task, wherein the business platform calls the target interface to access the business data and displays the trip report indicators visually.
[0060] It should be noted that the foregoing explanation of the vehicle data push method embodiment also applies to the vehicle data push device of this embodiment, and will not be repeated here.
[0061] The vehicle data push device proposed in this application receives and parses vehicle operation data reported by the in-vehicle terminal in real time during the test drive. Simultaneously, it synchronizes business information written to the business database to the data warehouse. In the data warehouse, the vehicle operation data and synchronized business information are correlated and aggregated, thereby achieving stable, efficient, and timely processing of massive amounts of vehicle data. This ensures that report data can be pushed out shortly after the test drive ends, significantly improving data timeliness. Therefore, it solves the problems of insufficient computing power and low timeliness of test drive report generation when using Java tools to process massive amounts of test drive data in related technologies.
[0062] Figure 4 A schematic diagram of the structure of a server provided in an embodiment of this application. The server may include: The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.
[0063] When the processor 402 executes the program, it implements the vehicle data push method provided in the above embodiments.
[0064] Furthermore, the server also includes: Communication interface 403 is used for communication between memory 401 and processor 402.
[0065] The memory 401 is used to store computer programs that can run on the processor 402.
[0066] The memory 401 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.
[0067] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0068] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.
[0069] Processor 402 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.
[0070] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for pushing vehicle data.
[0071] This application also provides a computer program product, including: a computer program or instructions, which, when executed, implement the vehicle data push method as described in the above embodiments.
[0072] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0073] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0074] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0075] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.
[0076] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
[0077] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.
Claims
1. A method for pushing vehicle data, characterized in that, Includes the following steps: The business information of test drives is written into the business database, including the vehicle identification number of the test drive vehicle and the test drive time period; During the test drive period, the vehicle operation data reported by the vehicle terminal of the test drive vehicle through a message queue is received. Based on the vehicle operation data and the business information, a trip report index for the test drive vehicle is generated, and the trip report index is pushed to the business database.
2. The method for pushing vehicle data according to claim 1, characterized in that, The vehicle operation data is raw hexadecimal data. Before generating the trip report indicators for the test drive vehicle based on the vehicle operation data and synchronized business information, the following steps are also included: The raw hexadecimal data is parsed using a streaming computing task; The parsed vehicle operation data is stored in the first target table of the data warehouse; The business information in the business database is synchronized to the second target table in the data warehouse.
3. The method for pushing vehicle data according to claim 2, characterized in that, Based on the vehicle operation data and synchronized business information, the trip report indicators for the test drive vehicle are generated, including: The trip report indicators are generated by performing association and aggregation calculations on the first target table and the second target table based on a preset script.
4. The method for pushing vehicle data according to claim 1 or 3, characterized in that, The trip report indicators include at least one of the following: mileage, average speed, maximum speed, remaining battery power, remaining fuel, tire pressure, and driving trajectory. The mileage is calculated as follows: the total mileage of the last vehicle operation data point during the test drive period minus the total mileage of the first vehicle operation data point. The average vehicle speed is calculated as the arithmetic mean of the average vehicle speeds among all vehicle operation data during the test drive period. The maximum speed is calculated as the maximum speed among all vehicle operating data during the test drive period. The remaining battery power is determined as the remaining battery power value in the last vehicle operation data during the test drive period. The remaining fuel level is determined as the remaining fuel level in the last vehicle operation data during the test drive period. The tire pressure includes the left front tire pressure, right front tire pressure, left rear tire pressure, and right rear tire pressure. The value of each tire pressure is the pressure value corresponding to the last vehicle operation data during the test drive period. The driving trajectory is a set of the positioning longitude and positioning latitude of all vehicles during the test drive period.
5. The method for pushing vehicle data according to claim 1, characterized in that, Pushing the trip report metrics to the business database also includes: Store the trip report metrics in a third target table in the data warehouse; The trip report metrics in the third target table are written into the business database through an offline scheduling task. The business platform calls the target interface to access the business data and visualizes the trip report metrics.
6. A vehicle data push device, characterized in that, include: The writing module is used for the identification code and test drive time period; The receiving module is used to receive vehicle operation data reported by the vehicle terminal of the test drive vehicle through a message queue during the test drive period. The push module is used to generate trip report indicators for the test drive vehicle based on the vehicle operation data and synchronized business information, and push the trip report indicators to the business database.
7. The vehicle data push device according to claim 6, characterized in that, The push module is further used for: Store the trip report metrics in a third target table in the data warehouse; The trip report metrics in the third target table are written into the business database through an offline scheduling task. The business platform calls the target interface to access the business data and visualizes the trip report metrics.
8. A server, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the vehicle data push method as described in any one of claims 1-5.
9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they implement the vehicle data push method according to any one of claims 1-5.
10. A computer program product comprising: A computer program or instruction, characterized in that, when executed, the computer program or instruction implements the vehicle data push method according to any one of claims 1-5.