Method, system, medium and product for acquisition of vehicle bus data
By acquiring the acquisition configuration files and monitoring trigger conditions, and using periodic, event-driven and scenario-driven modes to collect vehicle bus data, solving the problems of high equipment costs and resource waste in the existing technology, and achieving efficient and economical data acquisition.
Patent Information
- Application Number
- CN202510393755.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-31
- Publication Date
- 2025-07-18
AI Technical Summary
Existing vehicle bus data acquisition equipment is expensive and usually collects all data rather than a specific period or type of data, resulting in waste of resources.
By acquiring the acquisition configuration file, determine the data type, acquisition mode and trigger conditions, monitor the vehicle bus data to meet the trigger conditions for acquisition, and send data packets to the server, supporting periodic, event-driven and scenario-driven acquisition modes.
It realizes efficient collection of specific vehicle bus data according to actual needs, reduce unnecessary data transmission and save resources.
Smart Images
Figure CN120342898A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of vehicles, and more particularly to a method for collecting vehicle bus data, a system capable of implementing the method, a computer-readable storage medium, and a computer program product. Background Art
[0002] Existing vehicle communication mainly relies on the Controller Area Network (CAN) bus, which has been widely used in vehicle control systems for its high reliability and real-time performance. With the electrification and digitalization process of automotive technology, the collection of vehicle bus data is crucial for both after-sales problem troubleshooting and functional engineering optimization. Currently, the collection of vehicle bus data can be achieved through dedicated collection devices, which may be costly. In addition, the collection of vehicle bus data often targets all vehicle bus data, but in actual applications, only specific time periods or specific types of vehicle bus data may be required each time, rather than all vehicle bus data.
[0003] It should be noted that the information disclosed in the above background art section is only used to enhance the understanding of the background of the present application, and thus may include information that does not constitute the prior art known to those of ordinary skill in the art. Summary of the Invention
[0004] To solve or at least alleviate one or more of the above problems, there is provided a method for collecting vehicle bus data, a system capable of implementing the method, a computer-readable storage medium, and a computer program product, which can collect the vehicle bus data required in specific situations according to the actual needs according to a configuration file, so as to reduce unnecessary data transmission and obtain relevant data of the vehicle more economically and efficiently.
[0005] According to a first aspect of the present application, there is provided a method for collecting vehicle bus data, the method including: obtaining a collection configuration file; based on the collection configuration file, determining a data type of data to be collected, a collection mode corresponding to the data type, and a trigger condition for the collection mode; monitoring vehicle bus data to determine whether the trigger condition is satisfied; in response to one or more of the trigger conditions being satisfied, collecting one or more types of data in the data type; forming the collected data into a data packet and sending the data packet to a server.
[0006] As an alternative or supplement to the above solution, the method according to an embodiment of the present application further includes periodically updating the collection configuration file from the server.
[0007] As an alternative or supplement to the above solution, in the method according to an embodiment of the present application, the acquisition modes include: a periodic acquisition mode, an event-based acquisition mode, and a scenario-based acquisition mode.
[0008] As an alternative or supplement to the above solution, in the method according to an embodiment of the present application, the trigger condition of the periodic acquisition mode is to reach the timing of each period, the trigger condition of the event-based acquisition mode is that one or more vehicle bus data indicate that a predetermined event has occurred, and the trigger condition of the scenario-based acquisition mode is that one or more vehicle bus data satisfy one or more relationships.
[0009] As an alternative or supplement to the above solution, in the method according to an embodiment of the present application, the predetermined events include an acceleration event, an overtaking event, and an emergency braking event.
[0010] As an alternative or supplement to the above solution, in the method according to an embodiment of the present application, the one or more relationships include the relative magnitude relationship between the one or more vehicle bus data and one or more thresholds, the relative magnitude relationship between the one or more vehicle bus data, and the relative magnitude relationship between the vehicle bus data in the one or more vehicle bus data at different times.
[0011] As an alternative or supplement to the above solution, in the method according to an embodiment of the present application, collecting one or more types of data in the data types includes: collecting the one or more types of data for a period of time; collecting all the one or more types of data until the end of the current trip; and collecting the one or more types of data at a specific moment.
[0012] According to a second aspect of the present application, there is provided a system for collecting vehicle bus data, the system being deployed in a gateway of a vehicle, the system including: a processor; a memory; and a computer program, the computer program being stored on the memory and being executable on the processor, the execution of the computer program causing any one of the methods according to the first aspect of the present application to be executed.
[0013] According to a third aspect of the present application, there is provided a computer-readable storage medium, the computer-readable storage medium including instructions that, when running, execute any one of the methods according to the first aspect of the present application.
[0014] According to a fourth aspect of the present application, there is provided a computer program product, the computer program product including instructions that, when running, execute any one of the methods according to the first aspect of the present application.
[0015] The solution for collecting vehicle bus data according to one or more embodiments of the present application can perform specified collection operations for specific data types according to a configuration file, thereby efficiently collecting the required bus data and saving transmission, processing and storage resources. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The above and / or other aspects and advantages of the present application will become clearer and easier to understand through the following description of various aspects in conjunction with the accompanying drawings, in which the same or similar units are represented by the same reference numerals. In the accompanying drawings:
[0017] Figure 1 is a flow chart of a method 10 for collecting vehicle bus data according to an embodiment of the present application;
[0018] Figure 2 is a schematic diagram 20 illustrating the transfer of vehicle bus data from a vehicle 200 to a server 250 according to an embodiment of the present application;
[0019] Figure 3 is a schematic diagram of a system 30 for collecting vehicle bus data according to an embodiment of the present application. DETAILED DESCRIPTION
[0020] The description of the following specific embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or the application and use of the disclosed technology. In addition, it is not intended to be bound by any express or implied theory presented in the aforementioned technical field, background technology or the following specific embodiments.
[0021] In the following detailed description of the embodiments, many specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it is apparent to one of ordinary skill in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features are not described in detail to avoid unnecessarily complicating the description.
[0022] Terms such as "having" and "including" indicate that in addition to the units (modules) and steps that are directly and clearly stated in the specification and claims, the technical solution of the present application does not exclude the situation where there are other units (modules) and steps that are not directly or clearly stated. Terms such as "first" and "second" do not indicate the order of units in terms of time, space, size, etc., but are only used to distinguish each unit. Moreover, the steps in this article are not limited to being implemented in the order of writing, but the steps written later can also be implemented at the same time as the steps written earlier, or before the steps written earlier.
[0023] Hereinafter, various exemplary embodiments according to the present application will be described in detail with reference to the accompanying drawings.
[0024] Referring to the accompanying drawings, Figure 1 is a flowchart of a method 10 for collecting vehicle bus data according to an embodiment of the present application. As Figure 1 shown, in step S110, a collection configuration file is obtained. Specifically, when the vehicle is ignited and started, the vehicle queries whether the ignition count has reached the polling count, and the polling count can be set to a default value when the vehicle leaves the factory or modified during subsequent vehicle software upgrades. If the polling count has not been reached, the collection configuration file of the current vehicle end is used to collect vehicle bus data. If the polling count has been reached, the collection configuration file of the current vehicle end is transmitted to the server, and the server checks whether the collection configuration file of the current vehicle end needs to be updated. If an update is required, the server sends the updated collection configuration file to the vehicle; otherwise, the server indicates to the vehicle that there is no collection configuration file available for update, and the vehicle still uses the collection configuration file of the current vehicle end. Through wireless communication between the vehicle and the server, the collection configuration file can be updated periodically from the server. After receiving the updated collection configuration file from the server, the vehicle verifies the updated collection configuration file, and the verification includes verification of the collection configuration file and verification of the impact of the collection tasks in the collection configuration file on the vehicle, and returns the verification result to the server. Among them, the impact of the collection tasks on the vehicle includes the impact on the vehicle's computing resources, the driving experience, the vehicle's response speed, or the like. When both the verification of the collection configuration file and the verification of the impact of the collection tasks pass, the vehicle uses the updated collection configuration file; otherwise, the vehicle still uses the collection configuration file of the current vehicle end.
[0025] Next, in step S120, based on the collection configuration file, the data type of the data to be collected, the collection mode corresponding to the data type, and the trigger condition of the collection mode are determined. The collection configuration file includes the data type of the data to be collected, the collection mode corresponding to the data type, the trigger condition of the collection mode, and other parameters related to vehicle bus data collection. In some embodiments, the data type may include one or more data types. For example, CAN_ID1, CAN_ID2, CAN_ID3, and CAN_ID4. The data of these data types can come from the same or different electronic control units (ECUs) on the vehicle. In other embodiments, the data type may also include more or fewer data types.
[0026] The acquisition modes corresponding to the data types may include: periodic acquisition mode, event-based acquisition mode, and scenario-based acquisition mode. For example, CAN_ID1 and CAN_ID2 may correspond to the periodic acquisition mode, CAN_ID3 may correspond to the event-based acquisition mode, and CAN_ID4 may correspond to the scenario-based acquisition mode. In other embodiments, the correspondence between CAN_ID1, CAN_ID2, CAN_ID3, and CAN_ID4 and the acquisition modes may also vary.
[0027] In addition, the acquisition profile further includes parameters of the acquisition mode for guiding the data acquisition process. In some embodiments, the parameters may include parameters indicating when the data acquisition in the corresponding acquisition mode starts (i.e., trigger condition), parameters indicating when the data acquisition in this acquisition mode ends (termination condition), parameters indicating how the data acquisition in this acquisition mode operates (operation condition), and the like. In some embodiments, the trigger condition of the periodic acquisition mode may be the timing of reaching each period, the trigger condition of the event-based acquisition mode may be that one or more vehicle bus data indicate that a predetermined event occurs, and the trigger condition of the scenario-based acquisition mode may be that one or more vehicle bus data satisfy one or more relationships. The predetermined events may include an acceleration event, an overtaking event, and an emergency braking event. The one or more relationships include greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, or not equal to a threshold. In other embodiments, the one or more relationships may further include a relative magnitude relationship between one or more vehicle bus data, or a relative magnitude relationship between certain types of vehicle bus data at different times.
[0028] In some embodiments, for data of types CAN_ID1 and CAN_ID2, both of which correspond to a periodic acquisition mode. However, in the acquisition profile, by way of example, the acquisition frequency of the periodic acquisition mode corresponding to CAN_ID1 is 10 Hz, and the acquisition frequency of the periodic acquisition mode corresponding to CAN_ID2 is 100 Hz. Therefore, the trigger condition for the periodic acquisition mode corresponding to CAN_ID1 is the timing of every 0.1 s, and the trigger condition for the periodic acquisition mode corresponding to CAN_ID2 is the timing of every 0.01 s. For data of type CAN_ID3, it corresponds to an event-based acquisition mode. By way of example, the trigger condition for the event-based acquisition mode is that one or more vehicle bus data indicate that an acceleration event has occurred, where the one or more vehicle bus data may include data indicating the depth of the accelerator pedal and data indicating the engine speed. In other embodiments, depending on the definition of the data types of CAN_ID1, CAN_ID2, CAN_ID3, and CAN_ID4, the one or more vehicle bus data may also include one or more types of data among CAN_ID1-4. For data of type CAN_ID4, it corresponds to a scenario-based acquisition mode. By way of example, the trigger condition for the scenario-based acquisition mode is that the first vehicle bus data is greater than the first threshold and the second vehicle bus data is greater than the second threshold, where the first vehicle bus data may be data indicating the in-vehicle temperature, and the second vehicle bus data may be data indicating the out-of-vehicle ambient temperature. As another example, the trigger condition for the scenario-based acquisition mode is that the first vehicle bus data at a certain moment is greater than the first vehicle bus data at the previous moment and the second vehicle bus data is greater than the second threshold. As a further example, the trigger condition for the scenario-based acquisition mode is that the first vehicle bus data is greater than the second vehicle bus data. In other embodiments, depending on the definition of the data types of CAN_ID1, CAN_ID2, CAN_ID3, and CAN_ID4, the one or more vehicle bus data may also include one or more types of data among CAN_ID1-4.
[0029] Continue to refer to Figure 1, in step S130, monitor the vehicle bus data to determine whether the trigger condition is satisfied. After determining in step S120 when and in what acquisition mode to acquire which types of data based on the acquisition profile, in step S130, monitor various vehicle bus data during vehicle operation to determine whether the trigger condition is satisfied or when it is satisfied. Exemplarily, monitor the clock signal data of the vehicle. Whenever the timing of 0.01 s is reached, the trigger condition for the periodic acquisition mode corresponding to CAN_ID2 is satisfied; whenever the timing of 0.1 s is reached, the trigger condition for the periodic acquisition mode corresponding to CAN_ID1 is satisfied; monitor one or more vehicle bus data indicating an acceleration event. When the one or more vehicle bus data indicate that an acceleration event is occurring, the trigger condition for the event-based acquisition mode corresponding to CAN_ID3 is satisfied; monitor the relationship between the first and second vehicle bus data indicating a certain scenario and the corresponding thresholds. When the first vehicle bus data is greater than the first threshold and the second vehicle bus data is greater than the second threshold, the trigger condition for the event-based acquisition mode corresponding to CAN_ID4 is satisfied.
[0030] After that, in step S140, in response to one or more of the trigger conditions being satisfied, acquire one or more types of data among the data types. Specifically, in some embodiments, whenever the timing of 0.01 s is reached (i.e., the trigger condition for the periodic acquisition mode corresponding to CAN_ID2), acquire the data of the data type of CAN_ID2; whenever the timing of 0.1 s is reached (i.e., the trigger condition for the periodic acquisition mode corresponding to CAN_ID1), acquire the data of the data type of CAN_ID1; when one or more vehicle bus data indicate that an acceleration event occurs, acquire the data of the data type of CAN_ID3; when the first vehicle bus data is greater than the first threshold and the second vehicle bus data is greater than the second threshold, acquire the data of the data type of CAN_ID3.
[0031] For the periodic acquisition mode, since its trigger condition is usually the arrival of a fixed time, as long as the vehicle running time is longer than the period of the periodic acquisition mode, the trigger condition will surely be met. Therefore, the periodic acquisition mode is generally applicable to basic data that needs to be acquired regularly. However, for the event-based acquisition mode and the scenario-based acquisition mode, during the entire vehicle operation, the trigger condition is only met when a predetermined event or a specified scenario occurs. Therefore, during some vehicle operations (for example, during a certain journey), the acquisition of data of the data types corresponding to these acquisition modes may not occur. In contrast, the event-based acquisition mode and the scenario-based acquisition mode are more suitable for advanced data of specific working conditions. Further, the predetermined event may be a general common event or a universal event, and there is a limited number of them; for special events, special working conditions that are difficult to define, or a comprehensive working condition formed by combining one or more events, they can be defined through a specified scenario, which can be extended or modified as the version is updated. In this way, the acquisition of vehicle bus data can be customized, so as to only acquire data under certain events or specific working conditions, in order to further focus on engineering optimization and after-sales problem troubleshooting in certain aspects. Exemplarily, when a manufacturer hopes to acquire the battery power consumption data of a vehicle when it is running at high speed in a low-temperature environment, if it is acquired through the periodic acquisition method, a large amount of useless data may be acquired, which brings inconvenience to resources and subsequent data processing; if it is acquired through the acquisition mode based on the low-temperature event, a lot of data of the vehicle running at low speed in the low-temperature environment will also be acquired (these data may not be substantially helpful for the research on running at high speed in the low-temperature environment). Therefore, by adding the definition of this scenario to the acquisition configuration file, only the vehicle bus data under this scenario can be acquired for research and analysis, without the need to acquire the vehicle bus data of all working conditions and then filter them, so that the savings of acquisition, transmission, and storage resources can be achieved through the reasonable utilization of the vehicle's computing resources.
[0032] Further, as mentioned above, the acquisition configuration file includes parameters indicating when the data acquisition in the corresponding acquisition mode starts (i.e., the trigger condition), parameters indicating when the data acquisition in this acquisition mode ends (the termination condition), and parameters indicating how the data acquisition in this acquisition mode operates (the operation condition). Therefore, the acquisition of one or more types of data in the data types includes: acquiring the one or more types of data for a period of time (based on the trigger condition and the termination condition); acquiring all the one or more types of data until the end of this journey (only based on the trigger condition); and acquiring the one or more types of data at a specific moment (based on the operation condition). In this way, the acquisition, transmission, and storage resources can be further reduced.
[0033] Then, in step S150, the collected data is formed into data packets, and the data packets are sent to the server. The operation of forming data packets can be performed periodically or at a specified time. Further, after forming the data packets, compression of the data packets can also be performed to ensure the economy of data packet transmission. When the vehicle is turned off, data collection stops, but the data packets being transmitted are continued to be transmitted, and the data packets that have been formed but not yet transmitted are saved in the non-volatile memory. Since the vehicle network environment may be unstable, situations such as network disconnection or weak network are likely to occur, resulting in an unstable or disconnected link with the server. Therefore, after the data packets are compressed or generated, the data packets are first stored in the volatile memory, and then after the data packets are successfully transmitted to the server, the locally stored data packets are deleted. When the vehicle cannot establish a network connection with the server, reconnection attempts are made a predetermined number of times at a predetermined interval, and the predetermined interval or the predetermined number of times can be modified during the software upgrade process or manually by the user. When the reconnection attempts a predetermined number of times all fail, no more connection attempts are made within the current trip, and the data packets are directly stored in the non-volatile memory. In the next trip, the data packets are transmitted again. In some embodiments, in order to protect the service life of the non-volatile memory, certain restrictions are imposed on the writing of the non-volatile memory. Specifically, when it is determined that the vehicle is in a long-term network disconnection state, data packets are no longer written into the non-volatile memory.
[0034] Figure 2 FIG. 20 is a schematic diagram showing the transfer of vehicle bus data from vehicle 200 to server 250 according to an embodiment of the present application. As Figure 2 shown, vehicle 200 communicates wirelessly with remote server 250 through communication module 210. Vehicle 200 includes a plurality of ECUs (240A, 240B, 240C, 240D), and the plurality of ECUs are used to control different functions of the vehicle and implement communication between various units of the vehicle via the CAN bus. Vehicle 200 also includes gateway 220, and gateway 220 can receive most of the CAN bus data of the vehicle. According to one or more embodiments of the present application, data acquisition system 230 is deployed in gateway 220 to facilitate obtaining vehicle bus data. Data acquisition system 230 implements the processes of acquisition configuration file acquisition and parsing, vehicle bus data monitoring, data acquisition and packaging, and data transmission in gateway 220.
[0035] Refer to Figure 3 , Figure 3Schematic diagram of a system 30 for collecting vehicle bus data according to an embodiment of the present application. The system 30 includes a processor 320; a memory 310; and a computer program 330, the computer program 330 being stored on the memory 310 and executable by the processor 320, the running of the computer program 330 causing the method for collecting vehicle bus data as Figure 1 shown to be executed.
[0036] In addition, as described above, the present application can also be implemented as a computer-readable storage medium in which a program for causing a computer to execute the method as Figure 1 shown is stored. Here, as the computer-readable storage medium, various types of computer-readable storage media such as disk types (e.g., magnetic disks, optical disks, etc.), card types (e.g., memory cards, optical cards, etc.), semiconductor memory types (e.g., ROM, non-volatile memories, etc.), tape types (e.g., magnetic tapes, cassette tapes, etc.) can be adopted.
[0037] The present application can also be implemented as a computer program product that includes a computer program which, when executed by a processor, implements the program of the method as Figure 1 shown.
[0038] In applicable cases, various embodiments provided by the present application can be implemented using hardware, software, or a combination of hardware and software. Moreover, in applicable cases, without departing from the scope of the present application, the various hardware components and / or software components described herein can be combined into composite components including software, hardware, and / or both. In applicable cases, without departing from the scope of the present application, the various hardware components and / or software components described herein can be divided into sub-components including software, hardware, or both. Additionally, in applicable cases, it is contemplated that software components can be implemented as hardware components, and vice versa.
[0039] The software according to the present application (such as program code and / or data) can be stored on one or more computer-readable storage media. It is also contemplated that one or more general-purpose or special-purpose computers and / or computer systems connected by a network and / or in other ways can be used to implement the software identified herein. In applicable cases, the order of the various steps described herein can be changed, combined into composite steps, and / or divided into sub-steps to provide the features described herein.
[0040] Embodiments and examples presented herein are provided to best illustrate embodiments in accordance with the present application and its specific applications, and thereby enable those skilled in the art to implement and use the present application. However, those skilled in the art will know that the above description and examples are provided for purposes of illustration and example only. The presented description is not intended to cover every aspect of the present application or to limit the present application to the precise form disclosed.
Claims
1. A method for collecting vehicle bus data, the method comprising: Obtaining a collection configuration file; Based on the collection configuration file, determining the data type of the data to be collected, the collection mode corresponding to the data type, and the trigger condition of the collection mode; Monitoring vehicle bus data to determine whether the trigger condition is satisfied; In response to one or more of the trigger conditions being satisfied, collecting one or more types of data among the data types; Forming the collected data into a data packet and sending the data packet to the server.
2. The method according to claim 1, further comprising periodically updating the collection configuration file from the server.
3. The method according to claim 1, wherein The collection mode includes: a periodic collection mode, an event-based collection mode, and a scenario-based collection mode.
4. The method according to claim 3, wherein The trigger condition of the periodic collection mode is the timing of reaching each period, the trigger condition of the event-based collection mode is that one or more vehicle bus data indicate that a predetermined event occurs, and the trigger condition of the scenario-based collection mode is that one or more vehicle bus data satisfy one or more relationships.
5. The method according to claim 4, wherein The predetermined events include an acceleration event, an overtaking event, and an emergency braking event.
6. The method according to claim 4, wherein, The one or more relationships include the relative magnitude relationship between the one or more vehicle bus data and one or more thresholds, the relative magnitude relationship between the one or more vehicle bus data, and the relative magnitude relationship between the vehicle bus data in the one or more vehicle bus data at different times.
7. The method according to claim 1, wherein Collecting one or more types of data among the data types includes: collecting one or more types of data for a period of time; collecting all one or more types of data until the end of this trip; and collecting one or more types of data at a specific moment.
8. A system for collecting vehicle bus data, the system being deployed in the gateway of a vehicle, the system comprising: A processor; A memory; And A computer program, the computer program being stored on the memory and being executable on the processor, the execution of the computer program causing the method according to any one of claims 1-7 to be executed.
9. A computer-readable storage medium, the computer-readable storage medium comprising instructions that, when run, execute the method according to any one of claims 1-7.
10. A computer program product, the computer program product comprising instructions that, when run, execute the method according to any one of claims 1-7.