Vehicle data processing method and device, electronic equipment and storage medium

Abstract

The application provides a vehicle data processing method and device, electronic equipment and storage medium. The method comprises the following steps: acquiring a signal list sent by a user terminal, converting vehicle signals in the signal list by using a database file, and generating a vehicle information acquisition request; sending the vehicle information acquisition request to a vehicle-mounted communication controller, analyzing the vehicle information acquisition request, obtaining a target signal and a signal collection period; receiving full-amount CAN messages reported by each controller of the vehicle, and sending the full-amount CAN messages to the vehicle-mounted communication controller; analyzing the full-amount CAN messages based on the target signal and the signal collection period to obtain final vehicle signals; processing the final vehicle signals by using a cloud terminal to obtain raw data for generating a chart, and sending the raw data to the user terminal, so that the user terminal generates a corresponding chart by using the raw data and displays the chart. The application improves the use rate of vehicle data, enhances data value, and improves user experience.

Description

Technical Field

[0001] This application relates to the field of new energy vehicle technology, and in particular to a vehicle data processing method, device, electronic device and storage medium. Background Technology

[0002] Current vehicle data collection methods mostly employ pre-defined keyword collection schemes, such as vehicle status information. This information is displayed on the web page for backend maintenance personnel or on the user's mobile app. This approach has several drawbacks. For example, the backend or mobile app can only view keyword information set at the factory, resulting in poor scalability. Furthermore, most existing data collection schemes only allow maintenance personnel to define the data, failing to extend customization permissions to users. This leads to reduced data utilization, decreased data value, and a poor user experience. Summary of the Invention

[0003] In view of this, embodiments of this application provide a vehicle data processing method, apparatus, electronic device, and storage medium to solve the problems of poor scalability, reduced data utilization, reduced data value, and poor user experience in the prior art.

[0004] A first aspect of this application provides a vehicle data processing method, comprising: acquiring a signal list sent by a user terminal; converting vehicle signals in the signal list using a database file stored in the cloud; generating a vehicle information acquisition request based on the converted vehicle signals; sending the vehicle information acquisition request to an on-board communication controller; parsing the vehicle information acquisition request using the on-board communication controller to obtain a target signal and a signal acquisition period; receiving full CAN messages reported by each controller of the vehicle according to a preset time period using a gateway; sending the full CAN messages to the on-board communication controller; parsing the full CAN messages based on the target signal and the signal acquisition period to obtain the final vehicle signal corresponding to the target signal in the full CAN messages; sending the final vehicle signal to the cloud; processing the final vehicle signal using the cloud to obtain raw data for generating a chart; sending the raw data to the user terminal so that the user terminal can use the raw data to generate and display the corresponding chart.

[0005] A second aspect of this application provides a vehicle data processing apparatus, comprising: an acquisition module configured to acquire a signal list sent by a user terminal, convert vehicle signals in the signal list using a database file stored in the cloud, and generate a vehicle information acquisition request based on the converted vehicle signals; a parsing module configured to send the vehicle information acquisition request to an on-board communication controller, and parse the vehicle information acquisition request using the on-board communication controller to obtain a target signal and a signal acquisition period; a receiving module configured to receive full CAN messages reported by each controller of the vehicle according to a preset time period using a gateway, and send the full CAN messages to the on-board communication controller; a sending module configured to parse the full CAN messages based on the target signal and the signal acquisition period to obtain the final vehicle signal corresponding to the target signal in the full CAN messages, and send the final vehicle signal to the cloud; and a processing module configured to process the final vehicle signal using the cloud to obtain raw data for generating charts, and send the raw data to the user terminal so that the user terminal can use the raw data to generate and display the corresponding charts.

[0006] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described method.

[0007] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0009] By acquiring a list of signals sent by the user terminal, the system converts the vehicle signals in the list using a database file stored in the cloud, and generates a vehicle information acquisition request based on the converted signals. This request is then sent to the vehicle communication controller, which parses it to obtain the target signal and signal acquisition cycle. The system also receives all CAN messages reported by each controller of the vehicle at a preset time period via a gateway and sends these messages to the vehicle communication controller. Based on the target signal and signal acquisition cycle, the system parses all CAN messages to obtain the final vehicle signal corresponding to the target signal, which is then sent to the cloud. The cloud processes the final vehicle signal to obtain raw data for generating charts, which is then sent to the user terminal for generating and displaying the corresponding charts. This application enables flexible vehicle data acquisition and display, improving the utilization rate, data value, and user experience of vehicle data. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic flowchart of the vehicle data processing method provided in the embodiments of this application;

[0012] Figure 2 This is a schematic diagram of the structure of the vehicle data processing device provided in the embodiments of this application;

[0013] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0014] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0015] With the rapid development of new energy vehicles and intelligent vehicles, the demand for real-time collection, analysis, and display of vehicle data is becoming increasingly strong. Vehicle data is of great significance for understanding vehicle status, realizing intelligent control, and analyzing driving behavior. However, in existing technologies, most vehicle data collection methods adopt a collection scheme with pre-fixed keywords, which involve vehicle body status information, engine information, and other aspects.

[0016] This data collection scheme with pre-defined keywords limits the data displayed on the web page for backend maintenance personnel or the user's mobile app. Users and maintenance personnel can only view the keyword information set at the factory, and cannot dynamically adjust the required data according to actual needs, resulting in poor scalability for later use.

[0017] Furthermore, existing data collection solutions often only allow operations and maintenance personnel to define the data, while users cannot customize the data according to their own needs. In this situation, users can only passively accept the data information provided by the platform, failing to achieve true on-demand data collection and display, thus reducing the user experience.

[0018] In practical applications, different users may have different needs for vehicle data. For example, some users may be more concerned about battery information, while others may be more concerned about the vehicle's driving status. These differentiated needs make existing technologies inadequate in meeting user requirements.

[0019] Therefore, addressing the problems in existing technologies and developing a flexible vehicle data collection and display solution that allows users to customize data according to their needs has become an urgent issue to be resolved.

[0020] In view of this, this application provides a vehicle data processing method based on user needs to solve the above problems. This application improves the flexibility and scalability of vehicle data acquisition by using techniques such as sending a signal list from the user terminal, converting vehicle signals using a database file stored in the cloud, and parsing all CAN messages based on the target signal. This application utilizes vehicle usage status data and driving behavior data for statistical calculations to generate recommended information and display it to the user terminal, thereby increasing automatic identification and recommendation schemes, greatly improving data utilization, and enhancing user experience. This application implements vehicle-to-cloud communication through the MQTT protocol, ensuring stable data upload to the cloud even under weak network conditions. The customized data acquisition mechanism greatly improves the scalability of data display. The prediction and recommendation mechanism for data display greatly improves the utilization and value of the data.

[0021] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0022] Figure 1 This is a flowchart illustrating the vehicle data processing method provided in the embodiments of this application. Figure 1 The vehicle data processing method can be executed by an application. For example... Figure 1 As shown, the vehicle data processing method may specifically include:

[0023] S101: Obtain the signal list sent by the user terminal, convert the vehicle signals in the signal list using the database file stored in the cloud, and generate a vehicle information acquisition request based on the converted vehicle signals.

[0024] S102, the vehicle information acquisition request is sent to the vehicle communication controller, and the vehicle communication controller is used to parse the vehicle information acquisition request to obtain the target signal and the signal acquisition cycle.

[0025] S103 uses the gateway to receive the full CAN messages reported by each controller of the vehicle according to a preset time period, and sends the full CAN messages to the vehicle communication controller.

[0026] S104 parses the full CAN message based on the target signal and the signal acquisition cycle to obtain the final vehicle signal corresponding to the target signal in the full CAN message, and sends the final vehicle signal to the cloud.

[0027] S105 uses the cloud to process the final vehicle signal to obtain the raw data used to generate the chart, and sends the raw data to the user terminal so that the user terminal can use the raw data to generate the corresponding chart and display it.

[0028] First, some technical terms involved in the embodiments of this application in practical application scenarios will be explained, which may include the following:

[0029] MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol based on a publish / subscribe model. It is designed for low-bandwidth, high-latency, and unstable network environments, and is suitable for the Internet of Things (IoT), mobile applications, and other resource-constrained environments. The main features of MQTT are as follows:

[0030] Lightweight: The message structure of the MQTT protocol is very simple, with a minimum header size of 2 bytes, which reduces the overhead of data transmission.

[0031] Publish / Subscribe Pattern: Clients can subscribe to topics. When a publisher publishes a message, the message is sent to all clients that have subscribed to the corresponding topic. This pattern enables one-to-many communication, reducing the load on the server.

[0032] Low power consumption and low bandwidth: Suitable for IoT devices such as sensors and smart home devices, which typically have limited bandwidth and energy.

[0033] Quality of Service (QoS): The MQTT protocol supports three different levels of QoS: QoS0, QoS1 and QoS2, to meet the reliability requirements of different scenarios.

[0034] Supports offline messaging: When a client is offline, the MQTT broker can store messages for subscribed topics, and the client can receive messages published during the offline period when it reconnects.

[0035] Message Retention and Wills: The client can be configured to retain messages and will messages. When the client unexpectedly goes offline, the will message will be published to other subscribers to notify them of the abnormal situation.

[0036] The Telematics Box (TBox, also known as an in-vehicle communication controller) is a crucial component in the field of new energy vehicles. It's a device that integrates in-vehicle communication and information processing functions. The main function of the TBox is to enable communication between the vehicle and its external environment, providing functions such as remote diagnostics, remote control, real-time navigation, vehicle positioning, and emergency assistance. The TBox has the following functions:

[0037] Data collection: TBox can collect real-time vehicle data, including battery status, charging status, vehicle speed, driving distance, etc., and transmit the data to the backend server or user terminal device.

[0038] Remote diagnostics and control: TBox allows users or service providers to remotely monitor vehicle status, such as battery health and charging progress. It also supports remote control of various car functions, such as remotely unlocking / locking the vehicle and remotely starting the air conditioning.

[0039] Vehicle location and navigation: Through satellite positioning systems such as GPS and Beidou, TBox can obtain vehicle location information in real time and provide users with functions such as real-time navigation and trajectory query.

[0040] Connected vehicle services: TBox supports vehicle-to-internet connectivity, providing users with services such as real-time weather, traffic information, online music, and voice recognition.

[0041] Safety and Rescue: In emergency situations, such as a vehicle collision or other safety issues, the TBox can automatically trigger the alarm system, sending the vehicle's location and status information to the emergency rescue center or user device to provide timely rescue services.

[0042] In new energy vehicles, a controller is an electronic device that controls and manages various subsystems of the vehicle. The controller receives signals from sensors and other devices, and adjusts its output in real time according to a pre-set control algorithm to control various performance parameters of the vehicle. Controllers for new energy vehicles mainly include the following categories:

[0043] Motor Controller: The motor controller is responsible for controlling the drive motor of a new energy vehicle to achieve operations such as acceleration, deceleration, and forward / reverse rotation. It receives pedal signals and adjusts the motor's operating state to meet the driver's driving needs.

[0044] Battery Management System (BMS): The BMS monitors and manages the vehicle's battery to ensure it operates safely and reliably. The BMS can monitor parameters such as battery state of charge, voltage, and temperature, and adjust charging and discharging strategies as needed to extend battery life.

[0045] Onboard Charger Controller: The onboard charger controller is responsible for managing the charging process of new energy vehicles, communicating with external charging piles, controlling charging current and voltage, and ensuring safe charging of the battery.

[0046] Energy Management Controller: The energy management controller monitors and optimizes the vehicle's energy usage in real time, including devices such as the motor, battery, and generator. By adjusting the operating status of each component, it improves energy utilization efficiency and reduces energy consumption.

[0047] Body Controller: The body controller is primarily responsible for controlling the vehicle's lights, wipers, windows, seats, and other functions. It receives signals from switches, sensors, and other devices, and controls the corresponding actuators to adjust various functions.

[0048] Advanced Driver Assistance Systems (ADAS): The ADAS controller is responsible for processing information from the vehicle's surrounding environment, such as data collected by sensors like cameras, radar, and ultrasonic sensors, to provide the driver with safety warnings, autonomous driving assistance, and other functions.

[0049] These controllers work together to ensure an efficient, safe, and comfortable driving experience for new energy vehicles. Different models and manufacturers may use different controller designs and configurations to meet specific performance requirements.

[0050] In some embodiments, before obtaining the list of signals sent by the user terminal, the method of this application embodiment further includes:

[0051] The system collects and calculates data on the user's vehicle usage status and driving behavior, makes judgments based on the calculation results, and generates a recommendation message corresponding to the preset recommendation scheme when the calculation results meet the conditions. The system then sends the recommendation message to the user.

[0052] Once the user confirms the recommendation message, it is determined to be the default signal pre-configured in the recommendation scheme, and a signal list is generated using the default signal.

[0053] Specifically, when displaying the signals of the target vehicle, in order to provide a more personalized and accurate data display service, the system can not only generate a signal list based on the user's selection, but also predict the vehicle data that the user may need to view based on historical vehicle usage status data and driving behavior data, thereby automatically generating a vehicle data display scheme that meets the user's needs.

[0054] In other words, before obtaining the signal list sent by the user, this embodiment of the application can predict the user's data viewing needs based on the user's historical vehicle usage status data and historical driving behavior data over a period of time, and automatically generate a recommendation scheme. By sending the recommendation message to the mobile app (i.e., the user's terminal), the user can click on the recommendation message on the mobile app to automatically generate a signal list consisting of vehicle signals that match the user's viewing needs, thus achieving personalized vehicle signal display.

[0055] The following section uses three possible recommendation schemes as examples to explain in detail the process and principles of predicting and recommending vehicle signals that users may need to view. Specifically, it may include the following:

[0056] In a specific example, based on the number of recent clicks on fuel consumption information identified by the mobile app (which falls under driving behavior data) and the recent fuel consumption fluctuations identified by the vehicle and cloud (which fall under vehicle usage status data), a recommendation message indicating significant recent fuel consumption fluctuations is sent to the user when the number of clicks and the fuel consumption fluctuations reach preset trigger conditions (e.g., the number of clicks exceeds a preset number, or the fluctuation amplitude exceeds a fluctuation threshold). After the user clicks on this recommendation message, the system automatically generates a signal list corresponding to the preset "Recent Fuel Consumption Viewing Scheme" based on the default signal, and sends the signal list to the cloud for subsequent data processing operations.

[0057] After the data processing operation is completed, that is, after the final vehicle signal is processed in the cloud to generate raw data, the system automatically generates a recent fuel consumption trend chart based on the cooperation of various components and the corresponding raw data, and displays it in the user's mobile app, thereby helping the user understand the recent fuel consumption situation.

[0058] In another specific example, based on the frequency with which the user presses the brake and accelerator pedals (which falls under driving behavior data), when the frequency reaches a preset trigger condition (such as exceeding a frequency threshold), a recommendation message suggesting improvements to driving habits is sent to the user. After the user clicks on this recommendation message, the system automatically generates a list of signals corresponding to the preset "driving habit analysis scheme" based on the default signals, and sends this list to the cloud for subsequent data processing.

[0059] After the data processing operation is completed, that is, after the final vehicle signal is processed in the cloud to generate raw data, the system will automatically generate a comparison chart between the user's driving habit data and the recommended driving habit value (for example, a line graph can be used as a comparison chart), and display it in the user's mobile app, thereby helping the user to further improve their driving habits.

[0060] In another specific example, based on the usage time of vehicle electrical components (such as headlights, in-vehicle displays, etc.) (which falls under vehicle usage status data), the system automatically calculates the aging degree of each electrical component. For example, the aging degree can be determined based on the usage time of the electrical component. When the aging degree of an electrical component reaches a preset trigger condition (such as the usage time exceeding a certain threshold), a prompt message (i.e., a recommendation message) is sent to the user's terminal, indicating that the aging electrical component needs to be replaced. After the user clicks on the prompt message, the system automatically generates a signal list corresponding to the preset "aging component replacement plan" based on the default signal, and sends the signal list to the cloud for subsequent data processing operations.

[0061] After the data processing operation is completed, that is, after the final vehicle signal is processed in the cloud to generate raw data, the system will automatically generate a chart of the aging parts that need to be replaced and display the chart in the user's mobile app so that the user can plan the replacement plan of the aging parts in advance.

[0062] In some embodiments, obtaining a list of signals sent by the user terminal includes:

[0063] In response to the user's click operation on the vehicle signal to be acquired in the user terminal, a signal list is generated based on the user's selection of vehicle signals to be acquired, and the signal list is sent to the cloud via the HTTPS protocol.

[0064] Specifically, the mobile app (i.e. the user end) sends the desired list of signals to the cloud via the HTTPS protocol, that is, the cloud obtains the list of signals sent by the mobile app; the list of signals contains the vehicle signals selected by the user through the mobile app interface (i.e. the vehicle signals that the user wants to display), and the vehicle signals can be considered as vehicle information, such as: vehicle speed, window open / closed status, battery status, etc.

[0065] Furthermore, in response to the user's click on the vehicle information to be displayed (i.e., the vehicle signal to be acquired) in the application, the mobile app determines the vehicle information selected by the user and generates a signal list based on the selected vehicle information. In other words, the user selects the target vehicle information (target vehicle signal) to be displayed in the application, and the target vehicle signal is used to generate a signal list. The mobile app then sends the generated signal list to the cloud via the HTTPS protocol.

[0066] In some embodiments, a vehicle signal in the signal list is converted using a database file stored in the cloud, and a vehicle information retrieval request is generated based on the converted vehicle signal, including:

[0067] Based on the vehicle model information, the database file stored in the cloud is queried to determine the DBC file corresponding to the vehicle model information;

[0068] The vehicle signals in the signal list are converted using the vehicle's DBC file to obtain vehicle signals that match the vehicle's model information.

[0069] The converted vehicle signal is used to generate a vehicle information acquisition request, which includes the target signal to be displayed and the signal acquisition period corresponding to the target signal.

[0070] Specifically, after receiving the signal list, the cloud performs the corresponding conversion of the vehicle's CAN DBC to form a JSON request (i.e., a vehicle information acquisition request). The JSON request contains the required DBC corresponding signals and cycle information. The following detailed description of the cloud's signal list processing procedure, using a specific embodiment, includes the following:

[0071] Since the DBC file for each vehicle model may be different, it is necessary to convert the vehicle signals in the signal list into signals corresponding to the specific vehicle model. First, based on the vehicle model information, the database file stored in the cloud is queried to determine the DBC file corresponding to the model information. In other words, the DBC files for all vehicle models stored in the cloud are matched against the current vehicle's model. Then, the matched DBC file is used to convert the vehicle signals in the signal list, transforming the original vehicle signals into the signals corresponding to the specific vehicle model, and a JSON request is generated based on the converted vehicle signals.

[0072] In practical applications, after converting the signal list to the vehicle CAN DBC file, the cloud generates a JSON request. This request contains the vehicle signals (i.e., target signals) corresponding to the DBC the user wants to view, as well as the time intervals for collecting these signals (i.e., signal acquisition cycles). It should be noted that, in addition to sending the signal list to the cloud via a mobile app, and having the cloud process the signal list to generate a JSON request, a JSON request can also be generated directly using the cloud's management page.

[0073] In this embodiment, the CAN DBC file is a data file describing messages and signals in the CAN protocol (Controller Area Network Protocol), used to parse and display the actual data in the CAN messages. The DBC file can be considered a specification that defines how to convert raw CAN messages into specific vehicle parameter information (such as speed, fuel consumption, and RPM) in a specific vehicle's CAN bus system. Through the DBC file, various automotive diagnostic tools and software can more easily interpret and analyze the vehicle's CAN message data, thereby enabling vehicle detection, analysis, and debugging. JSON (JavaScript Object Notation) is a lightweight data exchange format that is easy to read and write, and also easy for machines to parse and generate. This embodiment encapsulates information into JSON requests, facilitating the transmission and parsing of data between the cloud, mobile apps, and vehicles.

[0074] In some embodiments, a vehicle information acquisition request is sent to an on-board communication controller, and the on-board communication controller parses the vehicle information acquisition request, including:

[0075] The vehicle information acquisition request is sent to the vehicle communication controller via the MQTT protocol using the cloud. The vehicle communication controller parses the vehicle information acquisition request to obtain the target signal and the signal acquisition period, and persists the target signal and the signal acquisition period to the local configuration file.

[0076] Specifically, after generating a JSON request (i.e., a vehicle information acquisition request) in the cloud, the generated JSON request is sent to the MQTT client deployed on the Tbox (i.e., the vehicle communication controller) via the MQTT protocol. After receiving the JSON request, the Tbox performs a parsing operation on the JSON request, extracts the target signal and signal acquisition period from the JSON request, and persists the parsed information to the local configuration file, that is, stores the target signal and signal acquisition period in the local configuration file.

[0077] In some embodiments, the gateway receives all CAN messages reported by each controller of the vehicle according to a preset time period, and sends the all CAN messages to the vehicle communication controller, including:

[0078] Each controller in the vehicle synchronizes all generated CAN messages to the gateway according to a preset time period, so that the gateway can package all CAN messages into a data file corresponding to the UDP protocol and send the data file to the vehicle communication controller via the UDP protocol.

[0079] Specifically, each controller in the vehicle sends all CAN messages generated on its own to the gateway at pre-set time intervals via the CAN protocol. Therefore, the gateway receives the vehicle's CAN messages reported by the controllers at regular intervals. Then, the gateway continuously packages all CAN messages from each controller into data files (binary data packets) at pre-set time intervals and sends the data files to the Tbox via the UDP protocol.

[0080] This application describes how the gateway and controller exchange CAN messages and send these CAN messages to the TBox.

[0081] In practical applications, each controller sends all CAN messages generated on its own to the gateway at a pre-set interval via the CAN protocol. Here, "all CAN messages" refers to all CAN information generated by the controller, including but not limited to vehicle status, battery information, and motor information. The pre-set interval means that this information is sent at fixed time intervals.

[0082] The gateway is responsible for collecting all CAN messages from each controller. After receiving these CAN messages, the gateway will package them according to a pre-set period and send the packaged CAN messages to the TBox via UDP (User Datagram Protocol).

[0083] Among them, UDP is a connectionless transport layer protocol that provides a fast and simple way to transmit data. Sending CAN messages to the TBox via UDP helps to achieve real-time and efficient vehicle data transmission.

[0084] In some embodiments, parsing the full CAN message based on the target signal and the signal acquisition period includes:

[0085] Based on the local configuration file, the entire CAN message is filtered using the target signal and the signal acquisition period to obtain the final vehicle signal corresponding to the target signal in the entire CAN message. The final vehicle signal is then compressed and sent to the cloud via the MQTT protocol.

[0086] Specifically, after receiving the data file, Tbox parses, filters, and compresses the full CAN data uploaded by the gateway according to the locally persisted configuration file information (i.e., the target signal and the signal acquisition period) to obtain the final vehicle signal. Then, it sends the final vehicle signal to the cloud via the MQTT protocol so that the cloud can receive the relevant data, parse it, and display it.

[0087] Furthermore, the local configuration file contains the target signals and the signal acquisition period. The target signals refer to the vehicle signals that need to be displayed to the user, and the signal acquisition period refers to the time interval at which these target signals are filtered from the full CAN messages. In a specific example, the gateway sends a data file containing the full CAN messages to the Tbox at a time interval of 0.8 seconds, while the Tbox's filtering period for the uploaded data file may be 10 seconds. That is, the Tbox filters and acquires the reported full CAN messages every 10 seconds. Therefore, the Tbox acquires the target signals from the full CAN messages within 10 seconds.

[0088] Furthermore, Tbox compresses the filtered final vehicle signals and sends the compressed signals to the cloud via the MQTT protocol. After receiving the final vehicle signals, the cloud processes them into raw data corresponding to a pre-defined chart format (i.e., raw data that can directly generate charts), and sends this raw data to the mobile app via HTTPS. Upon receiving the raw data, the mobile app parses it and generates corresponding charts for display. Users can then intuitively view the status data corresponding to the vehicle signals in the signal list on the mobile app.

[0089] In practical applications, when there is a new need to view custom data, you only need to initiate a request for the target signal and signal acquisition cycle on the mobile app or cloud. The entire system will periodically collect and parse the data and finally present it to the management terminal and mobile app, thus achieving truly flexible data collection.

[0090] According to the technical solution provided in this application, this application utilizes MQTT technology to realize communication between the vehicle, the cloud, and a mobile app, providing users with flexible vehicle data collection and display functions. Users can customize their vehicle information viewing needs through the mobile app and understand the vehicle's status in real time. When a user has new data viewing needs, they only need to initiate a request in the mobile app or the cloud, and the entire system will automatically update the data collection and display, achieving truly flexible data collection. In this way, users can view the vehicle's real-time status data anytime, anywhere, improving the user experience. This application enhances the flexibility and scalability of vehicle data collection, truly achieving "what the user wants is what they get," eliminating the pain point of users only being able to passively receive data information provided by the platform. The addition of automatic identification and recommendation schemes greatly improves data utilization, significantly enhances the user experience, and strengthens the value of the data.

[0091] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0092] Figure 2 This is a schematic diagram of the vehicle data processing device provided in an embodiment of this application. Figure 2 As shown, the vehicle data processing device includes:

[0093] The acquisition module 201 is configured to acquire a list of signals sent by the user terminal, convert the vehicle signals in the signal list using a database file stored in the cloud, and generate a vehicle information acquisition request based on the converted vehicle signals.

[0094] The parsing module 202 is configured to send a vehicle information acquisition request to the vehicle communication controller, and use the vehicle communication controller to parse the vehicle information acquisition request to obtain the target signal and the signal acquisition period.

[0095] The receiving module 203 is configured to receive the full CAN messages reported by each controller of the vehicle according to a preset time period using the gateway, and send the full CAN messages to the vehicle communication controller.

[0096] The sending module 204 is configured to parse the full CAN message based on the target signal and the signal acquisition period, obtain the final vehicle signal corresponding to the target signal in the full CAN message, and send the final vehicle signal to the cloud.

[0097] The processing module 205 is configured to process the final vehicle signal using the cloud to obtain the raw data for generating the chart, and send the raw data to the user terminal so that the user terminal can use the raw data to generate the corresponding chart and display it.

[0098] In some embodiments, Figure 2 Before acquiring the signal list sent by the user terminal, the acquisition module 201 statistically analyzes and calculates the user's vehicle usage status data and driving behavior data, and makes a judgment based on the calculation results. When the judgment results meet the conditions corresponding to the preset recommendation scheme, a recommendation message corresponding to the recommendation scheme is generated and sent to the user terminal. After obtaining the user terminal's confirmation instruction for the recommendation message, it is determined to be the default signal pre-configured by the recommendation scheme, and a signal list is generated using the default signal.

[0099] In some embodiments, Figure 2 The acquisition module 201 responds to the user's click operation on the vehicle signal to be acquired in the user terminal, generates a signal list based on the vehicle signal to be acquired selected by the user, and sends the signal list to the cloud via the HTTPS protocol.

[0100] In some embodiments, Figure 2 The acquisition module 201 queries the database file stored in the cloud based on the vehicle model information to determine the DBC file corresponding to the model information; it uses the vehicle's DBC file to convert the vehicle signals in the signal list to obtain vehicle signals that match the vehicle model information; and it uses the converted vehicle signals to generate a vehicle information acquisition request, wherein the vehicle information acquisition request includes the target signal to be displayed and the signal acquisition period corresponding to the target signal.

[0101] In some embodiments, Figure 2The parsing module 202 uses the cloud to send the vehicle information acquisition request to the vehicle communication controller via the MQTT protocol. The vehicle communication controller parses the vehicle information acquisition request to obtain the target signal and the signal acquisition period, and persists the target signal and the signal acquisition period to the local configuration file.

[0102] In some embodiments, Figure 2 The receiving module 203 synchronizes all generated CAN messages to the gateway according to a preset time period, so that the gateway packages all CAN messages into a data file corresponding to the UDP protocol and sends the data file to the vehicle communication controller via the UDP protocol.

[0103] In some embodiments, Figure 2 The sending module 204 filters all CAN messages according to the local configuration file, using the target signal and the signal acquisition cycle to obtain the final vehicle signal corresponding to the target signal in the full CAN messages. The final vehicle signal is then compressed and sent to the cloud via the MQTT protocol.

[0104] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0105] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 of this embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0106] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0107] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0108] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0109] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0111] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0112] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0113] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0114] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0117] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle data processing method, characterized in that, include: The system obtains a list of signals sent by the user based on a recommendation message, which is generated based on the user's historical vehicle usage status data and historical driving behavior data. The system then uses a DBC file corresponding to the vehicle model information stored in the cloud to convert the vehicle signals in the signal list. Based on the converted vehicle signals, the system generates a vehicle information acquisition request, which includes the target signal to be displayed and the signal acquisition period corresponding to the target signal. The vehicle information acquisition request is sent to the vehicle communication controller, which parses the vehicle information acquisition request to obtain the target signal and the signal acquisition period, and persists the target signal and the signal acquisition period to the local configuration file. The gateway receives all CAN messages reported by each controller of the vehicle according to a preset time period, and sends the all CAN messages to the vehicle communication controller. Based on the local configuration file, the full CAN messages are filtered according to the target signal and the signal acquisition period to obtain the final vehicle signal corresponding to the target signal in the full CAN messages, and the final vehicle signal is sent to the cloud. The final vehicle signal is processed in the cloud to obtain raw data for generating charts. The raw data is then sent to the user terminal so that the user terminal can use the raw data to generate and display the corresponding charts.

2. The method according to claim 1, characterized in that, Before obtaining the list of signals sent by the user based on the recommendation message, the method further includes: The system statistically analyzes and calculates the user's vehicle usage status data and driving behavior data, makes a judgment based on the calculation results, and when the calculation results meet the conditions corresponding to the preset recommendation scheme, it generates a recommendation message corresponding to the recommendation scheme and sends it to the user terminal. Upon receiving confirmation of the recommendation message from the user, the system determines the default signal pre-configured for the recommendation scheme and uses the default signal to generate the signal list.

3. The method according to claim 1, characterized in that, The process of obtaining the list of signals sent by the user based on the recommendation message includes: In response to a user's click operation on the vehicle signal to be acquired in the user terminal, the signal list is generated based on the vehicle signal to be acquired selected by the user, and the signal list is sent to the cloud via the HTTPS protocol.

4. The method according to claim 1, characterized in that, The step of sending the vehicle information acquisition request to the vehicle communication controller and using the vehicle communication controller to parse the vehicle information acquisition request includes: The vehicle information acquisition request is sent to the vehicle communication controller via the MQTT protocol using the cloud. The vehicle communication controller then parses the vehicle information acquisition request to obtain the target signal and the signal acquisition period.

5. The method according to claim 1, characterized in that, The step of receiving full CAN messages reported by each controller of the vehicle according to a preset time period using a gateway, and sending the full CAN messages to the vehicle communication controller, includes: Each controller of the vehicle synchronizes the generated full CAN messages to the gateway according to a preset time period, so that the gateway packages the full CAN messages into a data file corresponding to the UDP protocol and sends the data file to the vehicle communication controller via the UDP protocol.

6. The method according to claim 1, characterized in that, Sending the final vehicle signal to the cloud includes: The final vehicle signal is compressed, and the compressed final vehicle signal is sent to the cloud via the MQTT protocol.

7. A vehicle data processing device, characterized in that, include: The acquisition module is configured to acquire a list of signals sent by the user terminal based on a recommendation message, which is generated based on the user's historical vehicle usage status data and historical driving behavior data; convert the vehicle signals in the signal list using a DBC file corresponding to the vehicle model information stored in the cloud; and generate a vehicle information acquisition request based on the converted vehicle signals. The parsing module is configured to send the vehicle information acquisition request to the vehicle communication controller, use the vehicle communication controller to parse the vehicle information acquisition request, obtain the target signal and the signal acquisition period, and persist the target signal and the signal acquisition period to a local configuration file; The receiving module is configured to receive the full CAN messages reported by each controller of the vehicle according to a preset time period using the gateway, and send the full CAN messages to the vehicle communication controller. The sending module is configured to filter the full CAN messages based on the target signal and the signal acquisition period according to the local configuration file, obtain the final vehicle signal corresponding to the target signal in the full CAN messages, and send the final vehicle signal to the cloud. The processing module is configured to process the final vehicle signal using the cloud to obtain raw data for generating charts, and send the raw data to the user terminal so that the user terminal can use the raw data to generate and display the corresponding charts.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images