Data collection method, device and apparatus, and medium, program product and vehicle

Abstract

A data collection method, device and apparatus, and a medium, a program product and a vehicle. The method comprises: acquiring a target rule tree to be executed; and on the basis of node information in the target rule tree, collecting vehicle data.

Description

Data acquisition methods, equipment, devices, media, software products, and vehicles

[0001] This application claims priority to Chinese patent application filed on February 26, 2025, application number 202510227878.7, entitled "Data Acquisition Method, Equipment, Apparatus, Medium, Program Product and Vehicle", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of data acquisition technology, and in particular to a data acquisition method, device, apparatus, medium, program product, and vehicle. Background Technology

[0003] Vehicle-side data acquisition is a technology that has emerged with the upgrade of vehicle-to-everything (V2X) networks and the rapid development of vehicle intelligence. It collects traditional vehicle status information, environmental information, driver behavior information, and intelligent sensing information from cameras, radar, and IMU (Inertial Measurement Unit) via CAN or in-vehicle Ethernet. However, current vehicle data acquisition uses a fixed set of procedures, which are overly redundant and difficult to implement in a lightweight manner. Technical solutions

[0004] This application provides a data acquisition method, device, apparatus, medium, program product, and vehicle, which improves the lightweight nature of data acquisition and at least partially solves the aforementioned technical problems. The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0005] To achieve the above objectives, according to a first aspect of this application, a data acquisition method is provided, the data acquisition method comprising:

[0006] Obtain the target rule tree to be executed;

[0007] Vehicle data is collected based on the node information in the target rule tree.

[0008] According to a second aspect of this application, a data acquisition device is also provided, including a processor connected to a memory storing computer instructions, the processor being configured to execute the computer instructions in the memory to perform any of the above-described data acquisition methods.

[0009] According to a third aspect of this application, a data acquisition device is provided, comprising:

[0010] A rule engine is used to obtain a target rule tree to be executed and to collect vehicle data based on the node information in the target rule tree.

[0011] According to a fourth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, which, when executed by a processor, constitute any of the above-described data acquisition methods.

[0012] According to a fifth aspect of this application, a computer program product is provided, comprising computer instructions that are executed by a processor to implement any of the above-described data acquisition methods.

[0013] According to a sixth aspect of this application, a vehicle is provided that performs the data acquisition method described above, or includes the data acquisition device or equipment described above.

[0014] In summary, the embodiments of this application, through the above technical solution, collect vehicle data using node information in the target rule tree. This collection rule, presented as a collection rule node tree, is independent of the data collection process, helping to make data collection more lightweight.

[0015] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

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

[0017] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0018] Figure 1 is a flowchart illustrating one embodiment of the data acquisition method provided in some embodiments of this application;

[0019] Figure 2 is a schematic diagram of the structure of the rule tree provided in some embodiments of this application;

[0020] Figure 3 is a schematic diagram of a data acquisition scenario provided in some embodiments of this application;

[0021] Figure 4 is a schematic diagram of the algorithm mapping structure provided in some embodiments of this application;

[0022] Figure 5 is a schematic diagram of the structure of a rule tree in a specific application example provided in some embodiments of this application;

[0023] Figure 6 is a schematic diagram of the structure of the data acquisition device provided in some embodiments of this application;

[0024] Figure 7 is a schematic diagram of the data acquisition process in a specific application example provided in some embodiments of this application;

[0025] Figure 8 is a schematic diagram of the structure of the data acquisition device provided in some embodiments of this application.

[0026] Implementation methods of this application

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0028] Based on the problems mentioned in the background technology, vehicle-side data acquisition is a technology that has emerged with the rapid development of vehicle networking and vehicle intelligence. It collects traditional vehicle status information, environmental information, driver behavior information, and intelligent sensing information from cameras, radar, and IMU (Inertial Measurement Unit) via CAN or in-vehicle Ethernet. However, current vehicle data acquisition uses a fixed acquisition program, which is overly redundant and difficult to implement in a lightweight manner.

[0029] Furthermore, vehicle-side data comes from a wide range of sources, including operational status data of various vehicle components, driver behavior data generated from interactions between the vehicle and the driver, and control data generated from in-vehicle interactions. With the development of vehicle intelligence and the increase in smart terminals, the sources of vehicle-side data are becoming increasingly diverse, and the volume of data is increasing exponentially. In addition, the requirements for collecting vehicle-side data are not static; the data required for various data analysis tasks frequently change with business needs and model parameters.

[0030] Traditional vehicle-side data collection strategies involve selecting certain key data points and discarding others. This mechanical approach to data collection has significant limitations in terms of the dimensions and breadth of data collected. More importantly, when new data collection needs arise, the program requires secondary development and re-adaptation, which is unsuitable for rapidly updating data collection requirements.

[0031] The inventors discovered that for critical signals generated by vehicle-side components, it's not necessary to collect all signals generated by that component; similarly, for less critical signals generated by other components, not all data from those components is unnecessary. In fact, what truly needs to be collected is the data at a specific point in time or over a period of time when a component reaches a particular state. More importantly, vehicle-side components are often interconnected, and frequently it's necessary to collect data on when one or more components reach a certain state, and when another one or more components reach their specific state. Based on these findings, it's not necessary to collect all data generated by all component terminals, but rather to formulate corresponding collection rules and collect the key data defined at the moment the event occurs. Simultaneously, it's crucial to flexibly configure collection rules based on collection requirements to reduce program coupling and avoid repetitive, mechanical development.

[0032] In some related solutions, it is mainly used for the collection and analysis of user tracking points, but it is not suitable for the collection of massive vehicle-side data required for large-scale model analysis. Although the tracking point data is configurable, the collection rules are not explained in detail. In addition, when there is coupling between the rules, the data cannot be collected effectively.

[0033] In some related solutions, it is mainly used to collect user driving data points to achieve the customization of user-specific driving behavior and improve the user driving experience, rather than to be applied to the ever-changing and increasing data collection needs.

[0034] In some related solutions, traditional methods are used to collect CAN messages, and incomplete messages are filtered to avoid invalid collection during the collection process. However, this approach is not suitable for the collection of massive and frequently changing data.

[0035] It is evident that current vehicle-side data collection strategies are too simplistic and cannot cope with the ever-increasing volume of data and the data collection needs in complex scenarios. The data filtering and extraction levels are also low. At the same time, traditional data collection strategies are too closely coupled with programs and cannot be flexibly configured according to the collection needs.

[0036] To address the aforementioned issues, this application proposes a data acquisition method, device, apparatus, medium, program product, and vehicle. This application acquires vehicle data based on node information in the target rule tree, providing a comprehensive, adaptable, lightweight, and easy-to-maintain data acquisition strategy. This approach can meet the ever-increasing data demands, improve data acquisition efficiency and accuracy, and alleviate data storage pressure.

[0037] Specifically, the data acquisition method in this application can be applied to a data acquisition device or a vehicle, and the data acquisition device can also be a vehicle or installed on a vehicle. The following description uses a vehicle as an example to illustrate the various embodiments.

[0038] This application provides a data acquisition method. Please refer to Figure 1. The data acquisition method provided in this application includes steps S10-S20, which will be described in detail below.

[0039] S10. Obtain the target rule tree to be executed;

[0040] In this embodiment, specific data collection requirements and a corresponding set of collection rules are designed to address the different data collection needs of the data requester. These rules trigger data collection operations that satisfy the data collection requirements. When the set of collection rules is met, the corresponding data collection operation can be triggered to collect vehicle data, ultimately obtaining the vehicle data required by the data requester. In this embodiment, a set of collection rules includes at least one collection rule. Each set of collection rules can be assembled into different rule trees, which can serve as target rule trees to trigger data collection operations for collecting vehicle data.

[0041] In this embodiment, there may be one or more rule trees, from which the target rule tree to be executed can be obtained.

[0042] S20. Collect vehicle data based on the node information in the target rule tree.

[0043] In this embodiment, the target rule tree contains the triggering logic for the collection rules, and this triggering logic determines the node information of the target rule tree. After obtaining the target rule tree, based on the node information of the target rule tree, it is determined whether to trigger a data collection operation. If it is determined that a data collection operation can be triggered, then vehicle data is collected. The collected data can be the data collected by the triggering rule tree corresponding to the target rule tree. The method and content of collecting the data collected by the triggering rule tree can be determined based on the collection requirement information associated with the target rule data.

[0044] In the technical solution disclosed in this embodiment, a target rule tree to be executed is obtained, and vehicle data is collected based on the node information in the target rule tree. This way, the collection rules are presented in the form of a collection rule node tree, independent of the data collection process, which helps to make data collection more lightweight.

[0045] In one embodiment, vehicle data is collected based on node information in the target rule tree, including:

[0046] The target rule tree is executed based on the node information in the target rule tree, and the execution result of the target rule tree is determined.

[0047] Based on the execution results of the target rule tree, the vehicle data is collected.

[0048] In this embodiment, when determining the target rule tree, execution of the target rule tree begins based on the node information within it. The execution process relies on this node information, which determines the data collection rules and their connections. By analyzing these rules and connections, the execution result of the target rule tree can be determined. Based on the execution result, a decision is made on whether to trigger a data collection operation to collect the vehicle data required by the client.

[0049] Based on the execution results of the target rule tree, data corresponding to the target rule tree is collected from the target object, further decoupling the collection program from the collection process and further lightweighting the data collection.

[0050] In one embodiment, executing the target rule tree based on the node information in the target rule tree and determining the execution result of the target rule tree includes:

[0051] Execute the target rule tree based on the node information in the target rule tree, and determine the triggering state of the rule tree nodes in the target rule tree;

[0052] The execution result of the target rule tree is determined based on the triggering status of the rule tree nodes.

[0053] In this embodiment, for each rule tree node in the target rule tree, the triggering state of the rule tree node is determined according to the node information corresponding to the rule tree node. The triggering state can characterize the triggering state of the collection rule corresponding to the rule tree node, that is, whether the state of a certain component in the vehicle meets the data collection requirements. Based on the triggering states of several rule tree nodes in the target rule tree, the execution result of the target rule tree can be determined.

[0054] In some embodiments, referring to FIG2, the rule tree including the target rule tree is a multi-way tree. Unlike a binary tree, each node may have any number of child nodes, typically 0, 1, 2, 3, or 4. On the other hand, the depth of the rule tree can also be arbitrarily configured, typically within 5 levels.

[0055] In one embodiment, the node information includes collection rules. The target rule tree is executed based on the node information in the target rule tree, and the triggering state of the rule tree nodes in the target rule tree is determined, including:

[0056] Map the data collection rules to rule algorithms;

[0057] The target rule tree is executed based on the execution rule tree data corresponding to the target rule tree and the rule algorithm. The triggering state of the rule tree node is determined, and the execution rule tree data is the vehicle data required to execute the target rule tree.

[0058] In this embodiment, vehicle data required for executing the target rule tree needs to be acquired as the execution rule tree data. This execution rule tree data is used to determine the triggering state of rule tree nodes during execution. The execution rule tree data needs to be distinguished from the trigger rule tree data mentioned above.

[0059] Execution rule tree data refers to the data involved in determining whether the current state of a certain component meets the collection rules defined by the rule tree node when executing the target rule tree; while triggering rule tree data collection occurs when the execution result of the target rule tree meets the defined collection rules, that is, when the execution result of the target rule tree is successful, triggering the data collection operation corresponding to the target rule tree to collect vehicle data, which is the data required by the data requester corresponding to the target rule tree.

[0060] During the data acquisition process, the execution rule tree data is the input data fed into the rule engine, while the trigger rule tree data acquisition is the output data of the rule engine, which is the data finally acquired by the data acquisition device.

[0061] In the target rule tree, some rule tree nodes contain specific data collection rules. For each collection rule, its semantics are abstracted through parsing and mapped to a specific rule algorithm, thus mapping these collection rules to rule algorithms. A collection rule can be mapped to at least one rule algorithm. The rule algorithm is executed based on the execution rule tree data. The rule algorithm is used to determine the trigger state of the corresponding rule tree node. Based on the real-time execution results of the rule algorithm, the trigger state of the corresponding rule tree node can be determined. In this way, the trigger state of the rule tree node can be quickly and accurately determined through algorithm mapping.

[0062] In some embodiments, the execution rule tree data required for the collection rule corresponding to the rule tree node is determined from the execution rule tree data required for executing the target rule tree. The execution rule tree data corresponding to the rule tree node is also the data required by the rule algorithm corresponding to the rule tree node. During the execution of the target rule tree, the execution rule tree data corresponding to the rule tree node needs to be processed according to the rule algorithm of the rule tree node to determine the triggering state of the rule tree node, so as to indicate whether the collection rule corresponding to the rule tree node is triggered.

[0063] In this embodiment, by using the execution rule tree data corresponding to the target rule tree and the rule algorithm corresponding to the rule tree node, the triggering state of the rule tree node can be quickly determined, thereby improving the efficiency of executing the target rule tree.

[0064] In one embodiment, the rule algorithm includes at least one of a jump algorithm, a threshold algorithm, and a range algorithm.

[0065] In this embodiment, each rule tree node corresponds to a collection rule, which serves as node information. Each collection rule can correspond to at least one simple rule, which may include at least one of jump rules, threshold rules, and interval rules, corresponding to jump algorithms, threshold algorithms, and interval algorithms, respectively. Data collection involves a wide variety of rules; any component on the vehicle body may correspond to dozens or even more rules. With the development of automotive intelligence and electrification, the amount of vehicle body data has increased dramatically, and the rules for vehicle body data collection have become increasingly diverse. However, this embodiment maps the complex and numerous collection rules to three simple rule algorithms: threshold algorithm, jump algorithm, and interval algorithm.

[0066] Jump Algorithm: For discrete signals generated by certain vehicle-end components, it is sometimes necessary to capture the change from one value to another. For such rules, they are mapped to jump algorithms for execution.

[0067] Threshold algorithm: For signals generated by certain vehicle-end components, it is sometimes necessary to capture the moment when the signal is greater than, equal to or less than a certain threshold. For such rules, they are mapped to a threshold algorithm for execution.

[0068] Interval Algorithm: For signals generated by certain vehicle-end components, it is sometimes necessary to capture the moment when the signal value enters a certain interval. For such rules, they are mapped to the interval algorithm for execution.

[0069] When configuring data collection rules, the rules can be configured according to the format specified by the algorithm to form simple rules, so that they can be mapped to rule algorithms containing simple rule algorithms in the future, thereby improving processing efficiency.

[0070] Referring to Figure 4, the collection rules in the node information of all or part of the rule tree nodes in the target rule tree are mapped to rule algorithms that include at least one simple rule algorithm.

[0071] By mapping the rules into algorithms, complex and abstract data collection rules are parsed into three specific and simple rules. This allows the data collection program to execute the corresponding rules instead of adapting to each specific rule, thereby further improving the lightweight nature and efficiency of data collection.

[0072] In some embodiments, when performing algorithm mapping, semantic analysis can be performed on the collection rules of the rule tree nodes. By performing semantic analysis on the collection rules involved in vehicle-side data collection, it can be found that the numerous collection rules can ultimately be abstracted into a rule algorithm that includes at least one of the jump algorithm, threshold algorithm, and interval algorithm.

[0073] In one embodiment, before mapping the collection rules to a rule algorithm, the method further includes:

[0074] Retrieve the execution rule tree data corresponding to the target rule tree from the vehicle data stored in the data storage device.

[0075] In this embodiment, referring to FIG3, the vehicle may include a rule engine and a data storage device. The rule engine is mainly used to execute the data acquisition method provided in this embodiment to drive the execution of the target rule tree. The data storage device may be a Redis database, etc. It can access and store real-time vehicle data through CAN or vehicle Ethernet. The vehicle data required to execute the target rule tree can be obtained from the data storage device as the execution rule tree data.

[0076] In one embodiment, vehicle data is collected based on the execution result of the target rule tree, including:

[0077] If the execution is successful, vehicle data will be collected.

[0078] In this embodiment, the target rule tree is executed. If the execution result of the target rule tree is successful, a data collection operation can be triggered to collect vehicle data to obtain the data collected by the trigger rule tree corresponding to the target rule tree. The collected vehicle data is then placed in the database for easy access by the data requester.

[0079] In some embodiments, by checking the triggering states of the bottom-level rule tree nodes in the target rule tree, the triggering states of other rule tree nodes can be checked layer by layer upwards to finally determine the triggering state of the head node in the target rule tree. Based on the determined triggering state of the head node in the target rule tree, the execution result of the target rule tree is determined. When the triggering state of the head node is "triggered", it can be indicated that the execution result of the target rule tree is successful. If the execution result of the target rule tree is successful, a data collection operation can be triggered to collect vehicle data to obtain the vehicle data required by the requester.

[0080] In one embodiment, collecting vehicle data based on the execution result of the target rule tree further includes:

[0081] Based on the execution results of the target rule tree, obtain the collection requirement information associated with the target rule tree;

[0082] Based on the information required for data collection, vehicle data stored in the data storage device is collected.

[0083] In some embodiments, the data collection requirement information includes at least one of the following: data type, collection time, and collection frequency.

[0084] In this embodiment, the vehicle data stored in the data storage can be used as execution rule tree data and / or trigger rule tree acquisition data. When executing the target rule tree, the rule engine can retrieve the corresponding execution rule tree data from the data storage to execute the target rule tree. Alternatively, it can acquire the vehicle data stored in the data storage based on the execution result of the target rule tree to obtain the trigger rule tree acquisition data corresponding to the target rule tree.

[0085] It should be noted that the data collected by the trigger rule tree is not entirely the same as the data collected by the execution rule tree. In collecting demand information, more often than not, when certain parts of the vehicle reach a certain state, other data related to those parts are collected. Here, the data collected by the trigger rule tree is generally the data collected by the execution rule tree, while the data related to those parts is the data collected by the trigger rule tree.

[0086] In this embodiment, when the execution result meets the defined collection rules, that is, when the execution result is successful, the target rule tree is executed to trigger the data collection operation, collect the vehicle data corresponding to the collection requirement information defined by the target rule tree, and store it in the database so that the requesting party can obtain it.

[0087] The data collection requirement information is associated with the target rule tree and also corresponds to the collection rules of that target rule tree. This data collection requirement information can be placed in the rule file containing the target rule tree. In some embodiments, after receiving the rule file, the rule tree and its associated data collection requirement information can be assembled by parsing the rule file. The data collection requirement information includes the data type to be collected, the collection time and / or the collection frequency, etc. According to the requirements of the data collection requirement information, the vehicle data stored in the data storage is collected to obtain the aforementioned trigger rule tree collection data, which is then stored in the corresponding database for data requesters to access.

[0088] This approach, using the target rule tree to associate with the data collection requirements, allows for the accurate collection of data that meets the needs. Furthermore, the specific data to be collected is not determined by the collection program, but rather by the data collection requirements associated with the target rule tree—essentially by the rule file. Therefore, when data collection requirements change, only the collection requirements information in the rule file needs updating. The data collection requirements information and the program executing the rule tree are not coupled, eliminating the need for secondary development. Simultaneously, users do not need to understand the program's internal implementation. When new requirements change, the rule file is modified according to the multi-branch rule tree structure and distributed to the vehicle. The vehicle automatically parses the new rule file and updates the corresponding rule tree. This rule engine logic greatly enhances the system's versatility and universality.

[0089] In one embodiment, the node information includes the connection relationship of rule tree nodes. Executing the target rule tree based on the node information in the target rule tree and determining the triggering state of the rule tree nodes includes:

[0090] Execute the target rule tree based on the connection relationship of the rule tree nodes, and determine the child nodes corresponding to the rule tree nodes;

[0091] The triggering state of a rule tree node is determined based on the triggering state of its child nodes.

[0092] In this embodiment, each rule tree node in the target rule tree essentially corresponds to a data acquisition rule. The inventors discovered that in vehicle data acquisition scenarios, each acquisition rule can be converted into at least one simple rule. This simple rule can be a threshold rule, a jump rule, or a range rule, corresponding to the threshold algorithm, jump algorithm, and range algorithm mentioned above, respectively. If an acquisition rule corresponds to one simple rule, it can be called a first-type rule; if an acquisition rule corresponds to multiple simple rules, it is called a second-type rule.

[0093] For the first type of rule, it can be mapped to a rule algorithm containing a simple rule algorithm using the above method, so as to independently determine the triggering state of its corresponding rule tree node. For the second type of rule, its corresponding rule tree node can be designed to be a rule tree node containing multiple child nodes. This rule tree node does not need to be mapped to a rule algorithm, while the child nodes of this rule tree can be mapped to a rule algorithm containing a simple rule.

[0094] In this embodiment, for the rule tree node corresponding to the second type of rule, the child nodes corresponding to the rule tree node can be determined from the connection relationship in its corresponding node information. Generally, if a rule tree node has child nodes, then it has at least two child nodes. The triggering state of the rule tree node can be determined based on the triggering state of its child nodes, eliminating the need to map the collection rule corresponding to the rule tree node to the rule algorithms corresponding to multiple simple collection rules, thus improving processing efficiency.

[0095] In one embodiment, the collection rule for a bottom-level node in the rule tree is a simple rule, while the collection rules for non-bottom-level nodes in the rule tree correspond to at least two simple rules. For bottom-level nodes, their collection rules can be mapped to simple rule algorithms, and the triggering state of the bottom-level nodes can be determined based on the executed rule tree data and the collection rules. For non-bottom-level nodes, the triggering state of the non-bottom-level nodes needs to be determined based on the triggering states of their corresponding child nodes. In this way, the triggering states of the rule tree nodes can be determined layer by layer upwards during the execution of the target rule tree, ultimately determining the triggering state of the head node in the target rule tree. Based on the determined triggering state of the head node in the target rule tree, the execution result of the target rule tree can be determined.

[0096] In one embodiment, determining the triggering state of a rule tree node based on the triggering state of its child nodes includes:

[0097] The triggering state of the rule tree node is determined based on the triggering state of the child node and the logical relationship between the child nodes.

[0098] In this embodiment, for the second type of rule, it is also necessary to determine the logical relationship between at least two simple rules based on the collection rule. Based on these simple rules and their logical relationships, a complete collection rule can be formed. Correspondingly, there are also logical relationships between the child nodes of the rule tree node. Based on the connection relationship, the logical relationship between the corresponding child nodes of the rule tree node can also be determined to characterize the collection rules corresponding to the child nodes. Compared with the correlation between the collection rules corresponding to the rule tree node, based on the triggering state of the child nodes and the logical relationship between the child nodes, the collection rules of the rule tree node can be accurately and comprehensively characterized to accurately determine the triggering state.

[0099] In one example, referring to Figure 2, for a rule tree node, its corresponding child nodes have logical relationships to express the relevance of the collection rules corresponding to the child nodes. These logical relationships can include conjunctions and / or disjunctions. A conjunction indicates that the rules corresponding to two child nodes must be satisfied simultaneously, while a disjunction indicates that the rules corresponding to two child nodes only need to satisfy one of them. A conjunction is an AND relationship, represented by "and," and a disjunction is an OR relationship, represented by "or." By configuring this rule tree, it can be flexibly configured according to the relevance between rules, adapting to complex collection needs and accurately collecting the required data.

[0100] In one embodiment, the child nodes corresponding to the rule tree nodes have a judgment order. Therefore, in the above logical relationship, the child nodes with adjacent judgment orders can have a logical relationship to avoid the situation of logical relationship contradiction.

[0101] In one embodiment, the target rule tree is configured with a time window, and at least one rule tree node in the target rule tree is the target rule tree node corresponding to the time window. The method further includes:

[0102] If the target rule tree node is in the triggered state, maintain the triggered state of the target rule tree node and start the time window.

[0103] In this embodiment, a time window can also be configured for the rule tree. If the target rule tree currently being executed is configured with a time window, then when the target rule tree node corresponding to the time window is triggered, the triggering state of the node needs to be maintained in the triggered state, and the time window needs to be started.

[0104] In one embodiment, after maintaining the triggering state of the target rule tree node and starting the time window, the method further includes:

[0105] If the execution result of the target rule tree is successful, stop maintaining the triggering state of the target rule tree nodes;

[0106] Alternatively, if the time window is closed, stop maintaining the triggering state of the target rule tree node.

[0107] In this embodiment, after maintaining the triggering state of the target rule tree node and starting the time window, the triggering state of the target rule tree node can be stopped until the execution result of the target rule tree is successful or the time window is closed.

[0108] In some embodiments, a preset opening duration for the time window can also be configured, and the time window can be closed when the preset opening duration is reached.

[0109] In some embodiments, by default, the target rule tree node corresponding to the time window can be any rule tree node in the target rule tree. In some embodiments, the target rule tree node corresponding to the time window can also be configured, thereby specifying all or some rule tree nodes in the target rule tree as the target rule tree node. By setting a time window, the data collection needs of another component reaching another state within a certain period of time after one component of the vehicle reaches a certain state can be effectively solved.

[0110] In this embodiment, the target rule tree is executed. If the execution result of the rule tree is successful, data collection can be triggered to collect data corresponding to the target rule tree from the target object, thereby obtaining the triggered rule tree collection data. This triggered rule tree collection data is then placed in a database for easy access by data requesters. In some embodiments, the execution result of the target rule tree to be executed is obtained by acquiring the trigger status of the head node in the target rule tree to be executed. When the trigger status of the head node is "triggered," it can be indicated that the execution result of the target rule tree is successful.

[0111] To better understand, a specific application example is provided below. Referring to Figure 5, the specific content described by this target rule tree is as follows:

[0112] Data Acquisition Rule 1: The previous frame entered automatic parking mode:

[0113] APA_Mode_S=0x1:EnterAutomaticParkingMode

[0114] Algorithm mapping: The APA_Mode_S signal transitions from other signals to 0x01. Based on this transition characteristic, it is mapped to a transition algorithm.

[0115] Data Acquisition Rule 2: The APA function identifies risks in the current frame and triggers emergency braking.

[0116] APA_FailureBrakeMode_S=0x2:EmergencyEmergencyBraking

[0117] Algorithm mapping: The APA_FailureBrakeMode_S signal changes from other signals to 0x02, which is mapped to the transition algorithm.

[0118] Data collection rule 3: The vehicle is in motion when data collection rule 2 is detected (data collection rule 3 is valid only if data collection rule 3.1 and data collection rule 3.2 are satisfied simultaneously);

[0119] Data Acquisition Rule 3.1: Vehicle speed status signal is available:

[0120] Vehicle_Speed_Stats_S = 0x0

[0121] Algorithm mapping: The Vehicle_Speed_Stats_S signal is equal to 0x00, which is mapped to the threshold algorithm.

[0122] Rule 3.2: Vehicle speed signal transmitted by IPB:

[0123] IPB_Vehicle_Speed_S>2km / h and IPB_Vehicle_Speed_S<12km / h

[0124] Algorithm mapping: The IPB_Vehicle_Speed_S signal is in the interval (2, 12), and is mapped to an interval algorithm.

[0125] Data collection rule 4: Braking deceleration not greater than -5 m / s².

[0126] IPB_AX_S <= -5m / s2

[0127] Algorithm mapping: IPB_AX_S signal less than or equal to threshold -5m / s², mapped to threshold algorithm;

[0128] Target rule tree trigger logic: Collect rule 1 && Collect rule 2 && Collect rule 3 && Collect rule 4;

[0129] Data collection rule 3: Data collection rule 3.1 || Data collection rule 3.2;

[0130] Data type to be collected:

[0131] 1. Forward-facing camera + panoramic camera;

[0132] 2. GNSS / IMU sensor data;

[0133] 3. Sensor output results;

[0134] 4. Planner output results;

[0135] 5. Positioner output results;

[0136] 6. Controller output results;

[0137] 7. Chassis output (chassis from the algorithm vendor);

[0138] Data collection duration: 30 seconds before and 10 seconds after the trigger time;

[0139] Time window: 3000ms.

[0140] The target rule tree described above has three layers. The first layer has one node, which is the head node. The second layer consists of four child nodes of the head node, and the relationships between these nodes are all "AND," meaning that the rules corresponding to all four nodes must be satisfied simultaneously to trigger the target rule tree. The third layer consists of two child nodes of the third node in the second layer, and the relationships between these nodes are "OR," meaning that if either of the two child nodes is triggered, the parent node will be triggered. When the rule engine executes the target rule tree, it maps each node to its corresponding algorithm, retrieves the real-time value of the signal corresponding to each node from the Redis database, determines whether the signal value satisfies the corresponding collection rule, and outputs the final execution result of the target rule tree based on the relationships between the nodes. If the rule engine determines that a signal needs to be collected, it collects the predefined signal. In this embodiment, after the target rule tree is triggered, a total of seven vehicle-end signals are collected, with a collection duration of 30 seconds before and 10 seconds after the collection time, and the collected data is stored in the database.

[0141] Furthermore, the target rule tree is configured with a time window of 3000 milliseconds. When any node in the target rule tree meets the trigger condition, the time window opens, and the node remains in a triggered state (even if the trigger condition is not met in the next moment). Once the target rule tree is triggered or the time window reaches 3000 milliseconds, the time window closes. For the above target rule tree, assuming rule 2 meets the condition first, the time window opens, and the rule 2 node remains in a triggered state. Once the target rule tree is triggered or the time window closes, the rule 2 node returns to a non-triggered state, and a new round of judgment is performed.

[0142] In one embodiment, obtaining the target rule tree to be executed includes:

[0143] Retrieve the target rule tree from the rule tree queue in the rule pool.

[0144] In this embodiment, referring to Figure 3, the rule engine also includes a rule pool and a rule executor. The rule pool stores a rule tree queue, which includes at least one rule tree. Each rule tree in the queue can serve as a target rule tree to be executed. The rule executor retrieves the rule tree queue, and the target rule trees in the queue are dequeued sequentially. The target rule tree is then executed based on its node information to collect vehicle data stored in the data storage based on the execution result of the target rule tree. When retrieving a target rule tree, it can be retrieved and executed sequentially from the rule tree queue to trigger data collection in an orderly manner.

[0145] In one embodiment, the method further includes:

[0146] Based on the rule file, determine the target rule tree;

[0147] Store the target rule tree in the rule tree queue.

[0148] In this embodiment, the target rule tree originates from a rule file defined based on the data collection requirements. The rule engine receives the rule file through its rule pool, parses it, assembles the target rule tree, and places it into a rule tree queue. The subsequent rule executor can then retrieve the target rule tree from the rule tree queue in the rule pool and execute it.

[0149] In some embodiments, a rule tree for triggering data collection can be predefined based on the collection requirements, and the defined rule tree can be put into a rule file and sent to the rule pool of the rule engine. The rule pool parses the rule file, converts the rule tree in the rule file into a format that the rule executor can process, and stores the converted rule tree as the target rule tree to be executed in the rule tree queue of the rule pool.

[0150] In one embodiment, a rule file is parsed to determine at least one collection rule;

[0151] The target rule tree is obtained by assembling the data based on the collection rules.

[0152] In this embodiment, a set of collection rules that trigger the collection of data can also be predefined based on the collection requirements, and the collection rules can be put into a rule file and sent to the rule pool of the rule engine. The rule pool parses the rule file and can determine at least one collection rule. Based on the parsed at least one collection rule, a target rule tree to be executed can be assembled. The target rule tree is in a format that the rule executor can process and is stored in the rule tree queue, waiting for the rule executor to retrieve and execute it.

[0153] In one embodiment, the execution of the target rule tree is paused when a preset pause condition is met;

[0154] The preset pause conditions include receiving a rule file update signal and / or the data storage update speed being lower than a preset speed.

[0155] In this embodiment, referring to Figure 3, the rule engine also includes a startup manager, which manages the startup and pause of the execution rule tree. When preset pause conditions are met, the startup manager pauses the execution of the target rule tree. These preset pause conditions include receiving a rule file update signal and / or the data storage update speed being lower than a preset speed. Pausing the execution of the target rule tree upon receiving a rule file update signal enables hot-downloading of rule files. Pausing the execution of the target rule tree when the data storage update speed is lower than the preset speed reduces CPU load when data updates in the data storage are slow or not at all.

[0156] In one embodiment, the execution of the target rule tree is stopped when a preset stopping condition is met;

[0157] The preset stopping conditions include: receiving an update signal for the rule file, and / or the update speed of the data storage is less than the preset speed.

[0158] In this embodiment, referring to Figure 3, the rule engine also includes a startup manager. The startup manager manages the startup and shutdown of the rule executor in the rule tree queue. When preset shutdown conditions are met, the startup manager stops the rule executor from executing the target rule tree. These preset shutdown conditions include receiving a rule file update signal and / or the data storage update speed being lower than a preset speed. Stopping the execution of the target rule tree upon receiving a rule file update signal enables hot downloading of rule files. Stopping the execution of the target rule tree when the data storage update speed is lower than the preset speed allows the startup manager to stop the rule executor from executing the target rule tree when data updates in the data storage are slow or not updated, thereby reducing the CPU load.

[0159] In one embodiment, after stopping the execution of the target rule tree, the method further includes:

[0160] The rule file corresponding to the update signal is received through the rule pool.

[0161] In this embodiment, if an update signal for a rule file is received, the execution of the target rule tree is stopped, the relevant data is saved, and the rule file corresponding to the update signal is received again through the rule pool to re-read the new rule file. Based on the new rule file, a new target rule tree can be obtained, and this new target rule tree is updated to the rule tree queue to update the rule pool, thus completing the rule file update. Subsequently, based on the updated rule pool, the updated rule tree queue needs to be loaded, and the rule executor needs to be restarted to obtain and execute the target rule tree.

[0162] In one embodiment, if a preset startup condition is met, the target rule tree in the rule tree queue is executed;

[0163] The preset startup conditions include at least one of the following: receiving a startup command, completing the rule file update, and the data storage update speed being greater than or equal to a preset speed.

[0164] In this embodiment, under the condition that preset startup conditions are met, the rule tree queue in the rule pool is loaded, and the rule executor is started through the startup manager. The rule executor retrieves the target rule tree from the rule tree queue and executes it to initiate a new data acquisition process. The preset startup conditions include at least one of the following: receiving a startup command, rule file update completion, and data storage update speed greater than or equal to a preset speed. The rule file update completion corresponds to the condition of receiving an update signal for the rule file in the preset stop condition, allowing the execution of the rule executor to be paused during rule file updates, thus completing hot-downloading of the rule file. The data storage update speed being greater than or equal to the preset speed corresponds to the condition of the data storage update speed being less than the preset stop condition, allowing the execution of the target rule tree by the rule executor to be stopped through the startup manager when data updates in the data storage are slow or not yet updated, thereby reducing CPU load. When data updates in the data storage resume, the rule executor can be restarted through the startup manager to continue executing the target rule tree. By using the preset startup conditions and the startup manager to promptly start the rule executor to execute the target rule tree in the rule tree queue, the timeliness of data acquisition can be improved.

[0165] In one embodiment, the rule file is delivered from the cloud.

[0166] In this embodiment, the rule file can be distributed from the cloud. The cloud communicates with the rule engine and can distribute newly added or updated rule files to the rule pool in the rule engine. The rule pool parses the received rule file and assembles the target rule tree to update the rule tree queue in the rule pool.

[0167] This embodiment also provides a data acquisition device, which can be integrated into a vehicle. For example, as shown in Figure 6, the data acquisition device may include:

[0168] Rule engine 1001 is used to obtain the target rule tree to be executed and collect vehicle data based on the node information in the target rule tree.

[0169] In one embodiment, the data acquisition device may further include a data storage device 1002 for storing vehicle data. The data storage device 1002 can be connected to the vehicle's data interface to acquire, store, and update real-time vehicle data. The rule engine 1001 is also used to acquire a target rule tree to be executed and, based on the node information in the target rule tree, collect the vehicle data stored in the data storage device 1002.

[0170] In one embodiment, the rule engine 1001 includes a rule pool and a rule executor;

[0171] The rule pool includes a queue of rule trees;

[0172] The rule executor is used to obtain the target rule tree from the rule tree queue and collect the vehicle data stored in the data storage device 1002 based on the node information in the target rule tree.

[0173] In one embodiment, the rule engine 1001 further includes a launch manager;

[0174] The startup manager is used to control the rule executor to stop executing the target rule tree in response to the satisfaction of a preset stop condition; and to control the rule executor to execute the target rule tree in the rule tree queue in response to the satisfaction of a preset startup condition;

[0175] The preset stop conditions include: receiving an update signal for the rule file, and / or the update speed of the data storage 1002 is less than a preset speed; the preset start conditions include at least one of receiving a start command, the rule file update being completed, and the update speed of the data storage 1002 being greater than or equal to a preset speed.

[0176] In one embodiment, the rule executor is further configured to execute the target rule tree according to the node information in the target rule tree, determine the triggering state of the rule tree node in the target rule tree, determine the execution result of the target rule tree according to the triggering state of the rule tree node, and collect vehicle data based on the execution result of the target rule tree.

[0177] In one embodiment, the node information includes collection rules, and the rule executor is further configured to: map the collection rules to a rule algorithm;

[0178] The target rule tree is executed based on the execution rule tree data and rule algorithm corresponding to the target rule tree. The triggering state of the rule tree node is determined, and the execution rule tree data is the vehicle data required to execute the target rule tree.

[0179] In one embodiment, the rule algorithm includes at least one of a jump algorithm, a threshold algorithm, and a range algorithm.

[0180] In one embodiment, the rule executor is further configured to obtain the execution rule tree data corresponding to the target rule tree from the vehicle data stored in the data storage 1002.

[0181] In one embodiment, the rule executor is further configured to obtain the collection requirement information associated with the target rule tree based on the execution result of the target rule tree;

[0182] The vehicle data stored in the data storage device 1002 is collected based on the collection requirements information.

[0183] In one embodiment, the node information includes the connection relationship of rule tree nodes, and the rule executor is further configured to: execute the target rule tree according to the connection relationship of rule tree nodes, determine the child nodes corresponding to the rule tree nodes; and determine the triggering state of the rule tree nodes according to the triggering state of the child nodes corresponding to the rule tree nodes.

[0184] In one embodiment, the rule executor is further configured to: determine the triggering state of a rule tree node based on the triggering state of the child node and the logical relationship between the child nodes.

[0185] In one embodiment, the logical relations include conjunction and / or disjunction.

[0186] In one embodiment, the rule engine 1001 further includes a time window manager;

[0187] The time window manager is used to control the rule executor to maintain the triggering state of the target rule tree node when the triggering state of the target rule tree node in the target rule tree is triggered, and to start the time window configured in the target rule tree. At least one rule tree node in the target rule tree is the target rule tree node corresponding to the time window.

[0188] In one embodiment, the time window manager is also used to control the rule executor to stop maintaining the triggering state of the target rule tree node when the execution result of the target rule tree is successful; or, when the time window is closed, to stop maintaining the triggering state of the target rule tree node.

[0189] In one embodiment, the rule pool of the rule engine 1001 is used to update the rule tree queue in the rule pool based on the received rule file; the rule file is distributed from the cloud.

[0190] In one embodiment, the rule pool is also used to receive the rule file corresponding to the update signal through the rule pool, and update the rule tree queue based on the received rule file.

[0191] This embodiment uses the node information of the target rule tree to independently determine the collection rules, thereby triggering the collection of data corresponding to the target rule tree for the target object. In this way, the collection rules are presented as a collection rule node tree, independent of the data collection process, which helps to make data collection more lightweight.

[0192] For example, referring to Figure 3, the vehicle includes a data acquisition device, which includes a rule engine and a data storage device. The data storage device can be a database and is connected to the vehicle's data interface to store real-time vehicle data. The rule engine can also be connected to the cloud, which acts as the source of rule files, configures the rule files according to an agreed format, and distributes the rule files to the vehicle through the vehicle-cloud link. The vehicle reads the rule files in real time and executes the latest rule tree.

[0193] The rule engine is used to drive the execution of the rule tree, and specifically includes a rule pool, a startup manager, a rule executor, and a time window manager. The rule pool can parse the rule files distributed from the cloud, assemble the target rule tree, and put the assembled target rule tree into a rule tree queue, waiting for the rule executor in the rule engine to retrieve the target rule tree from the rule tree queue for execution.

[0194] The startup manager can be used to manage the startup and pause of rule executors. When a rule file update signal is received during the execution of a rule executor, it can pause the current execution of the rule executor, save the relevant data, re-read the new rule file, update the rule pool, load the rule tree queue based on the updated rule pool, and restart the rule executor.

[0195] The rule executor sequentially retrieves target rule trees to be executed from the rule tree queue formed by the rule pool, and reads the execution rule tree data required for executing the rule tree from the database. Based on the execution rule tree data and the node information of the rule tree, it executes the target rule tree and determines the execution result of the target rule tree. After the rule tree queue has completed one round of execution, it can start retrieving rule trees from the beginning again to continue the next round of execution.

[0196] In some embodiments, before configuring the rule file, a rule tree containing multiple collection rules can be configured according to the simple rule algorithm, and the rule tree can be updated to the rule file. In this way, after the rule engine receives the rule file and parses it, it can convert the rule tree in the rule file into a target rule tree that the rule executor can process, so as to quickly obtain the assembled rule tree and improve the assembly efficiency of the rule tree.

[0197] In some embodiments of this invention, the distribution of rule files from the cloud is divided into hot distribution and cold distribution. Cold distribution of rule files: If the vehicle-side data collection program is in a static state, that is, the rule executor is not started, the rule file can be directly transmitted to the vehicle-side via the vehicle-cloud link.

[0198] When the rule executor's collection program starts, a target rule tree is being executed. If a rule file update signal is received, such as a request to be sent from the cloud, the rule executor can be stopped through the startup manager. Then, the rule file corresponding to the request can be received through the vehicle-cloud link to update the rule file on the vehicle side. After the rule file update is completed, the rule engine state is reset through the startup manager, the rule tree queue is reloaded, and the rule executor is restarted to re-execute the rule tree queue.

[0199] To better understand, a specific application process is given below, see Figure 7:

[0200] 1. The cloud-based system configures rule files based on data collection requirements. These requirements can originate from vehicle intelligence R&D needs, user behavior and product optimization needs, or vehicle-side accident safety analysis needs. After configuring the rule files according to the agreed-upon rule format, the cloud-based system distributes them to the vehicle.

[0201] 2. Cloud-based rule file distribution, including hot distribution and cold distribution of rule files.

[0202] Cold distribution of rule files occurs when the vehicle-side data collection program is in a static state and the rule tree in the rule pool has not been executed. This distribution can be completed directly through the vehicle-cloud link. Hot distribution of rule files occurs when the vehicle-side data collection program is running and a target rule tree is being executed by the rule executor. In this case, the execution of the current rule engine needs to be paused through the startup manager, the vehicle-side rule file is updated through the vehicle-cloud link, the rule engine state is reset, the rule tree queue is reloaded, and the execution of the rule tree is restarted.

[0203] 3. Startup Management: Manage the rule engine status through the startup manager. In addition to managing the start and stop of the rule engine when hot-downloading rule files, the startup manager can also pause the execution of the rule engine when the data update speed in the data storage of vehicle data is slow or not updated. When a new data source is available, it can be restarted, thereby reducing the CPU load.

[0204] 4. The rule engine parses the rule files. The rule engine parses the rule files distributed from the cloud and assembles the rule trees, placing them sequentially into the rule tree queue in the rule pool. The rule engine then drives the rule executor to retrieve the rule trees from the rule tree queue and execute them.

[0205] 5. The rule engine drives the target rule tree. The rule engine sequentially reads the target rule tree in the rule pool and reads real-time vehicle-side data from the Redis database to obtain the execution rule tree data. It then sequentially determines the trigger status of each node in the rule tree and, based on node information, whether a time window is open, etc., comprehensively determines the execution result of the rule tree.

[0206] 6. If the rule engine determines that the execution result of the target rule tree is successful, it collects the vehicle-side data corresponding to the target data information defined in the rule file and stores it in the database as the trigger rule tree data collection data for use by the data requester. If the rule engine determines that the execution result of the target rule tree is unsuccessful, the rule engine continues to drive the execution of the target rule tree. If the defined vehicle data is collected, the rule engine will also continuously drive the execution of the target rule tree.

[0207] Based on the above embodiments, full coverage of vehicle-side data collection can be achieved. However, with the application of intelligent technologies such as autonomous driving and smart cockpits, the dimensions and breadth of vehicle-side data are increasing daily. In this context, collecting all vehicle-side data is impractical, while selecting specific data for collection is too rigid. This dilemma...

[0208] Based on the above embodiments, the data collection requirements can be separated from the data collection program. The data collection program does not change with the changes in data collection requirements. When the data collection requirements are updated or new requirements are added, the rule file can be reconfigured according to the requirements and then sent to the vehicle terminal via the cloud. Based on this, data collection can be covered to every data source on the vehicle terminal.

[0209] Based on the above embodiments, it is able to adapt to data collection in complex scenarios. By configuring a multi-branch rule tree and establishing relationships between rules, it addresses the collection needs when multiple vehicle-end signals reach specific states within a certain period of time. The depth and breadth of the rule tree are unlimited, meaning that theoretically it can adapt to extremely complex data collection needs. This is particularly important in today's era of intelligent vehicles with an increasing number of vehicle data terminals and multiple terminals working collaboratively.

[0210] Based on the above embodiments, lightweight data acquisition from the vehicle can be achieved. When acquiring signal data, this application does not mechanically collect data for all consecutive moments of the signal. Instead, it establishes acquisition rules to collect data around a specific time point or time period when one or more signals reach a specific state. On the one hand, it collects data that is truly valuable to the demand side, eliminating the need for secondary filtering. On the other hand, collecting key data significantly alleviates storage pressure.

[0211] Based on the above embodiments, secondary program development can be avoided, reducing the difficulty of program maintenance and use. As mentioned above, the data to be collected is not determined by the collection program, but by the rule file. Therefore, when the collection requirements are updated, only the rule file needs to be updated. The collection requirements and the collection program are not coupled, and there is no need for secondary development of the collection program. At the same time, the user does not need to understand the internal implementation principle of the program. When there are new requirements, the collection configuration file is modified according to the multi-branch rule tree structure and sent to the vehicle terminal. The vehicle terminal automatically parses the new requirements and implements collection. The rule engine logic greatly enhances the system's versatility and universality.

[0212] In summary, this application's embodiments, through a rule engine strategy, achieve lightweight data collection while covering all data sources on the vehicle side. Faced with massive amounts of data generated by the vehicle, it collects key data beneficial to the data requester. Through a multi-branch rule tree strategy, the data collection can adapt to data collection in complex scenarios. In addition, the collection requirements are decoupled from the collection program, which can cope with constantly changing collection requirements and greatly enhance the scalability of data collection.

[0213] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0214] Accordingly, this application also provides a data acquisition device, as shown in FIG8, which is a schematic diagram of the structure of the data acquisition device provided in this application embodiment. The data acquisition device 1100 further includes a processor 1101 with one or more processing cores, a memory 1102 with one or more computer-readable storage media, and computer instructions stored on the memory 1102 and executable on the processor. The processor 1101 and the memory 1102 are electrically connected. Those skilled in the art will understand that the data acquisition device structure shown in the figures does not constitute a limitation on the data acquisition device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0215] The processor 1101 is the control center of the data acquisition device 1100. It connects various parts of the data acquisition device 1100 via various interfaces and lines. By running or loading software programs and / or components stored in the memory 1102, and by calling data stored in the memory 1102, it executes various functions of the data acquisition device 1100 and processes data, thereby providing overall monitoring of the data acquisition device 1100. The processor 1101 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0216] In this embodiment, the processor 1101 in the data acquisition device 1100 loads the instructions corresponding to the processes of one or more application programs into the memory 1102 according to the following steps, and the processor 1101 runs the application programs stored in the memory 1102 to realize various functions, such as:

[0217] Obtain the target rule tree to be executed; collect vehicle data based on the node information in the target rule tree. The specific implementation details of each of these operations can be found in the preceding embodiments and will not be repeated here.

[0218] Optionally, as shown in Figure 8, the data acquisition device 1100 further includes: a touch screen display 1103, a radio frequency circuit 1104, an audio circuit 1105, an input device 1106, and a power supply 1107. The processor 1101 is electrically connected to the touch screen display 1103, the radio frequency circuit 1104, the audio circuit 1105, the input device 1106, and the power supply 1107. Those skilled in the art will understand that the data acquisition device structure shown in Figure 8 does not constitute a limitation on the data acquisition device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0219] The touch display screen 1103 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 1103 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the data acquisition device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar formats. The touch panel can be used to collect touch operations performed by the user on or near it (e.g., operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), and generate corresponding operation commands, which then execute corresponding programs. In one embodiment, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1101. It can also receive and execute commands from the processor 1101. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 1101 to determine the type of touch event. Subsequently, the processor 1101 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 1103 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 1103 can be used as two independent components to achieve input and output functions. That is, the touch display screen 1103 can also be used as part of the input device 1106 to achieve input functions.

[0220] The radio frequency circuit 1104 can be used to transmit and receive radio frequency signals to establish wireless communication with network medical devices or other data acquisition devices, and to transmit and receive signals with network medical devices or other data acquisition devices.

[0221] Audio circuit 1105 can be used to provide an audio interface between the user and the data acquisition device via a speaker and a microphone. Audio circuit 1105 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts the acquired sound signals into electrical signals, which are then received by audio circuit 1105, converted back into audio data, and processed by processor 1101 before being transmitted via radio frequency circuit 1104 to, for example, another data acquisition device, or output to memory 1102 for further processing. Audio circuit 1105 may also include an earphone jack to provide communication between external headphones and the data acquisition device.

[0222] The input device 1106 can be used to receive input numbers, character information or user characteristic information (such as fingerprints, iris, facial information, etc.), and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0223] Power supply 1107 is used to power the various components of data acquisition device 1100. Optionally, power supply 1107 can be logically connected to processor 1101 through a power management device, thereby enabling functions such as charging, discharging, and power consumption management through the power management device. Power supply 1107 may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0224] Although not shown in Figure 8, the data acquisition device 1100 may also include a camera, sensor, wireless fidelity device, Bluetooth device, etc., which will not be described in detail here.

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

[0226] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0227] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of computer instructions, which can be loaded by a processor to execute any of the data acquisition methods provided in embodiments of this application. The computer instructions can execute the steps of the following data acquisition method:

[0228] Obtain the target rule tree to be executed; collect vehicle data based on the node information in the target rule tree.

[0229] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0230] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0231] Since the computer-readable storage medium contains computer instructions that can implement any of the data acquisition methods provided in the embodiments of this application, it can execute any of the data acquisition methods provided in the embodiments of this application. Therefore, the effects are detailed in the preceding embodiments and will not be repeated here.

[0232] This application also provides a computer program product, including computer instructions that can be loaded by a processor to execute any of the data acquisition methods provided in this application. The computer instructions can execute the steps of the following data acquisition method:

[0233] Obtain the target rule tree to be executed; collect vehicle data based on the node information in the target rule tree.

[0234] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0235] Since the computer program product can implement the beneficial storage computer instructions that can be implemented by any of the data acquisition methods provided in the embodiments of this application, it can execute any of the data acquisition methods provided in the embodiments of this application. Therefore, the effects are detailed in the previous embodiments and will not be repeated here.

[0236] In one embodiment, this application also provides a vehicle that includes any of the above-described data acquisition devices, data acquisition equipment, computer-readable storage media, and computer program products, and executes any of the above-described methods.

[0237] In the description of this application, the terms "first" and "second" are used for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, features defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

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

[0239] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.

[0240] The above are merely specific embodiments of this application and are not intended to limit this application in any way. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A data acquisition method, wherein, include: Obtain the target rule tree to be executed; Vehicle data is collected based on the node information in the target rule tree.

2. The data acquisition method as described in claim 1, wherein, The step of collecting vehicle data based on the node information in the target rule tree includes: The target rule tree is executed based on the node information in the target rule tree, and the execution result of the target rule tree is determined. The vehicle data is collected based on the execution result of the target rule tree.

3. The data acquisition method as described in claim 2, wherein, The step of executing the target rule tree based on the node information in the target rule tree and determining the execution result of the target rule tree includes: Execute the target rule tree according to the node information in the target rule tree, and determine the triggering state of the rule tree node in the target rule tree; The execution result of the target rule tree is determined based on the triggering state of the rule tree node.

4. The data acquisition method as described in claim 3, wherein, The node information includes collection rules. The step of executing the target rule tree based on the node information in the target rule tree, and determining the trigger state of the rule tree nodes in the target rule tree, includes: Map the collection rules to a rule algorithm; The target rule tree is executed according to the execution rule tree data corresponding to the target rule tree and the rule algorithm, and the triggering state of the rule tree node is determined. The execution rule tree data is the vehicle data required to execute the target rule tree.

5. The data acquisition method as described in claim 4, wherein, The rule algorithm includes at least one of the jump algorithm, threshold algorithm, and interval algorithm.

6. The data acquisition method as described in claim 4 or 5, wherein, Before mapping the collection rules to a rule algorithm, the method further includes: The execution rule tree data corresponding to the target rule tree is obtained from the vehicle data stored in the data storage device.

7. The data acquisition method according to any one of claims 3 to 6, wherein, The node information includes the connection relationships of the rule tree nodes. The step of executing the target rule tree based on the node information in the target rule tree and determining the triggering state of the rule tree nodes in the target rule tree includes: Execute the target rule tree according to the connection relationship of the rule tree nodes, and determine the child nodes corresponding to the rule tree nodes; The triggering state of the rule tree node is determined based on the triggering state of the child node corresponding to the rule tree node.

8. The data acquisition method as described in claim 7, wherein, Determining the trigger state of a rule tree node based on the trigger state of its child nodes includes: The triggering state of the rule tree node is determined based on the triggering state of the child node and the logical relationship between the child nodes.

9. The data acquisition method as described in claim 8, wherein, The logical relations include conjunction and / or disjunction.

10. The data acquisition method according to any one of claims 3 to 9, wherein, The target rule tree is configured with a time window, and at least one rule tree node in the target rule tree is the target rule tree node corresponding to the time window. The method further includes: In response to the target rule tree node being triggered, the trigger state of the target rule tree node is maintained, and the time window is started.

11. The data acquisition method as described in claim 10, wherein, After maintaining the triggering state of the target rule tree node and starting the time window, the method further includes: In response to the execution result of the target rule tree being successful, the triggering state of the target rule tree node is stopped. Alternatively, in response to the closing of the time window, the triggering state of the target rule tree node is stopped.

12. The data acquisition method according to any one of claims 2 to 11, wherein, The collection of vehicle data based on the execution result of the target rule tree further includes: Based on the execution result of the target rule tree, obtain the collection requirement information associated with the target rule tree; Based on the aforementioned data collection requirements, the vehicle data stored in the data storage device is collected.

13. The data acquisition method as described in claim 12, wherein, The data collection requirements include at least one of the following: data type, collection time, and collection frequency.

14. The data acquisition method according to any one of claims 1 to 13, wherein, The process of obtaining the target rule tree to be executed includes: The target rule tree is obtained from the rule tree queue of the rule pool.

15. The data acquisition method as described in claim 14, wherein, The method further includes: The target rule tree is determined based on the rule file; The target rule tree is stored in the rule tree queue.

16. The data acquisition method as described in claim 15, wherein, The determination of the target rule tree based on the rule file includes: Based on the rule file, at least one collection rule is determined; The target rule tree is obtained by assembling based on the acquisition rules.

17. The data acquisition method as described in claim 15 or 16, wherein, The method further includes: In response to the fulfillment of a preset stopping condition, the execution of the target rule tree is stopped; The preset stopping conditions include: receiving an update signal for the rule file, and / or the update speed of the data storage is less than a preset speed.

18. The data acquisition method as described in claim 17, wherein, After stopping the execution of the target rule tree, the method further includes: The rule file corresponding to the update signal is received through the rule pool.

19. The data acquisition method according to any one of claims 15 to 18, wherein, The method further includes: In response to the fulfillment of preset startup conditions, the target rule tree in the rule tree queue is executed; The preset startup conditions include at least one of the following: receiving a startup command, the rule file being updated, and the data storage speed being greater than or equal to a preset speed.

20. The data acquisition method according to any one of claims 15 to 19, wherein, The rule file is distributed from the cloud.

21. A data acquisition device, wherein, The device includes a processor connected to a memory storing computer instructions. The processor is configured to execute the computer instructions stored in the memory to perform the data acquisition method according to any one of claims 1 to 20.

22. A data acquisition device, wherein, The data acquisition device includes: A rule engine is used to obtain a target rule tree to be executed and to collect vehicle data based on the node information in the target rule tree.

23. The data acquisition device as described in claim 22, wherein, The data acquisition device includes a data storage device, which is used to store the vehicle data; The rule engine is also used to obtain the target rule tree to be executed, and to collect the vehicle data stored in the data storage device based on the node information in the target rule tree.

24. The data acquisition device as described in claim 22 or 23, wherein, The rule engine includes a rule pool and a rule executor; The rule pool includes a rule tree queue; The rule executor is used to obtain the target rule tree from the rule tree queue and collect the vehicle data according to the node information in the target rule tree.

25. The data acquisition device as described in claim 24, wherein, The rule engine also includes a startup manager; The startup manager is used to control the rule executor to stop executing the target rule tree in response to the satisfaction of a preset stop condition; In addition, in response to the satisfaction of preset startup conditions, the rule executor is controlled to execute the target rule tree in the rule tree queue; The preset stop conditions include: receiving an update signal for the rule file, and / or, the update speed of the data storage device is less than a preset speed; the preset start conditions include at least one of receiving a start command, the rule file update being completed, and the update speed of the data storage device being greater than or equal to the preset speed.

26. The data acquisition device as described in claim 24 or 25, wherein, The rule executor is further configured to execute the target rule tree according to the node information in the target rule tree, determine the triggering state of the rule tree node in the target rule tree, determine the execution result of the target rule tree according to the triggering state of the rule tree node, and collect the vehicle data based on the execution result of the target rule tree.

27. The data acquisition device as claimed in claim 26, wherein, The rule engine also includes a time window manager; The time window manager is used to control the rule executor to be triggered when the target rule tree node of the target rule tree is in the triggered state, maintain the trigger state of the target rule tree node, and start the time window configured in the target rule tree, wherein at least one rule tree node in the target rule tree is the target rule tree node corresponding to the time window.

28. The data acquisition device according to any one of claims 24 to 27, wherein, The rule engine is used to update the rule tree queue in the rule pool based on the received rule file; the rule file is distributed from the cloud.

29. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the data acquisition method according to any one of claims 1 to 20.

30. A computer program product, wherein, It includes computer instructions, which are executed by a processor to implement the data acquisition method according to any one of claims 1 to 20.

31. A vehicle, wherein, The vehicle performs the data acquisition method as described in any one of claims 1 to 20, or includes the data acquisition device as described in claim 21 or the data acquisition apparatus as described in any one of claims 22 to 28.

Images