Vehicle fault diagnosis method and device, computer device, medium and program product

Abstract

The application relates to a vehicle fault diagnosis method and device, computer equipment, a medium and a program product, which can be used in the technical field of vehicles. The method comprises the following steps: acquiring a plurality of stage events corresponding to a control instruction of a vehicle, and determining a target stage event; determining an initial candidate fault cause set corresponding to the target stage event; screening target vehicle fault diagnosis data items from candidate vehicle fault diagnosis data items according to the initial candidate fault cause set and resource budget information; acquiring actual observation data of the target vehicle fault diagnosis data items, and performing screening processing on the initial candidate fault cause set according to the actual observation data to obtain a target candidate fault cause set; generating fault diagnosis data according to the actual observation data and the target candidate fault cause set, and sending the fault diagnosis data to a vehicle fault diagnosis server to enable the vehicle fault diagnosis server to perform fault diagnosis processing on the vehicle. The method can improve the efficiency of vehicle fault diagnosis.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle fault diagnosis method, apparatus, computer equipment, medium, and program product. Background Technology

[0002] With the rapid development of automotive intelligent technology, vehicle fault diagnosis technology has become an important research direction in the field of intelligent vehicles in order to ensure the safe and stable operation of vehicles.

[0003] Currently, vehicle fault diagnosis typically relies on onboard terminals to collect all vehicle data and upload it directly to a server for centralized analysis. However, given the massive amounts of vehicle data and limited network transmission resources, this indiscriminate data collection and processing method is time-consuming, resulting in low efficiency in vehicle fault diagnosis. Summary of the Invention

[0004] Therefore, it is necessary to provide a vehicle fault diagnosis method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency of vehicle fault diagnosis in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a vehicle fault diagnosis method. The method includes:

[0006] The system acquires multiple stage events corresponding to the vehicle's control commands, and determines the target stage event where the operational anomaly occurs based on the sequential dependencies between these multiple stage events.

[0007] Determine the initial set of candidate fault causes corresponding to the target stage event;

[0008] Based on the initial candidate fault cause set and the preset resource budget information, the target vehicle fault diagnosis data item is selected from the preset candidate vehicle fault diagnosis data items.

[0009] Obtain actual observation data of the target vehicle fault diagnosis data item, and filter the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set;

[0010] Based on the actual observation data and the target candidate fault cause set, fault diagnosis data for the vehicle is generated, and the fault diagnosis data is sent to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

[0011] In one embodiment, the step of selecting target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items based on the initial candidate fault cause set and preset resource budget information includes:

[0012] From the candidate vehicle fault diagnosis data items, determine the candidate vehicle fault diagnosis data items that are associated with the target stage event, associated with the initial candidate fault cause set, and are in the preset list allowable state;

[0013] Obtain the privacy cost information, resource cost information, and authorization status information of the candidate vehicle fault diagnosis data items;

[0014] Based on the privacy cost information, the resource cost information, the authorization status information, and the resource budget information, the target vehicle fault diagnosis data item is selected from the candidate vehicle fault diagnosis data items.

[0015] In one embodiment, the resource budget information includes privacy budget information and computing resource budget information;

[0016] The step of selecting the target vehicle fault diagnosis data item from the candidate vehicle fault diagnosis data items based on the privacy cost information, the resource cost information, the authorization status information, and the resource budget information includes:

[0017] From the candidate vehicle fault diagnosis data items, at least one of the following is removed: vehicle fault diagnosis data items whose authorization status information indicates unauthorized vehicle fault diagnosis data items, vehicle fault diagnosis data items whose privacy cost information exceeds the privacy budget information, and vehicle fault diagnosis data items whose resource cost information exceeds the computing resource budget information, to obtain the target vehicle fault diagnosis data item.

[0018] In one embodiment, the step of acquiring actual observation data of the target vehicle fault diagnosis data item, and filtering the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set, includes:

[0019] The actual observation data is acquired within the preset sampling window corresponding to the target vehicle fault diagnosis data item;

[0020] Based on the preset exclusion information matrix and the actual observation data, conflicting candidate fault causes are removed from the initial candidate fault cause set to obtain the target candidate fault cause set.

[0021] In one embodiment, generating the vehicle's fault diagnosis data based on the actual observation data and the target candidate fault cause set includes:

[0022] The actual observation data is subjected to desensitization and transformation processing to obtain the target diagnostic feature vector corresponding to the actual observation data;

[0023] The fault diagnosis data is generated based on the target diagnostic feature vector, the target stage event, and the target candidate fault cause set.

[0024] In one embodiment, after sending the fault diagnosis data to the vehicle fault diagnosis server, the method further includes:

[0025] Receive data supplementation requests from the vehicle fault diagnosis server in response to the fault diagnosis data;

[0026] The data supplementation request is validated to obtain the validation result of the data supplementation request;

[0027] If the verification result indicates that the verification is successful, supplementary vehicle fault diagnosis data items are determined from the candidate vehicle fault diagnosis data items based on the data supplementation request and the current remaining resource budget information of the vehicle.

[0028] Obtain supplementary observation data for the supplementary vehicle fault diagnosis data item, and filter the target candidate fault cause set based on the supplementary observation data to obtain the filtered candidate fault cause set.

[0029] Based on the supplementary observation data and the filtered set of candidate fault causes, supplementary fault diagnosis data for the vehicle is generated, and the supplementary fault diagnosis data is sent to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can perform a second fault diagnosis on the vehicle based on the supplementary fault diagnosis data.

[0030] In one embodiment, determining the target stage event where the operational anomaly occurred from the plurality of stage events based on the sequential dependencies between the stage events includes:

[0031] Perform state verification processing on the multiple stage events to obtain the state verification result of each stage event;

[0032] Based on the status verification results of each stage event, determine the abnormal stage event that caused the operational abnormality from the multiple stage events;

[0033] Based on the aforementioned sequential dependency relationship, the abnormal stage event that ranks first among the abnormal stage events is determined as the target stage event.

[0034] Secondly, this application also provides a vehicle fault diagnosis device. The device includes:

[0035] The event determination module is used to acquire multiple stage events corresponding to the vehicle's control commands, and based on the sequential dependencies between the multiple stage events, determine the target stage event in which the operation abnormality occurs from the multiple stage events;

[0036] The set determination module is used to determine the initial set of candidate fault causes corresponding to the target stage event;

[0037] The data filtering module is used to filter out target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items based on the initial candidate fault cause set and preset resource budget information.

[0038] The set filtering module is used to obtain the actual observation data of the target vehicle fault diagnosis data item, and to filter the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set.

[0039] The data sending module is used to generate fault diagnosis data for the vehicle based on the actual observation data and the target candidate fault cause set, and send the fault diagnosis data to the vehicle fault diagnosis server so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

[0040] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0042] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above aspects.

[0043] The above vehicle fault diagnosis method, apparatus, computer device, computer-readable storage medium and computer program product, by acquiring a plurality of stage events corresponding to control instructions of a vehicle, and determining a target stage event with operation abnormality based on the sequential dependency relationship between the plurality of stage events, is beneficial to accurately locking the specific business link where the fault occurs; by determining an initial candidate fault cause set corresponding to the target stage event, it is beneficial to initially delimiting the scope of fault troubleshooting; by screening target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items according to the initial candidate fault cause set and preset resource budget information, it is beneficial to accurately determining the diagnostic data to be collected under the condition of limited budget resources, avoiding blind collection; by acquiring actual observation data of the target vehicle fault diagnosis data items, and screening the initial candidate fault cause set according to the actual observation data to obtain a target candidate fault cause set, it is beneficial to using the actual data to eliminate irrelevant causes and narrow the fault localization scope; by generating vehicle fault diagnosis data according to the actual observation data and the target candidate fault cause set and sending the data to the vehicle fault diagnosis server, it is beneficial for the server to perform vehicle fault diagnosis based on accurate and filtered data, thereby improving the efficiency and accuracy of vehicle fault diagnosis. Brief Description of the Drawings

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required in the description of the embodiments or related technologies. Obviously, the drawings described below show only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without any creative effort.

[0045] Figure 1 is a schematic flowchart of a vehicle fault diagnosis method in one embodiment;

[0046] Figure 2 is a schematic diagram of a generation process of the minimum diagnostic feature set on the end side in one embodiment;

[0047] Figure 3 is a schematic diagram of a restricted incremental supplement process under low confidence in one embodiment;

[0048] Figure 4 is a schematic diagram of the functional module relationship of the end-side diagnostic data generation apparatus in one embodiment;

[0049] Figure 5 is a structural block diagram of a vehicle fault diagnosis apparatus in one embodiment;

[0050] Figure 6 is an internal structure diagram of a computer device in one embodiment. Detailed Description of the Embodiments

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0053] In the fields of vehicle networking, remote vehicle control, terminal-side data processing, and privacy protection, traditional vehicle fault diagnosis solutions have many limitations. Some existing solutions focus on comparing and correlating data collected from multiple nodes to locate abnormal nodes across the entire chain, or on extracting, caching, compressing, and uploading vehicle logs according to a preset time range. Other solutions focus on lifecycle control of ordinary and privacy data and middleware isolation. Furthermore, some edge-cloud collaborative diagnostic solutions use edge-side diagnostic models to generate candidate events or fault probabilities and upload them to the cloud via encoder dimensionality reduction or feature vectors. However, uploading complete logs may carry vehicle identifiers, account identifiers, precise locations, original control parameters, original messages, Bluetooth peripheral identifiers, or long-term sequence signals, and the sampling, transmission, and storage scope may cover normal phases unrelated to the current anomaly. Simply compressing, encrypting, managing the lifecycle, or classifying existing logs as ordinary / privacy-related cannot determine which fields must be sampled to distinguish the current candidate fault cause, which do not, for how long, and when to stop. Fixed data entry points also cannot be adjusted according to changes in the anomaly stage and candidate causes, easily leading to the continuous reporting of irrelevant fields or the loss of key distinguishing fields. To address the issues of minimizing the outward transmission of sensitive data while ensuring fault distinguishability, and the low efficiency and accuracy of vehicle fault diagnosis, this application proposes a vehicle fault diagnosis method, specifically a method for generating and supplementing the minimum diagnostic feature set at the end side driven by the abnormal phase of the vehicle control state machine.

[0054] In one exemplary embodiment, such as Figure 1As shown, a vehicle fault diagnosis method is provided. This embodiment illustrates the application of this method to a terminal (e.g., an in-vehicle terminal, or a terminal used to control the vehicle, which is not limited here). It is understood that this method can also be applied to a server, or to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.; the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps:

[0055] Step S101: Obtain multiple stage events corresponding to the vehicle control command; based on the sequential dependency relationship between the multiple stage events, determine the target stage event where the operation abnormality occurs from the multiple stage events.

[0056] Step S102: Determine the initial set of candidate fault causes corresponding to the target stage event;

[0057] Step S103: Based on the initial candidate fault cause set and the preset resource budget information, select the target vehicle fault diagnosis data item from the preset candidate vehicle fault diagnosis data items.

[0058] Step S104: Obtain the actual observation data of the target vehicle fault diagnosis data item; based on the actual observation data, filter the initial candidate fault cause set to obtain the target candidate fault cause set.

[0059] Step S105: Based on the actual observation data and the target candidate fault cause set, generate vehicle fault diagnosis data and send the fault diagnosis data to the vehicle fault diagnosis server so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

[0060] Among them, the stage events can be the events of various business nodes that the vehicle control command goes through during the execution process, such as command sending events, network connection events, identity authentication events, server receiving events, vehicle receipt events, and vehicle condition verification events.

[0061] Among them, the target stage event can be the first abnormal stage event among the above multiple stage events that fails, times out, has a contradictory state, or fails to meet the preset completion conditions.

[0062] The initial candidate fault cause set can be a set of fault causes that can lead to an anomaly, which are initially determined for the target stage event based on a pre-set mapping relationship between the anomaly stage and the candidate causes. For example, it can include one or more of the following: session anomaly, downlink network anomaly, vehicle offline or hibernation, and vehicle not executing.

[0063] The resource budget information can be information used to limit the amount of data collection and processing consumption. For example, it can include privacy budget information and resource usage budget information. Privacy budget information can refer to the weighted sum and upper limit of data sensitivity level, and resource usage budget information can refer to one or more of the following: the upper limit of allowed sampling duration, the upper limit of CPU computing power, the upper limit of cache bytes, and the upper limit of outgoing bytes.

[0064] Among them, the candidate vehicle fault diagnosis data items can be pre-registered data feature groups that can be used for fault investigation, such as the recent heartbeat summary feature group, the message queue telemetry transmission stage delay feature group, the network context feature group, and the vehicle status summary feature group.

[0065] Among them, the target vehicle fault diagnosis data item can be a group of data features selected from the candidate vehicle fault diagnosis data items by combining resource budget information, which can make the fault cause discrimination greater than the preset discrimination threshold within the budget.

[0066] The actual observation data can be the actual values ​​collected for the fault diagnosis data items of the target vehicle within a preset limited sampling window, such as state enumeration values, relative delay bin data, statistical bin data, or error family enumeration values.

[0067] The target candidate fault cause set can be the set of remaining candidate fault causes that have not been eliminated after conditionally eliminating the initial candidate fault cause set using actual observation data.

[0068] Among them, the fault diagnosis data can be a diagnostic feature package generated based on actual observation data and used to upload to the server. The diagnostic feature package contains state enumeration, relative delay binning, statistical binning or error family mapping data that have been desensitized and transformed, and does not contain the original vehicle identification code, account identifier, precise location information or cross-session stable identifier.

[0069] Among them, the vehicle fault diagnosis server can be a server or cloud platform deployed in the cloud to receive fault diagnosis data and output the final fault attribution result and attribution confidence based on the fault diagnosis data.

[0070] Optionally, the terminal acquires multiple stage events corresponding to the vehicle's control commands, and based on the sequential dependencies between these events, determines the target stage event where the operational anomaly occurs. It then determines an initial set of candidate fault causes corresponding to the target stage event. Based on the initial set of candidate fault causes and preset resource budget information, it filters out the target vehicle fault diagnosis data item from preset candidate vehicle fault diagnosis data items. The terminal acquires actual observation data for the target vehicle fault diagnosis data item and, based on this data, filters the initial set of candidate fault causes to obtain the target set of candidate fault causes. Finally, based on the actual observation data and the target set of candidate fault causes, it generates vehicle fault diagnosis data and sends this data to the vehicle fault diagnosis server, enabling the server to perform fault diagnosis processing on the vehicle based on the data.

[0071] For example, the terminal sequentially records multiple stages of events corresponding to vehicle control commands, such as command sending, network connection, and identity authentication. It monitors these stages based on their sequential dependencies. If a stage event fails, times out, or exhibits a contradictory state, it identifies that stage as the target stage event indicating an operational anomaly. Based on a pre-defined mapping relationship, it determines an initial set of candidate fault causes corresponding to the target stage event. When determining which data needs to be collected for further troubleshooting, it reads pre-defined resource budget information, such as privacy budget limits and computing resource limits. Based on the initial set of candidate fault causes and the resource budget information, it selects data from pre-defined candidate vehicle fault diagnosis data items that meet the budget requirements. Find the target vehicle fault diagnosis data items with a discrimination index greater than a preset discrimination index threshold; within a limited sampling time window, acquire the actual observation data of the target vehicle fault diagnosis data items, and use the actual observation data to trigger preset exclusion rules to remove irrelevant causes in the initial candidate fault cause set, thereby obtaining a narrowed target candidate fault cause set; convert the actual observation data into enumeration values ​​or statistical values ​​that do not contain original sensitive information, and combine them with the target candidate fault cause set to generate vehicle fault diagnosis data, and send the fault diagnosis data to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can output the final fault attribution result based on the fault diagnosis data, thereby completing the vehicle fault diagnosis process.

[0072] For example, Figure 2 This is a schematic diagram of the process for generating the minimum diagnostic feature set on the edge side, including: associating stage events of the same vehicle control session, determining abnormal stages and forming a candidate fault cause set, reading the distinguishing benefits of feature groups, privacy / resource costs and authorization status, selecting the minimum feature group within the budget and starting a finite sampling window, shrinking the candidate fault cause set according to the actual feature values, generating a controlled diagnostic vector and uploading it.

[0073] In this application, the diagnostic scope is narrowed down by the abnormal stage of the vehicle control state machine, and the candidate fault causes are verifiablely narrowed down by actual feature values. It combines minimum feature selection, end-side controlled transitions, and a limited supplementary closed loop under low confidence (i.e., confidence less than a preset confidence threshold). The terminal creates a short-lifecycle diagnostic session identifier, associating events from the same control request's sending, connection, authentication, server reception, vehicle receipt, and vehicle condition verification stages. The identifier is generated by a local random number, a rotating key, the instruction category, and a time bucket, and expires after the session ends. It does not use VIN (Vehicle Identification Number), account, number, device MAC (Media Access Control), fixed hash, or other cross-session stable association identifiers. The vehicle control session is not bounded by a single network request, but by the sequence of stage events corresponding to a control intent. The session construction module receives control instruction trigger events and sequentially records stage events such as local pre-verification, channel selection, connection establishment, authentication or key negotiation, instruction sending, server reception confirmation, downlink delivery, vehicle receipt, and vehicle condition verification. Each stage event is associated with at least the stage code, relative time, state enumeration, error family enumeration, and a random associated flag within the session. The associated flag is derived from a local random number, the session start time bucket, the instruction category, and the rotation key. It is used only during the session's validity period and expires after the session is closed, times out, or a diagnostic packet is confirmed and enqueued.

[0074] In the aforementioned vehicle fault diagnosis method, by acquiring multiple stage events corresponding to the vehicle's control commands and determining the target stage event where the operational anomaly occurs based on the sequential dependencies between these events, it is beneficial to accurately pinpoint the specific business process where the fault occurs. By determining the initial set of candidate fault causes corresponding to the target stage event, it is beneficial to initially define the scope of fault investigation. By filtering the target vehicle fault diagnosis data item from the preset candidate vehicle fault diagnosis data items based on the initial set of candidate fault causes and preset resource budget information, it is beneficial to accurately determine the diagnostic data to be collected under limited budget resources, avoiding blind collection. By acquiring the actual observation data of the target vehicle fault diagnosis data item and filtering the initial set of candidate fault causes based on the actual observation data to obtain the target candidate fault cause set, it is beneficial to use actual data to eliminate irrelevant causes and narrow down the fault location range. By generating vehicle fault diagnosis data based on the actual observation data and the target candidate fault cause set and sending it to the vehicle fault diagnosis server, it is beneficial for the server to perform vehicle fault diagnosis based on accurate and filtered data, thereby improving the efficiency and accuracy of vehicle fault diagnosis.

[0075] In an exemplary embodiment, the process of selecting target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items based on an initial set of candidate fault causes and preset resource budget information includes: determining candidate vehicle fault diagnosis data items from the candidate vehicle fault diagnosis data items that are associated with a target stage event, associated with the initial set of candidate fault causes, and in a preset list-allowed state; obtaining privacy cost information, resource cost information, and authorization status information of the candidate vehicle fault diagnosis data items; and selecting target vehicle fault diagnosis data items from the candidate vehicle fault diagnosis data items based on the privacy cost information, resource cost information, authorization status information, and resource budget information.

[0076] Among them, the candidate vehicle fault diagnosis data items can be feature data groups that have been initially filtered, are applicable to the current abnormal scenario in terms of business logic, and are allowed by the activity policy whitelist.

[0077] The preset list's allowed status can be a status marked as allowed to collect and read in the activity policy whitelist issued by the cloud.

[0078] Among them, privacy cost information can be a quantitative indicator that represents the degree of user privacy exposure involved in collecting the data item, such as sensitivity level or privacy weight score.

[0079] Among them, resource cost information can be a quantitative indicator representing the terminal system resources required to collect and process the data item, such as the sampling time, computation amount, or storage bytes required.

[0080] The authorization status information can be an authorization identifier indicating whether the current vehicle user has agreed to the collection of this type of data.

[0081] Optionally, after determining the initial set of candidate fault causes, the terminal performs preliminary matching from the preset candidate vehicle fault diagnosis data items, selecting candidate vehicle fault diagnosis data items that are associated with both the current target stage event and the initial set of candidate fault causes, and whose status is in the preset list of allowed states; reads and obtains the privacy cost information, resource cost information, and user authorization status information corresponding to these candidate vehicle fault diagnosis data items; compares the privacy cost information, resource cost information, and authorization status information with the resource budget information of the current session, and filters out target vehicle fault diagnosis data items that meet the budget requirements and have been authorized from the candidate vehicle fault diagnosis data items.

[0082] For example, the feature policy uses feature groups as the minimum authorization and sampling unit, rather than individual raw fields. Each feature group includes at least: feature group identifier, applicable anomaly stage set, candidate fault cause set, sampling start and end conditions, maximum sampling window, controlled transformation function, fault differentiation benefit, privacy cost, resource cost, authorization requirements, maximum supplementary rounds, and policy version. Feature groups can be pre-defined within the application version or updated by a signed policy file. For the current candidate fault cause set, the terminal first constructs a candidate range that is applicable to the current anomaly stage, associated with the candidate fault cause set, and belongs to the locally pre-registered feature groups, and removes feature groups that are not authorized, not whitelisted by the activity policy, have expired policies, have insufficient budget, or are not supported by local capabilities. For the remaining feature groups, the terminal can calculate the expected differentiation benefit based on a preset benefit table, or obtain an estimated benefit from the number of excluding causes for the current candidate fault cause set in the stage-conditional exclusion rule matrix for that feature group. The selection objective is to minimize the number of feature groups whose candidate cause set reaches a preset discriminative degree after actual feature value shrinkage, while satisfying the privacy budget and resource budget, or to minimize the weighted sum of privacy cost and resource cost.

[0083] The technical solution provided in this embodiment determines the candidate data items through multi-dimensional conditions and filters them by combining cost information and budget information. This helps to select the most suitable diagnostic features while ensuring data compliance and resource controllability, thereby helping to balance fault distinguishability and terminal resource consumption.

[0084] In an exemplary embodiment, the resource budget information includes privacy budget information and computational resource budget information; based on the privacy cost information, resource cost information, authorization status information, and resource budget information, the target vehicle fault diagnosis data item is selected from the candidate vehicle fault diagnosis data items, including: removing at least one of the following from the candidate vehicle fault diagnosis data items: vehicle fault diagnosis data items whose authorization status information indicates unauthorized status, vehicle fault diagnosis data items whose privacy cost information exceeds the privacy budget information, and vehicle fault diagnosis data items whose resource cost information exceeds the computational resource budget information, to obtain the target vehicle fault diagnosis data item.

[0085] Privacy budget information can be the maximum limit set for the privacy costs that can be exposed for a single diagnostic session, such as a weighted sum of sensitivity levels.

[0086] Among them, the computing resource budget information can be the maximum limit of terminal resources that can be consumed for a single diagnostic session, such as the upper limit of CPU computing power, the upper limit of cache bytes, or the upper limit of outgoing bytes.

[0087] Optionally, when filtering data items, the terminal traverses all candidate vehicle fault diagnosis data items. If it detects that the authorization status information of a candidate vehicle fault diagnosis data item is unauthorized, or its privacy cost information is greater than the privacy budget information, or its resource cost information is greater than the computing resource budget information, the vehicle fault diagnosis data item is removed from the candidate vehicle fault diagnosis data items to obtain the target vehicle fault diagnosis data item.

[0088] For example, the terminal maintains a privacy budget, a resource budget, and a supplementary round budget for each diagnostic session. The privacy budget can be represented as a weighted average of the sensitivity levels of a feature group and its upper limit; the resource budget can be represented as one or more upper limits among allowed sampling duration, CPU computation, cached bytes, and outgoing bytes; the supplementary round budget limits the number of additional samples triggered by cloud policies. The budget is initialized at the start of the session and deducted in real time after selection, sampling, transformation, or uploading. To prevent policies from bypassing privacy restrictions through abstract scores, the policy verification module first performs authorization verification and budget verification, and then performs benefit ranking; even if a feature group has the highest preset benefit, it cannot be selected if its sampling window exceeds the limit, its privacy level exceeds the remaining session quota, or it needs to read prohibited fields.

[0089] The technical solution provided in this embodiment helps prevent diagnostic strategies from bypassing privacy restrictions or excessively consuming terminal performance, thereby facilitating the minimization of sensitive data exposure and effective control of terminal resources.

[0090] In an exemplary embodiment, actual observation data of the target vehicle fault diagnosis data item is obtained, and the initial candidate fault cause set is filtered based on the actual observation data to obtain the target candidate fault cause set. This includes: obtaining actual observation data within a preset sampling window corresponding to the target vehicle fault diagnosis data item; and removing conflicting candidate fault causes from the initial candidate fault cause set based on a preset exclusion information matrix and the actual observation data to obtain the target candidate fault cause set.

[0091] The preset sampling window can be a data collection period that is pre-registered for each data feature group and is limited by the maximum time span, such as the duration of the most recent heartbeat cycle.

[0092] The preset exclusion information matrix can be a pre-configured data table or rule matrix that records verifiable conditional relationships that are sufficient to exclude candidate causes when a certain actual feature value is taken during the abnormal phase.

[0093] Optionally, after determining the target vehicle fault diagnosis data item, the terminal starts a preset sampling window corresponding to the target vehicle fault diagnosis data item and acquires the actual observation data within the preset sampling window; it calls a preset exclusion information matrix, substitutes the collected actual observation data into the exclusion information matrix for matching, determines the candidate fault causes that logically conflict with the actual observation data, and removes the conflicting candidate fault causes from the initial candidate fault cause set, thereby obtaining a target candidate fault cause set with a further narrowed scope.

[0094] For example, optional low-sensitivity (e.g., sensitivity level less than a preset sensitivity threshold) feature groups include Recent Heartbeat Summary, MqttStageDuration, NetworkContext, and VehicleStateSummary. Low sensitivity means that this feature group, after controlled transformation, does not contain the original terminal identifier, precise location, complete message, or mapping data that can recover the original values. For example, the RecentHeartbeatSummary feature group is suitable for vehicle receipt timeout scenarios. Its sampling window is the most recent heartbeat cycle, and it only outputs state enumerations such as HEALTHY, STALE, and UNKNOWN. The MqttStageDuration feature group outputs delay buckets for adjacent stages such as client sending, server receiving, downlink delivery, and vehicle receipt. The VehicleStateSummary feature group only outputs enumeration values ​​of the target vehicle condition "changed, unchanged, unknown" within the verification window. The RssiStatistics (Received Signal Strength Indication Statistics) feature group only outputs the mean, variance, trend buckets, and abnormal disconnection count buckets within a limited window.

[0095] The phase-based conditional exclusion rule matrix records at least the relationship between "abnormal phase - candidate cause - feature group - feature value - excludeable cause - retained cause". This matrix does not merely record the correlation or statistical weight of "fault mode × diagnostic test", but rather verifiable conditional relationships that allow a specific actual feature value to exclude or retain candidate causes under a particular abnormal phase. After obtaining the actual feature value, the terminal uses these relationships to shrink the candidate set. For example, with VEHICLE_ACK_TIMEOUT (vehicle acknowledgment timeout): when RecentHeartbeatSummary is STALE, the rule matrix can exclude "session continuously healthy with only momentary downlink jitter", retaining "downlink abnormality, vehicle offline or hibernating, vehicle not executed"; when RecentHeartbeatSummary is HEALTHY, it can exclude "vehicle offline or hibernating"; when the server's reception phase is normal and the downlink latency bucket is OVER_10S (exceeding 10 seconds), it can further exclude reasons such as client failure to send or vehicle execution, retaining "downlink network abnormality, vehicle offline or hibernating". In another example, when VehicleStateSummary is "Target state has changed," the rule matrix directly excludes "Vehicle not executed." If it is "Target state has not changed" and the heartbeat state is HEALTHY, then "Vehicle offline or asleep" and "Vehicle status feedback delay" can be excluded, while session anomalies, downlink anomalies, or vehicle not executed can be retained. Selecting features solely based on abstract information gain may be disconnected from actual diagnostic capabilities. For example, a certain heartbeat feature group may have a high uncertainty elimination capability in an information theory sense, but in the current abnormal stage where the vehicle is in an area without network coverage, its actual value may remain UNKNOWN, failing to exclude any candidate fault causes. This application verifies the discriminative power using the rule matrix shrinkage results triggered by actual values.

[0096] The technical solution provided in this embodiment, by acquiring actual observation data within a preset sampling window and using a preset exclusion information matrix for verification and narrowing, helps to avoid blindly collecting data over a large area and making subjective inferences, thereby improving the accuracy of fault location.

[0097] In an exemplary embodiment, generating vehicle fault diagnosis data based on actual observation data and a target candidate fault cause set includes: performing desensitization transformation on the actual observation data to obtain a target diagnosis feature vector corresponding to the actual observation data; and generating fault diagnosis data based on the target diagnosis feature vector, target stage events, and target candidate fault cause set.

[0098] Among them, desensitization and transformation processing can be the process of converting the original field containing sensitive information into a secure data format that does not contain the original sensitive field and cannot be restored to the original value, such as bucketing, enumeration or error family mapping processing.

[0099] The target diagnostic feature vector can be a structured data vector consisting of state enumeration, relative delay buckets, statistical buckets, or error families, which is output after desensitization and transformation.

[0100] Optionally, after collecting the actual observation data, the terminal performs desensitization and transformation processing on the actual observation data, transforming the actual observation data into a safe and irreversible target diagnostic feature vector; the generated target diagnostic feature vector is combined with the identification information of the currently recorded target stage event and the identification information of the target candidate fault cause set obtained after screening, and assembled together to generate vehicle fault diagnosis data for external distribution.

[0101] For example, the controlled feature conversion module of the terminal converts the selected raw observations into diagnostic vectors on the terminal side. For raw values ​​of time delay, the module calculates and maps them to time delay buckets such as UNDER_1S (less than 1 second), ONE_TO_3S (1 to 3 seconds), THREE_TO_10S (3 to 10 seconds), and OVER_10S based on the relative difference between adjacent stages; for signal strength sequences, the module calculates the mean, variance, trend, and count buckets only within a limited window; for network error text and protocol error codes, the module maps them to error families such as NETWORK, AUTH, TIMEOUT, SESSION, and STATE.

[0102] The diagnostic package uses a fixed whitelist schema, which may include schemaVersion, short-lifetime diagnosticSessionId, instruction category, protocol category, abnormal phase, in-session phase summary, candidate cause set identifier, feature group identifier, controlled transformation rule identifier, policy version, used budget summary, supplementary rounds, diagnostic feature vector, and integrity verification fields. The field whitelist validator performs verification once before queuing and once before sending; if it discovers original sensitive fields, fields outside the policy, mapping data with recoverable original values, or cross-session stable identifiers, it directly refuses to generate or send the diagnostic package. Fields prohibited from entering the diagnostic package include at least the VIN, Vehicle ID (Identity), account number, phone number, precise location, control token, original values ​​of control parameters, complete MQTT (Message Queuing Telemetry Transport) or HTTP (Hypertext Transfer Protocol) message, Bluetooth MAC / UUID (Universally Unique Identifier), peripheral name, complete RSSI (Received Signal Strength Indicator) sequence, millisecond-level precise timestamp, and a dictionary or mapping table for restoring the aforementioned original values. If there is a short-term retention requirement on the device side, the original fragment is encrypted and stored using a session domain key, and deleted according to the first-come-first-served condition when the diagnostic package is successfully enqueued, reaches the minimum retention period, or the user withdraws authorization. The reporting module can reuse offline caching, retry, and batch upload capabilities, but the cached objects are only diagnostic packages that have passed the whitelist verification.

[0103] The technical solution provided in this embodiment, by performing desensitization and transformation processing on actual observation data and generating diagnostic data, helps to protect user privacy and security to the greatest extent while ensuring the diagnostic needs of the server.

[0104] In an exemplary embodiment, after sending the fault diagnosis data to the vehicle fault diagnosis server, the method further includes: receiving a data supplementation request issued by the vehicle fault diagnosis server for the fault diagnosis data; performing verification processing on the data supplementation request to obtain a verification result of the data supplementation request; if the verification result indicates that the verification is successful, determining supplementary vehicle fault diagnosis data items from the candidate vehicle fault diagnosis data items based on the data supplementation request and the vehicle's current remaining resource budget information; obtaining supplementary observation data for the supplementary vehicle fault diagnosis data items; filtering the target candidate fault cause set based on the supplementary observation data to obtain a filtered candidate fault cause set; generating supplementary vehicle fault diagnosis data based on the supplementary observation data and the filtered candidate fault cause set; and sending the supplementary fault diagnosis data to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle again based on the supplementary fault diagnosis data.

[0105] Among them, the data supplementation request can be a strategy instruction issued by the server to the terminal to request additional feature data when the attribution confidence of the first round of fault diagnosis data is less than a preset confidence threshold.

[0106] The verification result can be a conclusion reached by the terminal after comprehensively verifying the compliance, timeliness, and budget adequacy of the data supplementation request, and whether it is approved or rejected.

[0107] Among them, the supplementary vehicle fault diagnosis data items can be feature data groups selected from the intersection of the whitelist requested by the server and the local pre-registration after the terminal passes the verification, which are used to further investigate the fault.

[0108] Among them, the supplementary observation data can be the actual value data collected within a limited window for the supplementary vehicle fault diagnosis data item.

[0109] Among them, the supplementary fault diagnosis data can be a second-round diagnostic feature package generated based on the supplementary observation data, used to support the server in performing secondary attribution analysis.

[0110] Optionally, after the terminal sends the initial fault diagnosis data to the vehicle fault diagnosis server, if the server determines that the evidence is insufficient, the terminal will receive a data supplementation request from the server. This data supplementation request will undergo multi-dimensional verification to obtain a verification result. When the verification result indicates that the verification is successful, the terminal will select a suitable supplementary vehicle fault diagnosis data item from the candidate vehicle fault diagnosis data items, based on the content of the data supplementation request and the vehicle's current remaining resource budget information. Supplementary observation data corresponding to the supplementary vehicle fault diagnosis data item will be obtained, and this supplementary observation data will be used to further filter the existing target candidate fault cause set, resulting in a further narrowed set of candidate fault causes. Based on the supplementary observation data and the filtered set of candidate fault causes, supplementary fault diagnosis data will be generated and sent to the vehicle fault diagnosis server so that the vehicle fault diagnosis server can perform further fault diagnosis processing on the vehicle based on the supplementary fault diagnosis data.

[0111] For example, Figure 3 The diagram illustrates the limited incremental supplementation process under low confidence, including: the server outputs the first round of attribution results and confidence, verifies the confidence, remaining budget, authorization and policy validity, selects supplementary feature groups only from the pre-registered whitelist, samples with a limited window on the client side and shrinks the candidate cause set again, outputs the final attribution, and rejects requests for complete logs and prohibited fields.

[0112] Figure 4 This diagram illustrates the functional module relationships of the edge-side diagnostic data generation device, including: session construction module, state machine module, candidate cause module, strategy and budget module, minimum feature selection module, supplementary strategy verification module, controlled transformation module, diagnostic package verification module, cache reporting module, and server-side attribution and limited supplementary strategy; this device can be deployed in the terminal.

[0113] For example, after receiving the first round of diagnostic packages, the cloud can output the ranking and confidence of candidate causes based on rule-based reasoning, decision trees, probabilistic graphical models, or other attribution models. The cloud model is only used for attribution confidence calculation and does not participate in rewriting the end-side anomaly stage and candidate cause range. The cloud must not directly request raw logs or arbitrary fields; its issued supplementary policies must include at least a policy identifier, target anomaly stage, whitelist of allowed feature groups, controlled transformation rule identifier for each group, maximum rounds, maximum sampling window for each group, budget limit, validity period, signature, and policy version. Each feature group in the whitelist has a pre-defined maximum sampling window; the cloud can only request the diagnostic vectors within this window after controlled transformation and cannot request continuous raw data outside this window. After receiving the supplementary policy, the terminal sequentially verifies the policy signature, policy version compatibility, validity period, target session consistency, authorization status, remaining privacy and resource budget, used supplementary rounds, and feature group whitelist. If any condition is not met, the terminal will not sample or return supplementary fields, and may only report a limited list of reasons for rejection, such as POLICY_EXPIRED (policy expired), BUDGET_EXHAUSTED (budget exhausted), CONSENT_DENIED (authorization denied), or GROUP_NOT_ALLOWLISTED (feature group not in the whitelist). When all conditions are met, the minimum feature selection module selects one or more feature groups that can continue to shrink the current candidate fault cause set from the intersection of the feature groups applicable to the current anomaly stage, the locally pre-registered feature groups, and the policy whitelist feature groups, and performs sampling according to the corresponding registered conversion rules and the maximum sampling window. After obtaining the actual values, the terminal performs stage-conditional exclusion rule matrix shrinking and generates a second diagnostic package marked as a supplementary round. The terminal stops supplementation when the maximum round is reached, the preset discrimination is reached, the budget is exhausted, or the session validity period expires.

[0114] The technical solution provided in this embodiment is beneficial for obtaining incremental information on demand when the confidence level of the first round of diagnosis is insufficient, thereby improving the success rate of diagnosing complex faults without violating privacy constraints and resource limitations.

[0115] In an exemplary embodiment, determining the target stage event that has an operational anomaly from multiple stage events based on the sequential dependencies between multiple stage events includes: performing state verification processing on multiple stage events to obtain the state verification results of each stage event; determining the abnormal stage event that has an operational anomaly from multiple stage events based on the state verification results of each stage event; and determining the abnormal stage event that ranks first from the abnormal stage events based on the sequential dependencies, as the target stage event.

[0116] The status verification result can be a conclusion drawn by the terminal after judging the execution status of each stage event, such as whether it was successful, whether it timed out, or whether the status is contradictory.

[0117] Among them, abnormal stage events can be business node events that have not met the normal completion conditions, which are filtered out based on the status verification results.

[0118] Among them, the first abnormal stage event in the ranking can be the abnormal stage event that first causes the subsequent stages to be unable to continue in the order of occurrence or the order of business logic flow.

[0119] Optionally, after recording multiple stage events, the terminal performs status verification processing on each stage event to determine whether they have been completed normally, thereby obtaining the status verification results of each stage event. Based on the status verification results, events that fail to execute or time out are selected and identified as abnormal stage events that have caused operational anomalies. Based on the preset sequential dependencies between various stage events, the abnormal stage event that ranks first in logical order is selected from all the identified abnormal stage events as the target stage event.

[0120] For example, the terminal's state machine determines the abnormal stage based on the sequential dependencies between stages. For instance, an abnormal stage is denoted as CONNECT_FAIL when connection establishment fails; AUTH_FAIL when authentication is incomplete; VEHICLE_ACK_TIMEOUT when the server confirms receipt but the vehicle receipt is overdue; and STATE_VERIFY_MISMATCH when the vehicle receipt is normal but the vehicle status in the verification window remains unchanged. If multiple abnormalities coexist, the terminal prioritizes the first abnormal stage that prevents the session from proceeding to the next stage, while retaining subsequent abnormalities to supplement the session's context. Determining the abnormal stage through the state machine ensures that the generation of candidate fault causes has definite, interpretable, and auditable technical boundaries. The abnormal stage and the range of candidate causes are defined by the semantics of the stage events and pre-defined mappings, rather than by training samples, model weights, or probability distributions. The cloud can use rule-based reasoning or other attribution models to output confidence levels, but it must not change the abnormal stage, the range of candidate causes, and the field reading boundaries already determined on the terminal side. Taking VEHICLE_ACK_TIMEOUT as an example, candidate reasons can include session anomalies, downlink network anomalies, vehicle offline or hibernation, vehicle not executing, and vehicle condition verification not being covered. For AUTH_FAIL, candidate reasons can include invalid authentication materials, challenge response mismatch, connection interruption, and inconsistent clock windows. Different anomaly stages correspond to different feature whitelists, rather than collecting a uniform field for all sessions.

[0121] The technical solution provided in this embodiment, by performing status verification on multiple stage events and selecting the abnormal event that ranks first according to the sequential dependency relationship, is conducive to accurately determining the fundamental blockage point that causes the failure of the entire control link, thereby improving the efficiency and accuracy of subsequent vehicle fault diagnosis.

[0122] The following example illustrates the vehicle fault diagnosis method provided in this application. This example demonstrates the application of this method to a terminal, and the main steps include:

[0123] Step S1: Associate vehicle control session. The terminal associates events such as command sending, connection, authentication, server reception, vehicle feedback, and vehicle condition verification to the same short lifecycle diagnostic session.

[0124] Step S2: Identify the abnormal stage. The terminal determines the first stage that meets any of the following conditions according to the sequence of the vehicle control state machine stages: failure, timeout, state contradiction, or failure to meet the completion conditions.

[0125] Step S3: Form a candidate fault cause set. The terminal forms a set of candidate fault causes that have not yet been distinguished based on the preset "abnormal stage-candidate cause" mapping, abnormal stage, protocol category and low-sensitivity context; the candidate fault cause set is not replaced by the fault probability distribution output by the training model.

[0126] Step S4: Select the minimum feature set. The terminal reads the differentiation benefits, privacy costs, resource costs, and authorization status from the intersection of feature sets that simultaneously meet the criteria of being applicable to the current anomaly stage, related to the current candidate fault cause set, locally pre-registered, and permitted by the activity policy whitelist. It excludes prohibited, unauthorized, or over-budget feature sets and selects the minimum feature set within the budget that allows the candidate cause set to achieve a preset differentiation level. The selection is based on the actual feature values ​​being able to shrink the set, rather than solely on abstract information gain or general cost optimization.

[0127] Step S5: Limited window sampling and candidate set shrinking. The terminal obtains the actual feature values ​​only for the selected feature group within a preset limited sampling window, and deletes the candidate fault causes excluded by the actual values ​​according to the stage-conditional exclusion rule matrix. The limited sampling window is limited by the maximum sampling window of the corresponding feature group; any supplementary feature group can only be selected from the intersection of feature groups applicable to the current anomaly stage, pre-registered locally, and permitted by the activity strategy.

[0128] Step S6: Controlled Transformation and Restricted Supplementation. The terminal converts the original fields into diagnostic vectors mapped by bucketing, enumeration, statistics, or error families, and then uploads them. These diagnostic vectors do not contain the original sensitive fields, mapping data whose original values ​​can be recovered, or cross-session stable identifiers. When cloud confidence is insufficient, the next round of supplementation will only be executed according to the registered maximum sampling window and transformation rules if the remaining budget is sufficient, authorization is permitted, policy signature and validity period verification pass, and the supplementary feature group falls within the intersection of the current anomaly phase's applicability, local pre-registration, and policy whitelist.

[0129] In this application, the diagnostic scope is narrowed by the abnormal stage of the vehicle control state machine, and the candidate fault causes are verifiablely narrowed down by actual feature values. A closed loop combining minimum feature selection, edge-controlled transitions, and restricted supplementation under low confidence is also incorporated. This closed loop is not a parallel combination of vehicle control diagnosis and privacy processing. The closed loop proceeds as follows: a pre-defined state machine transition relationship determines the abnormal stage; a pre-defined "abnormal stage-candidate cause" mapping forms a candidate cause set; the candidate cause set and the abnormal stage together limit the intersection of selectable feature groups; the actual feature values ​​within the finite window trigger the shrinking of the stage-conditional exclusion rule matrix; the shrinking result is used to determine whether a preset discrimination level has been reached; only when the preset discrimination level has not been reached and budget, authorization, and signature policy constraints are met, restricted supplementation is performed from the intersection and the shrinking is repeated. There are clear data dependencies between the abnormal stage, candidate causes, feature groups, actual values, and restricted supplementation; the absence of any link will degrade the solution to fixed-point embedding, static desensitization, model dimensionality reduction and uploading, or full data collection.

[0130] This application, while achieving the same candidate fault cause set shrinkage rate or attribution accuracy, can reduce the number of bytes sent out, sampling window, and storage volume on both the client and server sides, and reduce the exposure of sensitive raw fields. Compared to schemes that upload complete stage logs at fixed time windows, this application only sends out diagnostic vectors composed of status enumeration, relative delay buckets, statistical buckets, and error families, without sending out complete messages, raw control parameters, and time series; in a typical session, the former is usually in the tens of bytes range, while the latter can be in the thousands of bytes range. Compared to end-cloud model schemes based on encoder-based dimensionality reduction uploads, this application does not rely on black-box dimensionality reduction models; the sampling range, transformation rules, and output semantics of each feature group are auditable, and the cloud cannot request arbitrary data exceeding the pre-registered range through policy requests; compared to schemes that only anonymize existing logs, this application excludes outgoing paths for VINs, accounts, precise locations, raw messages, and cross-session stable identifiers before data is sent out through field whitelists and controlled transformations.

[0131] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0132] Based on the same inventive concept, this application also provides a vehicle fault diagnosis device for implementing the vehicle fault diagnosis method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more vehicle fault diagnosis device embodiments provided below can be found in the limitations of the vehicle fault diagnosis method described above, and will not be repeated here.

[0133] In one exemplary embodiment, such as Figure 5 As shown, a vehicle fault diagnosis device 500 is provided, which may include:

[0134] The event determination module 501 is used to acquire multiple stage events corresponding to the vehicle's control commands, and determine the target stage event where the operation abnormality occurs from the multiple stage events based on the sequential dependency relationship between the multiple stage events.

[0135] The set determination module 502 is used to determine the initial set of candidate fault causes corresponding to the target stage event;

[0136] The data filtering module 503 is used to filter out the target vehicle fault diagnosis data items from the preset candidate vehicle fault diagnosis data items based on the initial candidate fault cause set and the preset resource budget information.

[0137] The set filtering module 504 is used to obtain the actual observation data of the target vehicle fault diagnosis data items, and to filter the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set;

[0138] The data sending module 505 is used to generate vehicle fault diagnosis data based on actual observation data and the target candidate fault cause set, and send the fault diagnosis data to the vehicle fault diagnosis server so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

[0139] In an exemplary embodiment, the data filtering module 503 is further configured to determine, from the candidate vehicle fault diagnosis data items, those associated with the target stage event, associated with the initial candidate fault cause set, and in the preset list allowable state; obtain the privacy cost information, resource cost information, and authorization status information of the candidate vehicle fault diagnosis data items; and filter out the target vehicle fault diagnosis data items from the candidate vehicle fault diagnosis data items based on the privacy cost information, resource cost information, authorization status information, and resource budget information.

[0140] In an exemplary embodiment, the resource budget information includes privacy budget information and computing resource budget information; the data filtering module 503 is further configured to remove at least one of the following from the candidate vehicle fault diagnosis data items: vehicle fault diagnosis data items whose authorization status information indicates unauthorized status, vehicle fault diagnosis data items whose privacy cost information exceeds the privacy budget information, and vehicle fault diagnosis data items whose resource cost information exceeds the computing resource budget information, in order to obtain the target vehicle fault diagnosis data items.

[0141] In an exemplary embodiment, the set filtering module 504 is further configured to acquire actual observation data within a preset sampling window corresponding to the target vehicle fault diagnosis data item; and, based on the preset exclusion information matrix and the actual observation data, remove conflicting candidate fault causes from the initial candidate fault cause set to obtain the target candidate fault cause set.

[0142] In an exemplary embodiment, the data sending module 505 is further configured to perform desensitization and transformation processing on the actual observation data to obtain the target diagnostic feature vector corresponding to the actual observation data; and generate fault diagnosis data based on the target diagnostic feature vector, the target stage event, and the target candidate fault cause set.

[0143] In an exemplary embodiment, the device 500 further includes: a request receiving module, configured to receive a data supplementation request issued by a vehicle fault diagnosis server for fault diagnosis data; perform verification processing on the data supplementation request to obtain a verification result of the data supplementation request; if the verification result indicates that the verification is successful, determine supplementary vehicle fault diagnosis data items from candidate vehicle fault diagnosis data items based on the data supplementation request and the vehicle's current remaining resource budget information; obtain supplementary observation data for the supplementary vehicle fault diagnosis data items; perform filtering processing on the target candidate fault cause set based on the supplementary observation data to obtain a filtered candidate fault cause set; generate supplementary vehicle fault diagnosis data based on the supplementary observation data and the filtered candidate fault cause set; and send the supplementary fault diagnosis data to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server performs fault diagnosis processing on the vehicle again based on the supplementary fault diagnosis data.

[0144] In an exemplary embodiment, the event determination module 501 is further configured to perform state verification processing on multiple stage events to obtain the state verification results of each stage event; based on the state verification results of each stage event, determine the abnormal stage event that has run abnormally from the multiple stage events; and based on the sequential dependency relationship, determine the abnormal stage event that ranks first from the abnormal stage events as the target stage event.

[0145] Each module in the aforementioned vehicle fault diagnosis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0146] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a vehicle fault diagnosis method. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0147] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0148] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0149] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0150] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0151] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0152] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0153] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A vehicle fault diagnosis method, characterized in that, The method includes: The system acquires multiple stage events corresponding to the vehicle's control commands, and determines the target stage event where the operational anomaly occurs based on the sequential dependencies between these multiple stage events. Determine the initial set of candidate fault causes corresponding to the target stage event; Based on the initial candidate fault cause set and the preset resource budget information, the target vehicle fault diagnosis data item is selected from the preset candidate vehicle fault diagnosis data items. Obtain actual observation data of the target vehicle fault diagnosis data item, and filter the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set; Based on the actual observation data and the target candidate fault cause set, fault diagnosis data for the vehicle is generated, and the fault diagnosis data is sent to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

2. The method according to claim 1, characterized in that, The step of selecting target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items based on the initial candidate fault cause set and preset resource budget information includes: From the candidate vehicle fault diagnosis data items, determine the candidate vehicle fault diagnosis data items that are associated with the target stage event, associated with the initial candidate fault cause set, and are in the preset list allowable state; Obtain the privacy cost information, resource cost information, and authorization status information of the candidate vehicle fault diagnosis data items; Based on the privacy cost information, the resource cost information, the authorization status information, and the resource budget information, the target vehicle fault diagnosis data item is selected from the candidate vehicle fault diagnosis data items.

3. The method according to claim 2, characterized in that, The resource budget information includes privacy budget information and computing resource budget information; The step of selecting the target vehicle fault diagnosis data item from the candidate vehicle fault diagnosis data items based on the privacy cost information, the resource cost information, the authorization status information, and the resource budget information includes: From the candidate vehicle fault diagnosis data items, at least one of the following is removed: vehicle fault diagnosis data items whose authorization status information indicates unauthorized vehicle fault diagnosis data items, vehicle fault diagnosis data items whose privacy cost information exceeds the privacy budget information, and vehicle fault diagnosis data items whose resource cost information exceeds the computing resource budget information, to obtain the target vehicle fault diagnosis data item.

4. The method according to claim 1, characterized in that, The actual observation data of the target vehicle fault diagnosis data item is obtained, and the initial candidate fault cause set is filtered based on the actual observation data to obtain the target candidate fault cause set, including: The actual observation data is acquired within the preset sampling window corresponding to the target vehicle fault diagnosis data item; Based on the preset exclusion information matrix and the actual observation data, conflicting candidate fault causes are removed from the initial candidate fault cause set to obtain the target candidate fault cause set.

5. The method according to claim 1, characterized in that, The step of generating fault diagnosis data for the vehicle based on the actual observation data and the target candidate fault cause set includes: The actual observation data is subjected to desensitization and transformation processing to obtain the target diagnostic feature vector corresponding to the actual observation data; The fault diagnosis data is generated based on the target diagnostic feature vector, the target stage event, and the target candidate fault cause set.

6. The method according to claim 1, characterized in that, After sending the fault diagnosis data to the vehicle fault diagnosis server, the process also includes: Receive data supplementation requests from the vehicle fault diagnosis server in response to the fault diagnosis data; The data supplementation request is validated to obtain the validation result of the data supplementation request; If the verification result indicates that the verification is successful, supplementary vehicle fault diagnosis data items are determined from the candidate vehicle fault diagnosis data items based on the data supplementation request and the current remaining resource budget information of the vehicle. Obtain supplementary observation data for the supplementary vehicle fault diagnosis data item, and filter the target candidate fault cause set based on the supplementary observation data to obtain the filtered candidate fault cause set. Based on the supplementary observation data and the filtered set of candidate fault causes, supplementary fault diagnosis data for the vehicle is generated, and the supplementary fault diagnosis data is sent to the vehicle fault diagnosis server, so that the vehicle fault diagnosis server can perform a second fault diagnosis on the vehicle based on the supplementary fault diagnosis data.

7. The method according to any one of claims 1 to 6, characterized in that, The process of determining the target stage event where the operational anomaly occurs from among the multiple stage events based on their sequential dependencies includes: Perform state verification processing on the multiple stage events to obtain the state verification result of each stage event; Based on the status verification results of each stage event, determine the abnormal stage event that caused the operational abnormality from the multiple stage events; Based on the aforementioned sequential dependency relationship, the abnormal stage event that ranks first among the abnormal stage events is determined as the target stage event.

8. A vehicle fault diagnosis device, characterized in that, The device includes: The event determination module is used to acquire multiple stage events corresponding to the vehicle's control commands, and based on the sequential dependencies between the multiple stage events, determine the target stage event in which the operation abnormality occurs from the multiple stage events; The set determination module is used to determine the initial set of candidate fault causes corresponding to the target stage event; The data filtering module is used to filter out target vehicle fault diagnosis data items from preset candidate vehicle fault diagnosis data items based on the initial candidate fault cause set and preset resource budget information. The set filtering module is used to obtain the actual observation data of the target vehicle fault diagnosis data item, and to filter the initial candidate fault cause set based on the actual observation data to obtain the target candidate fault cause set. The data sending module is used to generate fault diagnosis data for the vehicle based on the actual observation data and the target candidate fault cause set, and send the fault diagnosis data to the vehicle fault diagnosis server so that the vehicle fault diagnosis server can perform fault diagnosis processing on the vehicle based on the fault diagnosis data.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images