Data acquisition method, equipment, device, medium, program product and vehicle

Abstract

The invention relates to a data acquisition method, equipment and device, a medium, a program product and a vehicle. The method comprises the steps of obtaining a to-be-executed target rule tree; and collecting vehicle data according to the node information in the target rule tree. The invention aims to make data acquisition lighter.

Description

Technical Field

[0001] The present application relates to the field of data collection, and in particular to a data collection method, equipment, device, medium, program product and vehicle. Background Art

[0002] Vehicle-side data collection is a technology that has emerged alongside the advancement of the Internet of Vehicles (IoV) and the rapid development of vehicle intelligence. Through CAN or in-vehicle Ethernet, it collects traditional vehicle status information, environmental information, driver behavior information, and intelligent sensor information such as cameras, radar, and IMUs (Inertial Measurement Units). However, current vehicle data collection relies on a fixed collection process, which is overly redundant and difficult to implement in a lightweight manner. Summary of the Invention

[0003] The embodiments of the present application provide a data collection method, device, apparatus, medium, program product, and vehicle, which improve the lightweightness of data collection and at least partially solve the above-mentioned technical problems.

[0004] In order to achieve the above-mentioned object, according to the first aspect of the present application, a data collection method is provided, the data collection method comprising:

[0005] Get the target rule tree to be executed;

[0006] Vehicle data is collected according to the node information in the target rule tree.

[0007] According to the second aspect of the present application, a data acquisition device is also provided, including a processor, the processor is connected to a memory, the memory stores a computer program, and the processor is used to run the computer program in the memory to execute any of the above-mentioned data acquisition methods.

[0008] According to a third aspect of the present application, a data acquisition device is provided, comprising:

[0009] A rule engine module is used to obtain a target rule tree to be executed and collect vehicle data according to node information in the target rule tree.

[0010] According to a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, any of the above-mentioned data acquisition methods is implemented.

[0011] According to a fifth aspect of the present application, a computer program product is provided, which includes a computer program, and the computer program is executed by a processor to implement any of the above-mentioned data collection methods.

[0012] According to a sixth aspect of the present application, a vehicle is provided, which executes the data acquisition method described above, or includes the data acquisition device or equipment described above.

[0013] In summary, the embodiment of the present application, through the above technical solution, collects vehicle data through the node information in the target rule tree. In this way, the collection rules are in the form of a collection rule node tree, which is independent of the data collection process, helping to make data collection more lightweight.

[0014] Other features and advantages of the present application will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0016] In order to more completely understand the present application and its beneficial effects, the following description will be given in conjunction with the accompanying drawings, wherein the same drawing numbers represent the same parts in the following description.

[0017] Figure 1 This is a flow chart of an embodiment of a data collection method provided in an embodiment of the present invention;

[0018] Figure 2 is a schematic diagram of the structure of a rule tree provided in an embodiment of the present invention;

[0019] Figure 3 is a schematic diagram of a data collection scenario provided in an embodiment of the present invention;

[0020] Figure 4 Schematic diagram of the algorithm mapping structure provided in an embodiment of the present invention;

[0021] Figure 5 This is a schematic diagram of the structure of a rule tree in a specific application example provided in an embodiment of the present invention;

[0022] Figure 6 1 is a schematic structural diagram of a data acquisition device provided in an embodiment of the present invention;

[0023] Figure 7 This is a schematic diagram of a data collection process in a specific application example provided in an embodiment of the present invention;

[0024] Figure 8 It is a structural diagram of a data acquisition device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0026] Based on the issues mentioned in the aforementioned background technology, vehicle-side data collection, a technology that emerged with the advancement of the Internet of Vehicles and the rapid development of vehicle intelligence, collects traditional vehicle status information, environmental information, driver behavior information, and intelligent sensing information such as cameras, radar, and IMUs (inertial measurement units) through CAN or in-vehicle Ethernet. However, current vehicle data collection relies on a fixed collection program, which is too redundant and difficult to operate in a lightweight manner.

[0027] Furthermore, vehicle-side data comes from a wide range of sources, including operating status data of various vehicle components, driver behavior data generated by interactions between the vehicle and the driver, and control data generated by interactions between various vehicle modules. With the advancement of vehicle intelligence and the increase in smart terminals, the sources of vehicle-side data are becoming increasingly diverse, and the amount of data is increasing exponentially. Furthermore, the information required for vehicle-side data collection is not static; the data required for various data analysis tasks often changes with business needs and model parameters.

[0028] Traditional vehicle-side data collection strategies prioritize critical data and discard others. This mechanical approach to data collection suffers from significant limitations in both the dimensionality and breadth of data collected. More importantly, new data collection requirements necessitate redevelopment and re-adaptation of the program, making it unsuitable for rapidly evolving data collection requirements.

[0029] The inventors discovered that: for important signals generated by vehicle-side components, it is not necessary to collect all the signals generated by the component; and for non-important signals generated by other components, not all the data generated by the component is unnecessary. In fact, what really needs to be collected is the data at the time point or time period around the moment when the component reaches a certain state. More importantly, most vehicle-side components are interconnected, and many times it is necessary to collect data when one or several components reach a certain state and another or several other components reach their specific state. Based on these findings, it is not necessary to collect all the data generated by all component terminals, but it is necessary to formulate corresponding collection rules to collect the key data defined at the moment the event occurs. At the same time, it is also crucial to flexibly configure the collection rules according to the collection demand information to reduce program coupling and avoid repeated mechanical development.

[0030] Some related solutions are mainly used for the collection and analysis of user tracking data, and are not suitable for the massive vehicle-side data collection required for large-scale model analysis. Although the tracking data is configurable, the collection rules are not fully explained. In addition, when there is coupling between rules, data cannot be effectively collected.

[0031] In some related solutions, it is mainly used to collect user driving data points, customize user-specific driving behaviors, and improve user driving experience, rather than being used for constantly changing and increasing data collection demand information.

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

[0033] It can be seen that the current vehicle-side data collection strategy is too simple and cannot cope with the increasing amount of massive data and data collection demand information in complex scenarios. The level of data screening and data extraction is low. At the same time, the traditional data collection strategy is too highly coupled with the program and cannot be flexibly configured according to the collection demand information.

[0034] In order to solve the above problems, the embodiments of the present application propose a data collection method, equipment, device, medium, program product and vehicle. The embodiments of the present application collect vehicle data based on the node information in the target rule tree, which can cover a comprehensive, adaptable to complex scenarios, lightweight and easy-to-maintain data collection strategy, can cope with the current increasing data demand, improve data collection efficiency and collection accuracy, and alleviate data storage pressure.

[0035] Specifically, the data collection method of the present application can be applied to a data collection device or a vehicle, and the data collection device can also be a vehicle or be installed on a vehicle. The following embodiments are described in detail using the vehicle as an example of the execution subject of the data collection method.

[0036] This application provides a data collection method, please refer to Figure 1 The data collection method provided in the embodiment of the present application includes steps S10 to S20, which are described in detail below.

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

[0038] In this embodiment, specific collection requirements are designed to address the diverse collection needs of data demanders, along with a corresponding set of collection rules. These rules are used to trigger data collection operations that meet these requirements. When these collection rules are met, the corresponding data collection operation can be triggered to collect vehicle data, ultimately obtaining the vehicle data required by the data demander. In this embodiment, each collection rule set includes at least one collection rule. Different rule trees can be assembled based on each collection rule set. These rule trees can serve as target rule trees to be executed, triggering data collection operations to collect vehicle data.

[0039] In this embodiment, there may be one or more Rule-Trees, from which the target Rule-Tree to be executed may be obtained.

[0040] S20: Collect vehicle data according to the node information in the target rule tree.

[0041] In this embodiment, the target rule tree contains the trigger logic for collection rules, which determines the node information of the target rule tree. After obtaining the target rule tree, the node information in the target rule tree is used to determine whether to trigger data collection. If so, vehicle data is collected. The collected data can be the data collected by the trigger rule tree corresponding to the target rule tree. The method and content of collecting the data from the trigger rule tree can be determined based on the collection requirement information associated with the target rule data.

[0042] 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 collection rule is in the form of a collection rule node tree, independent of the data collection process, which helps to make data collection more lightweight.

[0043] In one embodiment, collecting vehicle data according to the node information in the target rule tree includes:

[0044] Executing the target Rule Tree according to the node information in the target Rule Tree, and determining an execution result of the target Rule Tree;

[0045] The vehicle data is collected based on the execution result of the target rule tree.

[0046] In this embodiment, when the target Rule Tree is determined, execution of the target Rule Tree begins based on the node information in the target Rule Tree. This execution is based on the node information in the target Rule Tree. The node information determines the collection rules in the Rule Tree and the connections between the collection rules. The collection rules and connections determine the execution result of the target Rule Tree. Based on the execution result of the target Rule Tree, a decision is made as to whether to trigger a data collection operation to collect the vehicle data required by the requester.

[0047] In this way, according to the execution result of the target rule tree, the data corresponding to the target rule tree is collected for the target object, further realizing the decoupling of the collection program and the collection process, and further realizing the lightweight of data collection.

[0048] In one embodiment, executing the target Rule Tree according to the node information in the target Rule Tree and determining the execution result of the target Rule Tree includes:

[0049] Execute the target Rule Tree according to the node information in the target Rule Tree, and determine the triggering status of the Rule Tree nodes in the target Rule Tree;

[0050] Determine the execution result of the target Rule Tree according to the triggering status of the Rule Tree node.

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

[0052] In some embodiments, reference Figure 2 The rule tree including the target rule tree is a multi-branch tree. Unlike a binary tree, each node may have any number of child nodes, usually 0, 1, 2, 3, or 4. On the other hand, the depth of the rule tree can also be configured arbitrarily, usually within 5 layers.

[0053] In one embodiment, the node information includes a collection rule, and executing the target Rule Tree according to the node information in the target Rule Tree to determine the triggering status of the Rule Tree node in the target Rule Tree includes:

[0054] Mapping the acquisition rules into rule algorithms;

[0055] 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 trigger state of the Rule Tree node is determined, where the execution Rule Tree data is the vehicle data required to execute the target Rule Tree.

[0056] In this embodiment, the vehicle data required for executing the target Rule Tree is obtained as the execution Rule Tree data. The execution Rule Tree data is used to determine the trigger status of the Rule Tree node when executing the target Rule Tree. The execution Rule Tree data needs to be distinguished from the trigger Rule Tree collection data mentioned above:

[0057] The execution rule tree data is the data involved in judging whether the current state of a component meets the collection rules defined by the rule tree node when executing the target rule tree; and the trigger rule tree collection data is the data collection operation corresponding to the target rule tree is triggered 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, and the data obtained by collecting vehicle data is the data required by the data demander corresponding to the target rule tree.

[0058] During the data collection process, the execution rule tree data is the input data input into the rule engine module, and the trigger rule tree collection data is the output data of the rule engine module, that is, the data finally collected by the data collection device.

[0059] In the target rule tree, some rule tree nodes include specific collection rules. Each collection rule is parsed, its semantics abstracted, and mapped to a specific rule algorithm to map these collection rules into a rule algorithm. A collection rule can be mapped to at least one rule algorithm, which is executed based on the rule tree data. The rule algorithm is used to determine the trigger state of the corresponding rule tree node. The trigger state of the corresponding rule tree node can be determined based on the real-time execution results of the rule algorithm. This algorithm mapping allows for quick and accurate determination of the trigger state of a rule tree node.

[0060] 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, it is necessary to process the execution rule tree data corresponding to the rule tree node according to the rule algorithm of the rule tree node to determine the triggering status of the rule tree node to indicate whether the collection rule corresponding to the rule tree node is triggered.

[0061] In this embodiment, the triggering status of the Rule Tree node can be quickly determined through the execution Rule Tree data corresponding to the target Rule Tree and the rule algorithm corresponding to the Rule Tree node, thereby improving the efficiency of executing the target Rule Tree.

[0062] In one embodiment, the rule algorithm includes at least one of a jump algorithm, a threshold algorithm, and an interval algorithm.

[0063] In this embodiment, each rule tree node corresponds to a collection rule, which serves as node information. A collection rule can correspond to at least one simple rule, which can include at least one of a jump rule, a threshold rule, and an interval rule, corresponding to a jump algorithm, a threshold algorithm, and an interval algorithm, 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 intelligent and electrified vehicles, the amount of vehicle body data has increased dramatically, and the rules for collecting vehicle body data have also become increasingly diverse. However, this embodiment maps the complex and numerous collection rules into three simple rule algorithms: a threshold algorithm, a jump algorithm, and an interval algorithm.

[0064] Jump algorithm: For discrete signals generated by certain vehicle-side components, it is sometimes necessary to capture their changes from one value to another. For such rules, they are mapped to the jump algorithm for execution.

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

[0066] Interval algorithm: For signals generated by certain vehicle-side 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.

[0067] When configuring collection rules, you can configure the collection rules according to the format specified by the algorithm to form simple rules, so that they can be subsequently mapped to rule algorithms containing simple rule algorithms to improve processing efficiency.

[0068] Reference Figure 4 , mapping the collection rules in the node information of all or part of the rule tree nodes in the target rule tree to a rule algorithm including at least one simple rule algorithm.

[0069] In this way, through rule-algorithm mapping, the complex and abstract collection rules are parsed into three specific simple rule algorithms, so that the collection program does not have to adapt to specific rules one by one, but only needs to execute the rule algorithm corresponding to the rule, which can further improve the lightweight and efficiency of data collection.

[0070] 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 is found that the numerous collection rules can ultimately be abstracted into at least one rule algorithm including a jump algorithm, a threshold algorithm, and an interval algorithm.

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

[0072] The execution rule-tree data corresponding to the target rule-tree is obtained from the vehicle data stored in the data storage module.

[0073] In this embodiment, referring to Figure 3 The vehicle may include a rule engine module and a data storage module, wherein the rule engine module is mainly used to execute the data collection method provided in this embodiment to drive the execution of the target rule tree, and the data storage module may be a redis database, etc., which accesses and stores real-time vehicle data through CAN or vehicle Ethernet. The vehicle data required for executing the target rule tree can be obtained from the data storage module as execution rule tree data.

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

[0075] When the execution result is successful, vehicle data is collected.

[0076] In this embodiment, the target rule tree is executed. When the execution result of the target rule tree is successful, a data collection operation can be triggered to collect vehicle data to obtain the collected data of the trigger rule tree corresponding to the target rule tree, and the collected vehicle data is placed in the database for easy acquisition by data demanders.

[0077] In some embodiments, the trigger status of the bottom rule tree node in the target rule tree can be used to determine the trigger status of other rule tree nodes layer by layer, and finally the trigger status of the head node in the target rule tree can be determined. Based on the trigger status of the head node in the target rule tree, the execution result of the target rule tree can be determined. When the trigger status of the head node is triggered, it can be characterized that the execution result of the target rule tree is successful. When the execution result of the target rule tree is successful, the data collection operation can be triggered to collect vehicle data to obtain the vehicle data required by the demander.

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

[0079] Based on the execution result of the target rule tree, obtaining collection requirement information associated with the target rule tree;

[0080] Based on the collection requirement information, the vehicle data stored in the data storage module is collected.

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

[0082] In this embodiment, the vehicle data stored in the data storage module can be used as execution rule tree data and / or trigger rule tree collection data. When executing a target rule tree, the rule engine module can retrieve the execution rule tree data corresponding to the target rule tree from the data storage module to execute the target rule tree. Alternatively, based on the execution results of the target rule tree, the vehicle data stored in the data storage module can be collected to obtain trigger rule tree collection data corresponding to the target rule tree.

[0083] It should be noted that the data collected by the trigger rule tree is not completely consistent with the data collected by the execution rule tree. In the collection of demand information, in more cases, when certain components of the vehicle reach a certain state, other data related to the component is collected. The certain components here are generally the execution rule tree data, and the data related to the component is the trigger rule tree collection data.

[0084] 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 for the demander to obtain.

[0085] This collection requirement information is associated with the target rule tree and the collection rules corresponding to the target rule tree. This 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 file is parsed to assemble a rule tree and its associated collection requirement information. The collection requirement information includes the type of data to be collected, the collection time, and / or the collection frequency. In accordance with the collection requirement information, vehicle data stored in the data storage module is collected to obtain the aforementioned triggering rule tree collection data, which is then stored in the corresponding database for access by the data requester.

[0086] In this way, through the collection requirement information associated with the target rule tree, data that can meet the requirements can be accurately collected. In addition, which data needs to be collected is not determined by the collection program, but by the collection requirement information associated with the target rule tree, which can also be considered to be determined by the rule file. Therefore, when the collection requirement changes need to be updated, the collection requirement information in the rule file can be updated. The collection requirement information is not coupled with the program that executes the rule tree, and there is no need for secondary development. At the same time, the user does not need to understand the internal implementation principles of the program. When there are new requirements changes, it is only necessary to modify the rule file according to the multi-branch rule tree structure and send it to the vehicle side. The vehicle side automatically parses the new rule file and updates the corresponding rule tree. The rule engine module logic greatly enhances the versatility and universality of the system.

[0087] In one embodiment, the node information includes a connection relationship of the Rule Tree nodes, and executing the target Rule Tree according to the node information in the target Rule Tree to determine the triggering status of the Rule Tree nodes includes:

[0088] 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;

[0089] The triggering state of the rule tree node is determined according to the triggering state of the child node corresponding to the rule tree node.

[0090] In this embodiment, each rule tree node in the target rule tree essentially corresponds to a collection rule. The inventors have discovered that in vehicle data collection scenarios, each collection rule can be converted into at least one simple rule. This simple rule can be a threshold rule, a jump rule, or an interval rule, corresponding to the threshold algorithm, jump algorithm, and interval algorithm described above, respectively. If a collection rule corresponds to a single simple rule, it is considered a first-class rule. If a collection rule corresponds to multiple simple rules, it is considered a second-class rule.

[0091] For the first type of rules, the above method can be used to map them into a rule algorithm containing a simple rule algorithm to independently determine the triggering status of their corresponding rule tree nodes. For the second type of rules, their corresponding rule tree nodes can be designed to be rule tree nodes containing multiple child nodes. The rule tree nodes do not need to be mapped out with a rule algorithm, and the child nodes of the rule tree can be mapped into a rule algorithm containing a simple rule.

[0092] 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 based on the connection relationship in the corresponding node information. Generally, if a Rule Tree node has child nodes, it has at least two child nodes. The trigger state of the Rule Tree node can be determined based on the trigger 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, thereby improving processing efficiency.

[0093] In one embodiment, the collection rule of the bottom-level node in the rule tree is a simple rule, while the collection rule of the non-bottom-level node in the rule tree corresponds to at least two simple rules. For the bottom-level node, its collection rule can be mapped to a simple rule algorithm, and the trigger state of the bottom-level node can be determined based on the execution rule tree data and the collection rule. For the non-bottom-level node, it is necessary to determine the trigger state of the non-bottom-level node based on the trigger state of the child node corresponding to the non-bottom-level node. In this way, in the process of executing the target rule tree, the trigger state of the rule tree node can be determined layer by layer, and the trigger state of the head node in the target rule tree can be finally determined. According to the trigger state of the head node in the target rule tree, the execution result of the target rule tree can be determined.

[0094] In one embodiment, determining the triggering state of the rule tree node according to the triggering state of the child node corresponding to the rule tree node includes:

[0095] The trigger state of the rule tree node is determined according to the trigger states of the sub-nodes and the logical relationship between the sub-nodes.

[0096] In this embodiment, for the second type of rules, it is also necessary to determine the logical relationship between at least two simple rules based on the collection rules. Based on these simple rules and the logical relationships between them, a complete collection rule can be formed. Correspondingly, the subnodes of a rule tree node also have logical relationships. Based on the connection relationship, the logical relationship between the subnodes corresponding to the rule tree node can also be determined to characterize the collection rules corresponding to the subnodes. Compared with the correlation between the collection rules corresponding to the rule tree node, the collection rules of the rule tree node can be accurately and comprehensively characterized based on the trigger status of the subnodes and the logical relationship between the subnodes, thereby accurately determining the trigger status.

[0097] In one example, referring to Figure 2For a rule tree node, its corresponding child nodes will have a logical relationship to express the relevance of the collection rules corresponding to the child nodes. Among them, logical relationships can include conjunction and / or disjunction. The conjunction relationship indicates that the rules corresponding to the two child nodes must be satisfied at the same time, and the disjunction relationship indicates that only one of the rules corresponding to the two child nodes needs to be satisfied. The conjunction relationship is an "and" relationship, represented by "and", and the disjunction relationship is an "or" relationship, represented by "or". By configuring this rule tree, you can flexibly configure it according to the relevance between rules, adapt to complex collection requirements, and accurately collect the required data.

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

[0099] 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 a target Rule Tree Node corresponding to the time window. The method further includes:

[0100] When the trigger state of the target rule tree node is triggered, the trigger state of the target rule tree node is maintained and the time window is started.

[0101] 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, it is necessary to maintain the trigger state of the node in the triggered state and start the time window.

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

[0103] If the execution result of the target Rule Tree is successful, stop maintaining the trigger state of the target Rule Tree node;

[0104] Alternatively, when the time window is closed, the triggering state of the target Rule Tree Node is stopped.

[0105] In this embodiment, the trigger state of the target Rule Tree Node is maintained and after the time window is started, the trigger state of the target Rule Tree Node may no longer be maintained until the execution result of the target Rule Tree is successful or the time window is closed.

[0106] In some embodiments, a preset opening duration of the time window may be configured for the time window. When the opening duration of the time window reaches the preset opening duration, the time window may be closed.

[0107] In some embodiments, by default, the target Rule Tree Node corresponding to a 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, it is possible to effectively solve the data collection requirement when a vehicle-side component reaches a certain state and another component reaches another state within a period of time after reaching a certain state.

[0108] In this embodiment, when the target Rule Tree is executed and the execution result of the Rule Tree is successful, data collection can be triggered to collect data corresponding to the target Rule Tree for the target object to obtain the triggered Rule Tree collected data. The triggered Rule Tree collected data is then stored 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 obtaining 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, the execution result of the target Rule Tree can be indicated as successful.

[0109] For a better understanding, a specific application example is provided below. Figure 4 The specific content described in the target rule tree is:

[0110] Collection rule 1: The previous frame enters the automatic parking mode:

[0111] APA_Mode_S=0x1:EnterAutomaticParkingMode

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

[0113] Collection rule 2: The APA function in the current frame identifies a risk and triggers an emergency brake:

[0114] APA_FailureBrakeMode_S=0x2:EmergencyEmergencyBraking

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

[0116] Collection Rule 3: The vehicle is in motion when Collection Rule 2 is detected (Collection Rule 3 is established only when Collection Rule 3.1 and Collection Rule 3.2 are satisfied at the same time);

[0117] Collection Rule 3.1: Vehicle speed status signal is available:

[0118] Vehicle_Speed_Stats_S=0x0

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

[0120] Collection Rule 3.2: Vehicle speed signal from IPB:

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

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

[0123] Collection rule 4: Braking deceleration is not greater than -5m / s2:

[0124] IPB_AX_S<=-5m / s2

[0125] Algorithm mapping: If the IPB_AX_S signal is less than or equal to the threshold: -5m / s2, it is mapped to the threshold algorithm;

[0126] Target rule tree trigger logic: Collection rule 1 && Collection rule 2 && Collection rule 3 && Collection rule 4;

[0127] Collection Rule 3: Collection Rule 3.1 || Collection Rule 3.2;

[0128] Type of data to be collected:

[0129] 1. Front view CAMERA + Pan view CAMERA;

[0130] 2. GNSS / IMU sensor data;

[0131] 3. Output of the perception module;

[0132] 4. Planning module output results;

[0133] 5. Positioning module output results;

[0134] 6. Control module output results;

[0135] 7. Chassis module output results (chassis module of the algorithm supplier);

[0136] Acquisition duration: 30 seconds before the trigger moment and 10 seconds after the trigger moment;

[0137] Time window: 3000ms.

[0138] The above-mentioned target rule tree has three layers in total, of which the first layer has one node, which is the head node; the second layer is the four child nodes of the head node, and the relationship between the nodes is "and", that is, the rules corresponding to the four nodes must be met at the same time to trigger the target rule tree; the third layer is the two child nodes of the third node of the second layer, and the relationship between the nodes is "or", that is, if any one of the two child nodes is triggered, the parent node is triggered. When the rule engine module executes the target rule tree, it maps each node to the corresponding algorithm, obtains the real-time value of the signal corresponding to each node from the redis database, and determines whether the signal value meets the corresponding collection rule. According to the relationship between the nodes, the final execution result of the target rule tree is output. If the rule engine module finally determines that the signal needs to be collected, the pre-defined signal is collected. In this embodiment, after the target rule tree is triggered, a total of seven vehicle-end signals are collected. The collection time is around 30 seconds before and 10 seconds after the collection time, and the collected data is stored in the database.

[0139] In addition, 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 the triggered state (even if the trigger condition is not met at the next moment). When the target rule tree is triggered or the time window reaches 3000 milliseconds, the time window closes. For the above target rule tree, assuming that Rule 2 meets the condition first, the time window opens at this time, and the Rule 2 node remains in the triggered state. After the target rule tree is triggered or the time window closes, the Rule 2 node returns to the untriggered state, and a new round of judgment is performed.

[0140] In one embodiment, obtaining a target rule-tree to be executed includes:

[0141] The target Rule-Tree is obtained from the Rule-Tree queue of the Rule Pool.

[0142] In this embodiment, referring to Figure 3 The rule engine module also includes a rule pool and a rule executor. The rule pool is used to store a rule tree queue. The rule tree queue includes at least one rule tree. Each rule tree in the rule tree queue can be used as a target rule tree to be executed. The rule engine module executor obtains the rule tree queue through the rule executor. The target rule trees in the rule tree queue are sequentially dequeued and executed according to the node information of the target rule tree. The vehicle data stored in the data storage module is collected based on the execution results of the target rule tree. When obtaining the target rule tree, the target rule tree can be obtained from the rule tree queue in sequence for execution to trigger data collection in an orderly manner.

[0143] In one embodiment, the method further comprises:

[0144] Determining the target rule tree based on the rule file;

[0145] The target Rule-Tree is stored in the Rule-Tree Queue.

[0146] In this embodiment, the target rule tree comes from a rule file defined based on the collection requirements. The rule pool in the rule engine module can receive the rule file, parse the received rule file, assemble the target rule tree, and place the target rule tree in the rule tree queue. The subsequent rule executor can retrieve the target rule tree from the rule tree queue of the rule pool and execute it.

[0147] In some embodiments, a rule tree for triggering data collection can be pre-defined based on the collection requirements, and the defined rule tree can be placed in a rule file and sent to the rule pool of the rule engine module. The rule pool parses the rule file, converts the rule tree in the rule file into a format that can be processed by the rule executor, and stores the converted rule tree as the target rule tree to be executed in the rule tree queue of the rule pool.

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

[0149] The target rule tree is assembled based on the collection rules.

[0150] In this embodiment, a set of collection rules that trigger data collection can also be pre-defined based on collection requirements, and the collection rules can be placed in a rule file and sent to the rule pool of the rule engine module. The rule pool parses the rule file to determine at least one collection rule. Based on the at least one parsed collection rule, a target rule tree to be executed can be assembled. The target rule tree is in a format that can be processed by the rule executor and is stored in a rule tree queue, waiting for the rule executor to obtain and execute it.

[0151] In one embodiment, when a preset suspension condition is met, the execution of the target rule-tree is suspended;

[0152] The preset pause condition includes receiving a rule file update signal and / or an update speed of the data storage module being lower than a preset speed.

[0153] In this embodiment, referring to Figure 3The rule engine module also includes startup management, which is used to manage the startup and suspension of the execution of the rule tree. When the preset suspension conditions are met, the execution of the target rule tree is suspended through startup management. The preset suspension conditions include receiving a rule file update signal and / or the update speed of the data storage module is lower than the preset speed. When the rule file update signal is received, the execution of the target rule tree is suspended, which can realize the hot distribution of the rule file. When the update speed of the data storage module is lower than the preset speed, the execution of the target rule tree is suspended. When the data in the data storage module is updated slowly or not updated, the execution of the rule tree can be suspended through startup management, thereby reducing the CPU running load.

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

[0155] The preset stop condition includes: receiving an update signal of the rule file, and / or an update speed of the data storage module being lower than a preset speed.

[0156] In this embodiment, referring to Figure 3 The rule engine module also includes a startup management unit, which is used to manage the rule executor to start and stop executing the target rule tree in the rule tree queue. When the preset stop condition is met, the rule executor is stopped from executing the target rule tree through the startup management unit. The preset stop condition includes receiving a rule file update signal, and / or the update speed of the data storage module is lower than the preset speed, etc. When the rule file update signal is received, the target rule tree is stopped from executing, which can realize the hot distribution of the rule file. When the update speed of the data storage module is lower than the preset speed, the target rule tree is stopped from executing. When the data in the data storage module is updated slowly or not updated, the rule executor can be stopped from executing the target rule tree through startup management, thereby reducing the CPU running load.

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

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

[0159] In this embodiment, upon receiving a rule file update signal, execution of the target rule tree is stopped, relevant data is saved, and the rule file corresponding to the update signal is then received through the rule pool to re-read the new rule file. Based on the new rule file, a new target rule tree is obtained, and the new target rule tree is updated to the rule tree queue to update the rule pool and complete the rule file update. Subsequently, based on the updated rule pool, the updated rule tree queue is loaded, and the rule executor is restarted to obtain and execute the target rule tree.

[0160] In one embodiment, when a preset start condition is met, executing the target Rule-Tree in the Rule-Tree Queue;

[0161] The preset start condition includes at least one of receiving a start instruction, completing the update of the rule file, and an update speed of the data storage module being greater than or equal to a preset speed.

[0162] In this embodiment, when preset start conditions are met, a rule tree queue in the rule pool is loaded, and the rule executor is started via the startup management module. The rule executor retrieves the target rule tree from the rule tree queue and executes it, initiating a new data collection process. The preset start conditions include at least one of: receiving a start instruction, completing a rule file update, and the data storage module's update speed being greater than or equal to a preset speed. The completion of the rule file update corresponds to the preset stop condition of receiving a rule file update signal. During the rule file update, the rule executor's execution can be paused to complete the hot delivery of the rule file. The data storage module's update speed being greater than or equal to the preset speed corresponds to the preset stop condition of the data storage module's update speed being less than the preset speed. If the data storage module is updating slowly or not at all, the rule executor can be stopped via startup management to execute the target rule tree, thereby reducing CPU load. When data updates resume in the data storage module, the rule executor can be restarted via startup management to resume execution of the target rule tree. By using the preset start conditions and the startup management module, the rule executor can be promptly started to execute the target rule tree in the rule tree queue, thereby improving the timeliness of data collection.

[0163] In one embodiment, the rule file is sent from the cloud.

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

[0165] This embodiment also provides a data acquisition device, which can be integrated into a vehicle, for example, Figure 6 As shown, the data acquisition device may include:

[0166] The rule engine module 1001 is used to obtain a target rule tree to be executed and collect vehicle data according to the node information in the target rule tree.

[0167] Optionally, the data acquisition device may further include a data storage module 1002 for storing vehicle data. The data storage module 1002 can access the vehicle's data interface to obtain real-time vehicle data for storage and updating. The rule engine module 1001 is further configured to obtain a target rule tree to be executed and, based on the node information in the target rule tree, to collect the vehicle data stored in the data storage module 1002.

[0168] Optionally, the rule engine module 1001 includes a rule pool and a rule executor;

[0169] The rule pool includes a rule tree queue;

[0170] 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 module 1002 according to the node information in the target rule tree.

[0171] Optionally, the rule engine module 1001 further includes a startup management unit;

[0172] The startup management unit is used to control the rule executor to stop executing the target rule tree when a preset stop condition is met; and to control the rule executor to execute the target rule tree in the rule tree queue when a preset startup condition is met;

[0173] Among them, the preset stop conditions include: receiving an update signal of the rule file, and / or the update speed of the data storage module 1002 is less than the preset speed; the preset start conditions include receiving a start instruction, completing the update of the rule file, and the update speed of the data storage module 1002 is greater than or equal to at least one of the preset speed.

[0174] Optionally, the rule executor is also used to execute the target rule tree according to the node information in the target rule tree, determine the trigger state of the rule tree node in the target rule tree, determine the execution result of the target rule tree according to the trigger state of the rule tree node, and collect vehicle data based on the execution result of the target rule tree.

[0175] Optionally, the node information includes a collection rule, and the rule executor is further configured to: map the collection rule into a rule algorithm;

[0176] The target rule tree is executed according to the execution rule tree data and rule algorithm corresponding to the target rule tree, and the trigger state of the rule tree node is determined. The execution rule tree data is the vehicle data required to execute the target rule tree.

[0177] Optionally, the rule algorithm includes at least one of a jump algorithm, a threshold algorithm and an interval algorithm.

[0178] Optionally, the rule executor is further configured to obtain execution rule-tree data corresponding to the target rule-tree from the vehicle data stored in the data storage module 1002 .

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

[0180] The vehicle data stored in the data storage module 1002 is collected based on the collection requirement information.

[0181] Optionally, the node information includes the connection relationship of the rule tree nodes, and the rule executor is further used to: 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; and determine the trigger state of the rule tree node according to the trigger state of the child nodes corresponding to the rule tree nodes.

[0182] Optionally, the rule executor is further configured to determine the trigger state of the rule tree node according to the trigger states of the sub-nodes and the logical relationship between the sub-nodes.

[0183] Optionally, the logical relationship includes a conjunction relationship and / or a disjunction relationship.

[0184] Optionally, the rule engine module 1001 further includes a time window management unit;

[0185] The time window management unit is used to control the rule executor to maintain the trigger state of the target rule tree node in the target rule tree when the trigger state of the target rule tree node in the target rule tree is triggered, and to start the time window configured by 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.

[0186] Optionally, the time window management unit is further configured to control the rule executor to stop maintaining the trigger state of the target rule tree node when the execution result of the target rule tree is successful; or to stop maintaining the trigger state of the target rule tree node when the time window is closed.

[0187] Optionally, the rule pool of the rule engine module 1001 is used to update the rule tree queue in the rule pool based on the received rule file; the rule file is sent from the cloud.

[0188] Optionally, the rule pool is further configured to receive a rule file corresponding to the update signal through the rule pool, and update the rule-tree queue based on the received rule file.

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

[0190] For example, referring to Figure 3 The vehicle includes a data acquisition device, which includes a rule engine module and a data storage module. The data storage module can be a database, which is connected to the vehicle's data interface to store real-time vehicle data. The rule engine module can also be connected to the cloud. The cloud serves as the source of rule files, configures rule files according to an agreed format, and sends 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.

[0191] The rule engine module drives the execution of rule trees and includes a rule pool, a startup management unit, a rule executor, and a time window management unit. The rule pool parses rule files sent from the cloud, assembles the target rule tree, and places the assembled target rule tree in a rule tree queue, waiting for the rule executor in the rule engine module to retrieve the target rule tree from the rule tree queue for execution.

[0192] The startup management unit can be used to manage the startup and suspension of the rule executor. When an update signal of the rule file is received during the execution of the rule executor, the execution of the current rule executor can be suspended, relevant data can be saved, the new rule file can be re-read, the rule pool can be updated, and the rule tree queue can be loaded according to the updated rule pool, and the rule executor can be restarted.

[0193] The rule executor sequentially retrieves the target Rule Trees to be executed from the Rule Tree Queue formed by the Rule Pool, reads the execution Rule Tree data required for executing the Rule Tree from the database, executes the target Rule Tree based on the execution Rule Tree data and the Rule Tree's node information, and determines the execution result of the target Rule Tree. After the Rule Tree Queue completes a round of execution, it can retrieve the Rule Tree from the beginning and continue the next round of execution.

[0194] In some embodiments, before configuring the rule file, a rule tree containing multiple acquisition rules can be configured according to the configuration specified by the simple rule algorithm, and the rule tree can be updated to the rule file. In this way, after the rule engine module receives the rule file and parses it, it converts the rule tree in the rule file into a target rule tree that can be processed by the rule executor, and can quickly obtain the assembled rule tree, thereby improving the assembly efficiency of the rule tree.

[0195] In some embodiments, the cloud-based rule file delivery is divided into hot delivery and cold delivery. Cold delivery of rule files: If the vehicle-side 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 through the vehicle-cloud link.

[0196] When the collection program of the rule executor is started, the target rule tree is being executed. If a rule file update signal is received, such as a request from the cloud, the rule executor can be stopped by starting the management unit, and then the rule file corresponding to the request is received through the vehicle-cloud link to update the vehicle-side rule file. After updating the rule tree queue in the rule pool, when the rule file update is completed, the rule engine module status is reset by starting the management unit, the rule tree queue is reloaded, and the rule executor is restarted to re-execute the rule tree queue.

[0197] For a better understanding, a specific application process is given below. Figure 7 :

[0198] 1. The cloud configures a rule file based on data collection requirements. This data collection requirement can be driven by vehicle intelligence R&D, user behavior and product optimization, or vehicle-side accident safety analysis. After configuring the rule file according to the agreed-upon format, the cloud sends it to the vehicle.

[0199] 2. Cloud rule file distribution, including hot distribution and cold distribution.

[0200] Among them, the cold distribution of rule files is completed when the vehicle-side acquisition program is in a static state and the rule tree of the rule pool has not been executed. The distribution can be completed directly through the vehicle-cloud link; the hot distribution of rule files is triggered when the vehicle-side acquisition program is in a running state and there is a target rule tree being executed by the rule executor. At this time, it is necessary to start the management unit to suspend the execution of the current rule engine module, and update the vehicle-side rule file through the vehicle-cloud link. After that, the rule engine module status is reset, the rule tree queue is reloaded, and the execution of the rule tree is restarted.

[0201] 3. Startup Management: Manage the status of the rule engine module through the startup management unit. In addition to managing the start and stop of the rule engine module when hot-delivering rule files, the startup management unit can also suspend the execution of the rule engine module when the data storage module storing vehicle data is updated slowly or not updated. When a new data source is available, it will restart the module to reduce CPU load.

[0202] 4. The rule engine module parses the rule file. The rule engine module parses the rule file sent from the cloud, assembles the rule tree, and places it into the rule tree queue of the rule pool. The rule engine module then drives the rule executor to obtain the rule tree from the rule tree queue and execute it.

[0203] 5. The rule engine module drives the target rule tree. The rule engine module 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 determines the trigger status of each node in the rule tree and comprehensively determines the execution result of the rule tree based on node information, whether the time window is open, and other factors.

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

[0205] Based on the above embodiments, full coverage of vehicle-side data collection can be achieved. With the application of intelligent technologies such as smart driving and smart cockpits, the dimension and breadth of vehicle-side data are also increasing day by day. In this context, it is not realistic to collect all vehicle-side data, and it is too rigid to only select specific data for collection. Based on this dilemma;

[0206] Based on the above embodiments, the collection requirements can be separated from the collection program, and the collection program does not change with the changes in the collection requirements. When the collection requirements are updated or there are new requirements, it is only necessary to reconfigure the rule file according to the requirements and send it to the vehicle side through the cloud. Based on this implementation, data collection can cover every data source on the vehicle side.

[0207] Based on the above embodiments, data collection in complex scenarios can be adapted. By configuring a multi-branch rule tree and establishing connections between rules, it can address the need to collect data when multiple vehicle-side signals reach specific states within a period of time. The depth and breadth of the rule tree are unlimited, meaning that in theory, it can adapt to extremely complex data collection needs. This is particularly important in today's era of intelligent vehicles, where the number of vehicle body data terminals is increasing and multiple terminals work together.

[0208] Based on the above embodiments, lightweight vehicle-side data collection can be achieved. When collecting signal data, the present invention does not mechanically collect data for all continuous periods of the signal. Instead, it formulates collection rules to collect data at the time point or time period surrounding the moment when one or more signals reach a specific state. On the one hand, data that is truly valuable to the demand side is collected, and the demand side does not need to perform secondary screening. On the other hand, only collecting key data can greatly alleviate storage pressure.

[0209] Based on the above embodiments, secondary development of the program can be avoided, and the difficulty of program maintenance and use can be reduced. As mentioned above, which data needs to be collected is not determined by the collection program, but by the rule file. Therefore, when the collection requirements are updated, the rule file can 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 principles of the program. When there are new requirements changes, it is only necessary to modify the collection configuration file according to the multi-branch rule tree structure and send it to the vehicle side. The vehicle side automatically parses the new requirements and realizes the collection. The logic of the rule engine module greatly enhances the versatility and universality of the system.

[0210] In summary, the embodiment of the present application, through the rule engine module strategy, can cover all data sources on the vehicle side while achieving lightweight collection, and collect key data that is beneficial to data demanders in the face of massive data generated by the vehicle side; through the multi-branch rule tree strategy, 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.

[0211] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0212] Accordingly, the present application also provides a data acquisition device, such as Figure 8 As shown, Figure 8 Schematic diagram of the structure of the data acquisition device provided in an embodiment of the present application. The data acquisition device 1100 also includes a processor 1101 having one or more processing cores, a memory 1102 having one or more computer-readable storage media, and a computer program stored in the memory 1102 and executable on the processor. The processor 1101 is electrically connected to the memory 1102. It will be understood by those skilled in the art that the data acquisition device structure shown in the figure does not constitute a limitation on the data acquisition device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0213] Processor 1101 is the control center of data acquisition device 1100. It connects the various components of data acquisition device 1100 using various interfaces and lines. By running or loading software programs and / or units stored in memory 1102 and accessing data stored in memory 1102, it executes various functions of data acquisition device 1100 and processes data, thereby monitoring data acquisition device 1100 as a whole. Processor 1101 can be a processor (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU), a network processor (Network Processor, NP), etc., and can implement or execute the various methods, steps, and logic blocks disclosed in the embodiments of this application.

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

[0215] Get the target rule tree to be executed;

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

[0217] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0218] Optional, such as Figure 8 As shown, the data acquisition device 1100 further includes: a touch screen 1103, a radio frequency circuit 1104, an audio circuit 1105, an input unit 1106, and a power supply 1107. Among them, the processor 1101 is electrically connected to the touch screen 1103, the radio frequency circuit 1104, the audio circuit 1105, the input unit 1106, and the power supply 1107 respectively. It can be understood by those skilled in the art that Figure 8 The data acquisition device structure shown in does not constitute a limitation to the data acquisition device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0219] The touch display screen 1103 can be used to display a graphical user interface and receive user actions on the operation instructions generated by the graphical user interface. The touch display screen 1103 may include a display panel and a touch panel. Among them, the display panel can be used to display information input by the user or information provided to the user and various graphical user interfaces of the data acquisition device, and these graphical user interfaces can be composed of graphics, text, icons, videos and any combination thereof. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. The touch panel can be used to collect the touch operation of the user on or near it (such as the user uses any suitable object or accessory such as a finger, a stylus, etc. on the touch panel or near the touch panel), and generate corresponding operation instructions, and the operation instructions execute corresponding programs. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch direction, detects the signal caused by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 1101, and can receive commands sent by the processor 1101 and execute them. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it is transmitted to the processor 1101 to determine the type of touch event. The processor 1101 then provides a corresponding visual output on the display panel according to the type of touch event. In an embodiment of the present invention, the touch panel and the display panel can be integrated into the touch display screen 1103 to realize input and output functions. However, in some embodiments, the touch panel and the touch panel can be used as two independent components to realize input and output functions. That is, the touch display screen 1103 can also be used as part of the input unit 1106 to realize the input function.

[0220] The radio frequency circuit 1104 can be used to send and receive radio frequency signals to establish wireless communication with network medical devices or other data acquisition devices through wireless communication, and to send and receive signals between 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 microphone. Audio circuit 1105 can convert received audio data into electrical signals and transmit them to the speaker, which then converts them into sound signals for output. The microphone, on the other hand, converts the collected sound signals into electrical signals, which are then received by audio circuit 1105 and converted into audio data. The audio data is then output to processor 1101 for processing, and then transmitted via RF circuit 1104 to, for example, another data acquisition device. Alternatively, the audio data can be 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 unit 1106 may be configured to receive input digital, character information, or user feature information (such as fingerprint, iris, or facial information), and to generate keyboard, mouse, joystick, optical, or trackball signal input 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 via a power management device, thereby enabling the power management device to manage charging, discharging, and power consumption. Power supply 1107 can also include one or more DC or AC power supplies, a recharging device, a power failure detection circuit, a power converter or inverter, a power status indicator, and other arbitrary components.

[0224] although Figure 8 Not shown in the figure, the data acquisition device 1100 may also include a camera, a sensor, a wireless fidelity module, a Bluetooth module, etc., which will not be repeated here.

[0225] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

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

[0227] To this end, an embodiment of the present application provides a computer-readable storage medium storing a plurality of computer programs. The computer programs can be loaded by a processor to execute any one of the data collection methods provided in the embodiments of the present application. The computer programs can execute the following steps of the data collection method:

[0228] Get the target rule tree to be executed;

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

[0230] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

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

[0232] Since the computer-readable storage medium can implement the beneficially stored computer program that can be implemented by any data collection method provided in the embodiments of the present application, it can execute any data collection method provided in the embodiments of the present application. Therefore, the effect is detailed in the previous embodiments and will not be repeated here.

[0233] The present application also provides a computer program product, which includes a computer program. The computer program can be loaded by a processor to execute any of the data collection methods provided in the present application. The computer program can execute the following steps of the data collection method:

[0234] Get the target rule tree to be executed;

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

[0236] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0237] Since the computer program product can implement the beneficially stored computer program that can be implemented by any data collection method provided in the embodiments of the present application, and can execute any data collection method provided in the embodiments of the present application, the effects are detailed in the previous embodiments and will not be repeated here.

[0238] Optionally, an embodiment of the present application further provides a vehicle, which includes any of the above data acquisition devices, data acquisition equipment, computer-readable storage media, and computer program products, and executes any of the above methods.

[0239] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0240] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0241] The embodiments, implementation methods and related technical features of the present application can be combined and replaced with each other without conflict.

[0242] The above are merely preferred embodiments of the present application and do not constitute any form of limitation to the present application. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present application without departing from the content of the technical solution of the present application are still within the scope of the technical solution of the present application.

Claims

1. A data collection method, characterized in that: include: Get the target rule tree to be executed; Vehicle data is collected according to the node information in the target rule tree.

2. The data collection method according to claim 1, wherein: The collecting of vehicle data according to the node information in the target rule tree includes: Executing the target Rule Tree according to the node information in the target Rule Tree, and determining an execution result of the target Rule Tree; The vehicle data is collected based on the execution result of the target rule tree.

3. The data collection method according to claim 2, wherein: The executing the target Rule Tree according to 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 status of the Rule Tree nodes in the target Rule Tree; Determine the execution result of the target Rule Tree according to the triggering status of the Rule Tree node.

4. The data collection method according to claim 3, wherein: The node information includes a collection rule, and executing the target Rule Tree according to the node information in the target Rule Tree to determine a trigger state of a Rule Tree node in the target Rule Tree includes: Mapping the acquisition rules into rule algorithms; 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 trigger state of the Rule Tree node is determined, where the execution Rule Tree data is the vehicle data required to execute the target Rule Tree.

5. The data collection method according to claim 4, wherein: The rule algorithm includes at least one of a jump algorithm, a threshold algorithm and an interval algorithm.

6. The data collection method according to claim 4, wherein: Before mapping the collection rules into 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 module.

7. The data collection method according to claim 3, wherein: The node information includes a connection relationship of the Rule Tree nodes, and executing the target Rule Tree according to the node information in the target Rule Tree and determining the trigger status 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 according to the triggering state of the child node corresponding to the rule tree node.

8. The data collection method according to claim 7, wherein: The determining the triggering state of the rule tree node according to the triggering state of the child node corresponding to the rule tree node includes: The trigger state of the rule tree node is determined according to the trigger states of the sub-nodes and the logical relationship between the sub-nodes.

9. The data collection method according to claim 8, wherein: The logical relationship includes a conjunction relationship and / or a disjunction relationship.

10. The data collection method according to claim 3, wherein: The target Rule Tree is configured with a time window, at least one Rule Tree Node in the target Rule Tree is a target Rule Tree Node corresponding to the time window, and the method further includes: When the trigger state of the target rule tree node is triggered, the trigger state of the target rule tree node is maintained and the time window is started.

11. The data collection method according to claim 10, wherein: After maintaining the trigger state of the target rule tree node and starting the time window, the method further includes: If the execution result of the target Rule Tree is successful, stop maintaining the trigger state of the target Rule Tree node; Alternatively, when the time window is closed, the triggering state of the target Rule Tree Node is stopped.

12. The data collection method according to claim 2, wherein: The collecting of the vehicle data based on the execution result of the target rule tree further includes: Based on the execution result of the target rule tree, obtaining collection requirement information associated with the target rule tree; Based on the collection requirement information, the vehicle data stored in the data storage module is collected.

13. The data collection method according to claim 12, wherein: The collection requirement information includes at least one of collection data type, collection time and collection frequency.

14. The data collection method according to claim 1, wherein: The step of obtaining a 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 collection method according to claim 14, wherein: The method further comprises: Determining the target rule tree based on the rule file; The target Rule-Tree is stored in the Rule-Tree Queue.

16. The data collection method according to claim 15, wherein: The determining the target rule tree based on the rule file includes: Determining at least one collection rule based on the rule file; The target rule tree is assembled based on the collection rules.

17. The data collection method according to claim 15, wherein: The method further comprises: When a preset stop condition is met, stop executing the target rule tree; The preset stop condition includes: receiving an update signal of the rule file, and / or an update speed of the data storage module being lower than a preset speed.

18. The data collection method according to claim 17, wherein: After stopping 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 collection method according to claim 15, wherein: The method further comprises: When a preset start condition is met, executing the target Rule-Tree in the Rule-Tree queue; The preset start condition includes at least one of: receiving a start instruction, completing the update of the rule file, and an update speed of the data storage module being greater than or equal to a preset speed.

20. The data collection method according to claim 15, wherein: The rule file is sent from the cloud.

21. A data acquisition device, characterized in that: The method comprises a processor connected to a memory, wherein the memory stores a computer program, and the processor is used to run the computer program in the memory to execute the data acquisition method according to any one of claims 1 to 20.

22. A data acquisition device, characterized in that: The data acquisition device comprises: A rule engine module is used to obtain a target rule tree to be executed and collect vehicle data according to node information in the target rule tree.

23. The data acquisition device according to claim 22, wherein: The data acquisition device includes a data storage module, and the data storage module is used to store the vehicle data; The rule engine module is further configured to obtain a target rule tree to be executed, and collect the vehicle data stored in the data storage module according to node information in the target rule tree.

24. The data acquisition device according to claim 22, wherein: The rule engine module 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 according to claim 24, wherein: The rule engine module also includes a startup management unit; The startup management unit is configured to control the rule executor to stop executing the target rule tree when a preset stop condition is met; and, when a preset start condition is met, controlling the rule executor to execute the target Rule-Tree in the Rule-Tree queue; Among them, the preset stop conditions include: receiving an update signal of the rule file, and / or the update speed of the data storage module is less than the preset speed; the preset start conditions include receiving a start instruction, the rule file update is completed, and the update speed of the data storage module is greater than or equal to at least one of the preset speed.

26. The data acquisition device according to claim 24, 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 status of the rule tree nodes in the target rule tree, determine the execution result of the target rule tree according to the triggering status of the rule tree nodes, and collect the vehicle data based on the execution result of the target rule tree.

27. The data acquisition device according to claim 26, wherein: The rule engine module also includes a time window management unit; The time window management unit is used to control the rule executor to maintain the trigger state of the target rule tree node of the target rule tree when the trigger state of the target rule tree node is triggered, and to start the time window configured by the target rule tree, wherein at least one of the rule tree nodes in the target rule tree is the target rule tree node corresponding to the time window.

28. The data acquisition device according to claim 24, wherein: The rule engine module is used to update the rule tree queue in the rule pool based on the received rule file; the rule file is issued by the cloud.

29. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the data collection method according to any one of claims 1 to 20 is implemented.

30. A computer program product, characterized in that The computer program comprises a computer program, and the computer program is executed by a processor to implement the data collection method according to any one of claims 1 to 20.

31. A vehicle, characterized in that: The vehicle executes the data acquisition method according to any one of claims 1 to 20, or includes the data acquisition equipment according to claim 21 or the data acquisition device according to any one of claims 22 to 28.

Images