Vehicle control software function failure analysis method and related equipment

Abstract

The invention discloses a vehicle control software function failure analysis method and related equipment, and relates to the technical field of Internet of Vehicles, and the method comprises the steps: obtaining operation log data corresponding to a target function failure event; based on a preset mapping model, determining a target signal identifier and a fault judgment rule associated with the target function failure event; according to the target signal identifier, extracting a signal sequence in a preset time window from the running log data; performing multi-stage verification on the signal sequence to obtain a signal verification result; and determining the fault type of the target function failure event based on the fault judgment rule and the signal verification result. According to the method, the mapping model is constructed, the signal sequence is extracted through the dynamic time window, hierarchical diagnosis is performed in combination with a progressive multi-stage verification mechanism, faults of an application layer, a communication layer and a hardware layer are accurately positioned, and the vehicle control function failure diagnosis efficiency and accuracy are improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking technology, and in particular to a method for analyzing vehicle control software function failure and related equipment. Background Art

[0002] With the rapid development of connected vehicle technology, the functional complexity of onboard systems is increasing. However, the diagnosis of functional failures in vehicle control systems still relies on traditional manual log analysis. This requires engineers to rely on their experience to individually review massive log files, which is inefficient and prone to missing critical information. Furthermore, the lack of a standardized fault classification system leads to vague definitions of fault types, making it difficult to systematically locate the root cause of the problem. Furthermore, the mapping relationship between onboard signals and functional modules has not been effectively established, and the correlation analysis between signal timing, parameters, and functional failures is insufficient, further reducing diagnostic accuracy. Therefore, a method for analyzing functional failures in vehicle control software is urgently needed to address the aforementioned technical issues. Summary of the Invention

[0003] The Summary of the Invention introduces a series of simplified concepts that will be further described in the Detailed Description of the Invention. The Summary of the Invention of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0004] In a first aspect, the present application provides a method for analyzing vehicle control software failure, comprising:

[0005] Obtain the operation log data corresponding to the target function failure event;

[0006] Determine the target signal identifier and fault judgment rule associated with the target function failure event based on the preset mapping model;

[0007] Extracting a signal sequence within a preset time window from the operation log data according to the target signal identifier;

[0008] Performing multi-level verification on the signal sequence to obtain a signal verification result;

[0009] Based on the fault judgment rules and signal verification results, the fault type of the target function failure event is determined.

[0010] In some embodiments, determining a target signal identifier and a fault determination rule associated with a target function failure event based on a preset mapping model includes:

[0011] Determine a target functional module that matches the functional description of the target functional failure event based on a mapping relationship between functional modules and signal identifiers in a preset mapping model;

[0012] Filtering a target signal identifier that is logically associated with a trigger of a target function failure event from a plurality of candidate signal identifiers corresponding to the target function module;

[0013] Based on the target signal identifier, a fault determination rule in a preset mapping model is determined.

[0014] In some embodiments, extracting a signal sequence within a preset time window from the operation log data according to the target signal identifier includes:

[0015] Based on the occurrence time of the target function failure event, a dynamic time offset is expanded to generate a preset time window, wherein the dynamic time offset is determined based on a preset delay threshold corresponding to the target signal identifier;

[0016] Signal records with target signal identifiers within a preset time window are extracted from the operation log data and sorted by timestamp to generate a signal sequence.

[0017] In some embodiments, the multi-level verification includes a first-level verification, a second-level verification, and a third-level verification. The multi-level verification is performed on the signal sequence to obtain a signal verification result, including:

[0018] Performing a first-level verification on the signal sequence to determine whether there is at least one record of the target signal identifier being issued in the signal sequence;

[0019] If there is a delivery record, perform the second level verification, calculate the time interval between the timestamp of the delivery record and the timestamp of the reporting record corresponding to the target signal identifier, and determine whether the time interval is less than or equal to the preset delay threshold;

[0020] If the time interval is less than or equal to the preset delay threshold, the third level verification is performed to analyze whether the sending parameters in the sending record are consistent with the reporting parameters in the reporting record;

[0021] A signal verification result is generated according to the verification results of the first level verification, the second level verification, and the third level verification, wherein the signal verification result includes at least one of a signal existence status, a timing compliance status, and a parameter matching status.

[0022] In some embodiments, determining the fault type of the target functional failure event based on the fault determination rule and the signal verification result includes:

[0023] Match the fault trigger conditions defined in the fault judgment rules based on the signal existence status, timing compliance status, and parameter matching status in the signal verification results;

[0024] If the signal existence status is missing, the fault type is determined to be failure to send application layer instructions;

[0025] If the signal existence status is present and the timing compliance status is greater than the preset delay threshold, the fault type is determined to be a communication link abnormality;

[0026] If the signal existence status is present, the timing compliance status is less than or equal to the preset delay threshold, and the parameter matching status is inconsistent, the fault type is determined to be a hardware actuator fault.

[0027] In some embodiments, further comprising:

[0028] In the case where a target failure event is associated with multiple target signal identifiers,

[0029] Determine the signal interaction logic between multiple target signal identifiers based on the dependency relationship of the functional modules in the preset mapping model;

[0030] Perform joint analysis on the signal verification results of multiple target signal identifiers according to the signal interaction logic to generate a joint analysis result;

[0031] Based on the joint analysis results, the fault type is determined.

[0032] In some embodiments, further comprising:

[0033] Obtain diagnostic records of historical functional failure events and extract fault verification logic, signal verification results, and fault types from the diagnostic records;

[0034] Based on the association rule mining algorithm, the mapping rules between fault verification logic and fault types are analyzed;

[0035] When the confidence of the mapping rule is greater than a preset confidence threshold, the mapping rule is stored in the fault knowledge base to optimize the fault judgment rule in the preset mapping model.

[0036] In a second aspect, the present application proposes a device for analyzing vehicle control software failure, comprising:

[0037] An operation data acquisition unit, used to acquire operation log data corresponding to a target function failure event;

[0038] a target signal determination unit, which determines a target signal identifier and a fault determination rule associated with a target function failure event based on a preset mapping model;

[0039] a signal sequence generating unit, configured to extract a signal sequence within a preset time window from the operation log data according to a target signal identifier;

[0040] A signal result verification unit, configured to perform multi-level verification on the signal sequence to obtain a signal verification result;

[0041] The fault type analysis unit determines the fault type of the target function failure event based on the fault judgment rules and the signal verification result.

[0042] In a third aspect, an electronic device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to implement the steps of the method for analyzing vehicle control software function failure of any one of the first aspects when executing the computer program stored in the memory.

[0043] In a fourth aspect, the present application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for analyzing the failure of the vehicle control software function of any one of the first aspects.

[0044] In summary, this application realizes the standardized construction and automated execution of fault diagnosis rules by establishing a multi-dimensional mapping model between functional modules, signal identifiers and fault types. Based on the target signal identifier, the signal sequence within a specific time window is dynamically extracted from the operation log, and combined with a hierarchical three-level verification mechanism, the signal existence check, timing compliance verification and parameter matching analysis are completed in sequence, so as to accurately identify the root causes of faults at different levels such as application layer instruction sending anomalies, communication link transmission failures or hardware actuator failures. By dynamically adjusting the time range of log retrieval according to the signal delay characteristics, redundant data processing is effectively avoided and the positioning efficiency is greatly improved. The hierarchical verification mechanism is used to gradually eliminate various potential fault factors to ensure the accurate correspondence between the diagnostic conclusion and the fault type, which solves the technical defects of low efficiency and high misjudgment rate of traditional manual analysis methods, and enhances the accuracy and execution efficiency of vehicle control software function failure diagnosis.

[0045] The analysis method for vehicle control software function failure proposed in this application, and other advantages, objectives and features of this application will be reflected in part through the following description, and in part will also be understood by technical personnel in this field through research and practice of this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present description. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0047] Figure 1 A flowchart of a method for analyzing vehicle control software failure provided in an embodiment of the present application;

[0048] Figure 2 A schematic diagram of the structure of a device for analyzing vehicle control software failure provided in an embodiment of the present application;

[0049] Figure 3 This is a structural diagram of an electronic device for analyzing vehicle control software function failure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or that are inherent to these processes, methods, products or devices. The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings 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.

[0051] See also Figure 1 , which is a flow chart of a method for analyzing vehicle control software function failure provided in an embodiment of the present application, which may specifically include:

[0052] S110, obtaining operation log data corresponding to the target function failure event;

[0053] For example, operation log data is the basic data source for diagnosing functional failures of vehicle control software. It contains key information such as signal identifiers, signal distribution records, signal reporting records, and timestamp information. The signal identifier uniquely identifies the interactive signal distribution record of the on-board functional module, which reflects the status of the command sent by the vehicle control software to the actuator. The reporting record records the actual response results of the actuator or sensor. The timestamp information accurately marks the time node of the signal interaction, providing a basis for timing analysis. These data are generated and stored in real time by the on-board system, covering the full-link interactive behavior of the software instruction layer, communication layer, and hardware execution layer.

[0054] The core purpose of acquiring operational log data is to provide the original analytical basis for subsequent fault location. By extracting log data before and after the target functional failure event, the system can capture the signal interaction sequence directly related to the fault, such as the issuance of user operation commands, ECU response status, and actuator feedback parameters. This ensures that the diagnostic process is based on authentic and complete signal records, avoiding misjudgments caused by missing or fragmented data, and laying the data foundation for subsequent signal screening, multi-level verification, and fault type determination.

[0055] S120, determining a target signal identifier and a fault determination rule associated with a target function failure event based on a preset mapping model;

[0056] Exemplarily, the preset mapping model is the core logical framework for the diagnosis of functional failures in vehicle control software. It forms a multi-dimensional mapping relationship by standardizing the associated functional modules, signal identifiers, and fault types. When the target functional failure event (such as "window lift failure") is input, the system first parses the functional description and matches it to the corresponding functional module in the preset mapping model (such as "window control module"), and then extracts the candidate signal identifier associated with the module (such as signal ID = 0x121). By analyzing the triggering logic of the failure event (such as no response to the user operating the "window lift button"), the system filters out the target signal identifiers directly related to the event to ensure that the diagnosis focuses on key signals.

[0057] After determining the target signal identifier, the system extracts the corresponding verification logic based on the predefined fault judgment rules in the preset mapping model (for example, switch rebound requires verification of the timing and parameters of signal transmission and reporting). For example, if the target signal identifier is bound to the "button does not respond" rule, the fault judgment rule only needs to check whether the signal transmission record exists. Through this hierarchical mapping mechanism, the system quickly converts the functional failure problems described by the user into low-level signal verification tasks, providing a clear rule basis for subsequent multi-level verification, avoiding reliance on manual experience and rule ambiguity.

[0058] S130, extracting a signal sequence within a preset time window from the operation log data according to the target signal identifier;

[0059] For example, through the dynamic time window mechanism, we focus on signal interaction data that is strongly associated with functional failure events. Based on the preset delay threshold (such as 300ms to 5000ms) of the target signal identifier, the system automatically expands the time range [T-δ, T+δ] to generate an adaptive retrieval window with the failure occurrence time T as the center. For example, for a signal with a delay requirement of 300ms, δ is set to 5 seconds to cover potential communication delays or hardware response abnormalities. The target signal's sending and reporting records within the window are accurately extracted from massive logs, and sorted by timestamp to form a continuous signal sequence, providing a timing analysis basis for subsequent verification.

[0060] S140, performing multi-level verification on the signal sequence to obtain a signal verification result;

[0061] Exemplarily, after the signal sequence is generated, the system performs progressive multi-level verification in sequence. First, it verifies whether the target signal identifier's issuance record exists. If so, it further verifies whether the timing of the issuance and reporting records meets the preset delay requirements. Finally, it compares the consistency of the issuance and reporting parameters. Through the layered verification mechanism, potential fault causes are gradually eliminated, and verification results are generated including signal existence, timing compliance, and parameter matching status. Through hierarchical verification, the scope of the fault is gradually narrowed, avoiding single-dimensional misjudgment, ensuring that the diagnostic conclusion strictly matches the signal characteristics, and providing a structured basis for the final fault type determination.

[0062] S150: Determine the fault type of the target function failure event based on the fault determination rule and the signal verification result.

[0063] Exemplarily, accurate classification of fault types is achieved through logical mapping of fault judgment rules and signal verification results. The system matches the signal verification results (including signal existence, timing compliance and parameter matching status) with the fault judgment rules defined in the preset mapping model to determine the fault type. For example, if the signal existence status is "missing", the "application layer instruction sending failure" rule is triggered; if the timing exceeds the limit and the parameters are consistent, the "communication link abnormality" rule is triggered. This matching process is achieved through logical conditional judgment to ensure the accurate correspondence between the fault type and the abnormal status of the underlying signal.

[0064] Fault type determination follows a hierarchical and progressive logic, first eliminating signal presence issues, then verifying timing compliance, and finally checking parameter consistency. For example, if the signal presence is normal but the timing exceeds the limit, it is directly determined to be a communication failure without further parameter verification. By hierarchically matching rules with verification results, the system quickly identifies the root cause of the fault and forms a clear diagnostic conclusion, providing a basis for subsequent remediation recommendations.

[0065] In summary, the embodiment of the present application realizes the standardized construction and automatic execution of diagnostic rules by constructing a multi-dimensional association model between functional modules, signal identifiers and fault types, thereby significantly improving the accuracy of fault location. By dynamically adjusting the time window range of log retrieval and adaptively matching retrieval parameters based on the delay characteristics of different signals, key signal records are fully captured, and the signal loss or invalid data redundancy problems caused by traditional fixed time windows are avoided. A progressive layered verification mechanism is adopted to perform signal existence verification, timing compliance verification and parameter matching analysis in sequence. The cause of the fault is quickly converged through a layer-by-layer elimination method, effectively solving the technical problem of high misjudgment rate in traditional methods. For complex fault scenarios involving multi-signal interactions, by parsing the dependency relationship between functional modules and signal interaction logic, a joint analysis of cross-signal verification results is achieved, and complex fault types such as system-level communication anomalies or collaborative control failures are accurately identified. On this basis, a self-learning mechanism based on historical diagnostic data is introduced to continuously explore the potential laws between signal verification features and fault types, dynamically optimize the fault judgment rule base, and enhance the system's adaptability to new fault modes. This technical solution significantly reduces reliance on manual experience by combining standardized diagnostic processes with intelligent analysis methods, providing efficient and accurate diagnostic support for vehicle control software failure issues, and effectively improving the reliability and maintenance efficiency of vehicle intelligent operation and maintenance.

[0066] In some examples, determining a target signal identifier and a fault determination rule associated with a target functional failure event based on a preset mapping model includes:

[0067] Determine a target functional module that matches the functional description of the target functional failure event based on a mapping relationship between functional modules and signal identifiers in a preset mapping model;

[0068] Filtering a target signal identifier that is logically associated with a trigger of a target function failure event from a plurality of candidate signal identifiers corresponding to the target function module;

[0069] Based on the target signal identifier, a fault determination rule in a preset mapping model is determined.

[0070] Exemplarily, the preset mapping model predefines the mapping relationship between vehicle control software functional modules and signal identifiers, and each functional module corresponds to a set of signal identifiers that implement its core functions. When the target functional failure event is input, the system parses the functional description provided by the user (such as "window lift failure" or "steering wheel heating button unresponsive") and semantically matches it with the functional modules in the mapping model. For example, the user inputs "window lift failure", and the system matches the preset functional module name (such as "window control module") through keyword extraction to determine that the target functional module is "window control module". This process is implemented through natural language processing technology or predefined functional tags to ensure that functional failure events are accurately associated with the underlying functional modules.

[0071] After the target functional module is determined, the system extracts the candidate signal identifiers corresponding to the module from the mapping model. For example, the "window control module" may be associated with signal ID = 0x121 (window lift command), signal ID = 0x122 (window locked status), etc. The system further combines the trigger logic of the target function failure event (such as the user operation "window lift button no response") to filter out signal identifiers directly related to the trigger action. For example, if the failure event is that the button does not respond, the signal ID = 0x121 (the signal for sending the window lift command) is prioritized rather than the window locked status signal. The screening process is based on the causal relationship between the functional definition of the signal identifier and the trigger logic to ensure that the diagnosis focuses on the core signal.

[0072] Each signal identifier is pre-bound to the corresponding fault judgment rule in the preset mapping model. For example, signal ID = 0x121 is bound to the "switch rebound rule", which requires verification of the timing and parameter consistency of signal sending (SEND) and reporting (RECV); signal ID = 0x115 (steering wheel heating control) is bound to the "button no response rule", which only needs to verify whether the signal sending record exists. The system extracts the corresponding fault judgment rules based on the filtered target signal identifiers to form a specific verification logic. For example, for signal ID = 0x121, the system loads the "timing compliance verification" and "parameter matching verification" rules, while signal ID = 0x115 only loads the "signal existence verification" rule. This step ensures that the fault verification logic strictly matches the signal characteristics to avoid redundancy or omissions.

[0073] The preset mapping model organically associates functional modules, signal identifiers, and fault determination rules through a hierarchical structure. Functional modules serve as top-level logical units, with multiple signal identifiers associated downward; each signal identifier is further bound to a specific fault determination rule. For example, the "window control module" is associated with signal ID = 0x121, which corresponds to the "switch rebound rule." When a functional failure event is triggered, the system sequentially locates the signals and rules that need to be verified through a progressive path of functional modules, signal identifiers, and fault rules. This hierarchical design not only improves the clarity of diagnostic logic, but also supports the rapid expansion of new functional modules or signal rules, enhancing the system's maintainability and adaptability.

[0074] In some examples, extracting a signal sequence within a preset time window from the operation log data according to the target signal identifier includes:

[0075] Based on the occurrence time of the target function failure event, a dynamic time offset is expanded to generate a preset time window, wherein the dynamic time offset is determined based on a preset delay threshold corresponding to the target signal identifier;

[0076] Signal records with target signal identifiers within a preset time window are extracted from the operation log data and sorted by timestamp to generate a signal sequence.

[0077] Exemplarily, based on the occurrence time of the target function failure event, a dynamically adaptive preset time window is constructed. Specifically, the dynamic time offset is calculated based on the preset delay threshold bound to the target signal identifier in the preset mapping model. For example, if the preset delay threshold of a signal identifier is 500ms, the dynamic time offset can be extended to 5 seconds before and after the failure occurrence time, forming a retrieval window of [T-5s, T+5s]. This mechanism ensures that the complete interaction cycle of signal sending and reporting is covered by dynamically expanding the time range, while avoiding signal truncation or redundant data retrieval problems caused by fixed windows, effectively balancing diagnostic accuracy and computational efficiency.

[0078] All signal records of the target signal identifier within the preset time window are extracted from the operation log data, and sorted by timestamp to generate a time-series signal sequence. The signal interaction information recorded in the operation log data includes key fields such as signal type (download / report), timestamp and parameter value. By sorting by timestamp, the system converts discrete log entries into signal sequences with strict timing relationships, such as the downlink record SEND (T1) → the reporting record RECV (T2) → the downlink record SEND (T3), etc. The timing processing provides a structured data foundation for the subsequent verification of the consistency and compliance of signal interactions.

[0079] In some examples, the multi-level verification includes a first-level verification, a second-level verification, and a third-level verification. The multi-level verification is performed on the signal sequence to obtain a signal verification result, including:

[0080] Performing a first-level verification on the signal sequence to determine whether there is at least one record of the target signal identifier being issued in the signal sequence;

[0081] If there is a delivery record, perform the second level verification, calculate the time interval between the timestamp of the delivery record and the timestamp of the reporting record corresponding to the target signal identifier, and determine whether the time interval is less than or equal to the preset delay threshold;

[0082] If the time interval is less than or equal to the preset delay threshold, the third level verification is performed to analyze whether the sending parameters in the sending record are consistent with the reporting parameters in the reporting record;

[0083] A signal verification result is generated according to the verification results of the first level verification, the second level verification, and the third level verification, wherein the signal verification result includes at least one of a signal existence status, a timing compliance status, and a parameter matching status.

[0084] Exemplarily, the core of the first-level verification is to confirm whether there is at least one sending record (SEND record) of the target signal identifier in the signal sequence. The system traverses the sorted signal sequence and searches for a sending operation that matches the target signal identifier. If no sending record is detected, the signal existence status is determined to be "missing", indicating that the vehicle control software has not generated or successfully sent the instruction, and the fault may be caused by the failure to send the application layer instruction (such as the button event is not triggered or the software logic error). This verification level is directly related to the "button no response rule" in the fault judgment rule, which quickly eliminates the scenario where no instruction is sent. For example, in the event of no response to the steering wheel heating button, the system directly locates the application layer problem by searching for the missing sending record of signal ID = 0x115.

[0085] The second level of verification determines the timing compliance of signal interaction. When the first level of verification confirms the existence of a dispatch record, the system extracts the timestamp T1 of the dispatch record, and retrieves the reporting record (RECV) of the same signal identifier within the preset time window to obtain its timestamp T2. Calculate the time interval ΔT = |T2-T1| and compare it with the preset delay threshold (300ms) corresponding to the target signal identifier. If ΔT exceeds the threshold, the timing compliance status is determined to be "timeout", indicating that there is a communication delay or link interruption in the signal interaction. For example, after the window lift command is issued, if the reporting feedback delay exceeds 500ms, the communication link anomaly determination is triggered. This level of verification accurately identifies communication layer faults by quantifying the real-time nature of signal interaction.

[0086] The third level of verification performs parameter matching analysis. When the timing compliance status satisfies ΔT ≤ the preset delay threshold, the system further performs the third level of verification to compare whether the sent parameters in the sent record are consistent with the reported parameters in the reported record. The parameter matching analysis is based on the parameter mapping relationship defined in the preset mapping model (e.g., the sent parameter "2" represents "on", and the reported parameter "2" must correspond to the "on" state). If the parameters are inconsistent, the parameter matching status is determined to be "inconsistent", indicating that the hardware actuator did not respond correctly to the instruction, which may be caused by a drive circuit failure, a sensor false alarm, or physical damage to the actuator. This verification level corresponds to the "parameter drift rule". For example, issuing an "on" instruction but reporting the "off" state directly points to a hardware actuator failure.

[0087] Ultimately, the system integrates the three-level verification results to generate a signal verification result that includes signal existence status, timing compliance status, and parameter matching status. Verification results are stored as structured data, for example, {"existence":"exist","timing compliance":"compliant","parameter matching":"inconsistent"}. This result is logically matched against the fault determination rules defined in the preset mapping model. For example, parameter mismatches are directly associated with the hardware actuator fault type. Through a progressive multi-level verification mechanism, the system achieves comprehensive diagnosis from basic signal existence to execution details, ensuring that the fault type determination strictly corresponds to the underlying signal anomaly characteristics, thereby improving the credibility and operability of the diagnostic conclusions.

[0088] In some examples, the fault type of the target functional failure event is determined based on the fault determination rules and the signal verification result, including:

[0089] Match the fault trigger conditions defined in the fault judgment rules based on the signal existence status, timing compliance status, and parameter matching status in the signal verification results;

[0090] If the signal existence status is missing, the fault type is determined to be failure to send application layer instructions;

[0091] If the signal existence status is present and the timing compliance status is greater than the preset delay threshold, the fault type is determined to be a communication link abnormality;

[0092] If the signal existence status is present, the timing compliance status is less than or equal to the preset delay threshold, and the parameter matching status is inconsistent, the fault type is determined to be a hardware actuator fault.

[0093] For example, the signal verification results' signal presence, timing compliance, and parameter matching status are logically matched against predefined fault trigger conditions in a preset mapping model. Fault determination rules are stored as structured conditional expressions, for example: "IF presence = missing THEN fault type = application layer instruction failure." The system traverses the conditional expressions in the rule base, substitutes the verification result parameters, and performs Boolean operations to filter out fault types that meet all conditions.

[0094] When the signal existence status in the signal verification result is "missing," the system determines the fault type to be a failure to send an application-layer command. This status indicates that the target signal identifier's delivery record does not exist at all within the preset time window, indicating that the vehicle control software did not generate or successfully send the command to the underlying actuator. For example, in the event of an unresponsive steering wheel heating button, the system directly eliminates hardware or communication issues by searching for the missing delivery record for signal ID = 0x115, locating the cause as an application-layer logic error or an incorrectly triggered user operation event. This determination strictly adheres to the definition of the "button unresponsive rule" in the fault determination rules, meaning that only the existence of the signal delivery record needs to be verified, without further verification of timing or parameters.

[0095] If the signal presence status is present but the timing compliance status display interval exceeds the preset delay threshold, the system determines the fault type to be a communication link anomaly. In this case, the timestamp interval ΔT between the signal issuance record and the reporting record exceeds the preset threshold, indicating that although the command was issued, the hardware did not respond within the expected time. This indicates a communication layer failure such as CAN bus latency, gateway packet loss, or network topology anomalies. For example, if the reporting feedback delay exceeds 300ms after the steering wheel heating command is issued, it is determined to be a communication link transmission timeout, and the bus load or node communication status needs to be checked.

[0096] If the signal presence status is present and the timing compliance status is compliant, but the parameter matching status is inconsistent, the system determines the fault type to be a hardware actuator failure. This status indicates that the command was delivered on time, but the parameters reported by the actuator do not match the issued command. For example, the command parameter is "window up" but the reported parameter is "window not moved." This judgment directly points to a failure in the hardware actuator drive circuit, mechanical stagnation, or abnormal sensor feedback. For example, if the sunroof opening command parameters are inconsistent with the motor status feedback, the system accurately locates a hardware failure in the sunroof drive motor or position sensor, providing a clear basis for repair and replacement.

[0097] The above-mentioned determination process adopts a hierarchical verification sequence, which covers signal existence check, timing compliance verification and parameter matching analysis in turn, to ensure that the fault type determination is logically rigorous and efficient. The system first checks whether the application layer instructions are missing. If it is confirmed that the instructions are sent normally, it further checks the timing status of the communication link, and finally verifies the parameter consistency of the hardware actuator, effectively avoiding repeated or redundant analysis. For example, if it is detected that the timing exceeds the preset threshold, the system will directly determine it as a communication link failure without continuing to perform the parameter matching step; on the contrary, if the timing is compliant but the parameters do not match, the communication problem can be ruled out and the hardware execution anomaly can be directly locked. This mechanism relies on the rule base defined in the preset mapping model to achieve automatic classification of fault types by accurately matching verification results with fault triggering conditions, improve diagnostic efficiency and accuracy, and provide a flexible technical expansion foundation for complex fault analysis in complex scenarios.

[0098] In some instances, this also includes:

[0099] In the case where a target failure event is associated with multiple target signal identifiers,

[0100] Determine the signal interaction logic between multiple target signal identifiers based on the dependency relationship of the functional modules in the preset mapping model;

[0101] Perform joint analysis on the signal verification results of multiple target signal identifiers according to the signal interaction logic to generate a joint analysis result;

[0102] Based on the joint analysis results, the fault type is determined.

[0103] Exemplarily, when a target function failure event involves multiple target signal identifiers, the system parses the interaction logic between multiple signal identifiers based on the dependency of functional modules in the preset mapping model. For example, the window lift function may depend on signal ID = 0x121 (lift and lower instruction) and signal ID = 0x122 (locked state), and the two need to work together in the order of "unlock first and then lift and lower". The system determines the execution order, causal relationship or shared resources (such as communication bus, power node) between signals through the predefined signal dependency (such as timing dependency, parameter linkage or functional interlocking) in the mapping model. This step abstracts the multi-signal interaction into a logical relationship diagram, providing a structured framework for joint analysis.

[0104] The system cross-compares the verification results of multiple target signal identifiers and identifies abnormal patterns in combination with signal interaction logic. For example, if the timing of signal ID = 0x121 is compliant but the parameters are abnormal, and the existence of signal ID = 0x122 is missing, the system determines that the lock state is not completed based on the dependency relationship, resulting in the failure of the lifting and lowering instructions. Joint analysis uses association rules (such as "Signal A is abnormal and signal B cannot be triggered") or statistical models (such as multi-signal timing offset correlation analysis) to identify the root cause node of the complex fault. For example, if the timing of multiple signals exceeds the limit and share the same CAN bus, it is determined that the bus load is too high and is the common fault source.

[0105] Based on the comprehensive analysis of multiple signal verification results, the system can identify complex faults or anomalies of common dependent nodes. For example, when the signal IDs 0x121 and 0x122 both have timing overrun problems and both rely on the same ECU node, the system will determine that the fault is caused by the abnormal response of the ECU; if the parameters of multiple signals are abnormal and share the same power module, it can be inferred that there is an unstable power supply problem. The system classifies the fault into a complex anomaly type at the communication layer, control layer or hardware layer through the hierarchical dependency of functional modules defined in the preset mapping model (such as the hierarchical association between ECU, signal group and actuator), and generates targeted repair suggestions. This mechanism breaks through the limitations of traditional single signal analysis, can effectively handle fault diagnosis needs in complex scenarios, and significantly improves the comprehensiveness and accuracy of diagnostic results.

[0106] In some instances, this also includes:

[0107] Obtain diagnostic records of historical functional failure events and extract fault verification logic, signal verification results, and fault types from the diagnostic records;

[0108] Based on the association rule mining algorithm, the mapping rules between fault verification logic and fault types are analyzed;

[0109] When the confidence of the mapping rule is greater than a preset confidence threshold, the mapping rule is stored in the fault knowledge base to optimize the fault judgment rule in the preset mapping model.

[0110] For example, diagnostic records of historical functional failure events are obtained and the fault verification logic, signal verification results, and the final confirmed fault type are extracted. The diagnostic records are stored as structured data, containing the functional module identifier of the failure event, the target signal identifier, the multi-level verification results, and the fault type classification label. For example, for the historical event "window lift failure," the verification result {"Existence": "Existence", "Timing Compliance": "Timeout"} for signal ID = 0x121 and the fault type "Communication Link Abnormality" are extracted to form a training data sample. This step builds the data foundation for fault diagnosis knowledge through data cleaning and feature extraction.

[0111] Based on an association rule mining algorithm, the system analyzes the mapping patterns between fault verification logic and fault types. The system uses the feature combination of signal verification results as the antecedent and the fault type as the consequent to calculate the support and confidence of the rules. By setting a preset confidence threshold, it selects strong association rules with high confidence. This process automatically discovers the implicit causal relationship between verification logic and fault types through machine learning, identifying complex fault modes not covered by traditional rule bases.

[0112] Association rules with confidence levels exceeding a preset threshold are stored in the fault knowledge base, and the fault determination rules in the preset mapping model are dynamically updated. Through a periodic incremental learning mechanism, new patterns in historical diagnostic data are continuously absorbed, gradually expanding the coverage of fault determination rules to more edge scenarios. This self-optimization mechanism effectively improves the generalization capabilities of the preset mapping model, reduces manual maintenance costs, and ensures that diagnostic rules remain synchronized with the actual vehicle operating status, enhancing the accuracy and adaptability of fault classification.

[0113] See also Figure 2 , which is a schematic structural diagram of a vehicle control software function failure analysis device provided in an embodiment of the present application, comprising:

[0114] An operation data acquisition unit 21 is used to acquire operation log data corresponding to a target function failure event;

[0115] The target signal determination unit 22 determines the target signal identifier and the fault determination rule associated with the target function failure event based on a preset mapping model;

[0116] A signal sequence generating unit 23 is configured to extract a signal sequence within a preset time window from the operation log data according to the target signal identifier;

[0117] A signal result verification unit 24 performs multi-level verification on the signal sequence to obtain a signal verification result;

[0118] The fault type analysis unit 25 determines the fault type of the target function failure event based on the fault determination rule and the signal verification result.

[0119] See also Figure 3 An embodiment of the present application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, the steps of any method for analyzing the failure of a vehicle control software function are implemented.

[0120] Since the electronic device introduced in this embodiment is a device used to implement an analysis device for vehicle control software function failure in an embodiment of the present application, based on the method introduced in the embodiment of the present application, technical personnel in this field can understand the specific implementation of the electronic device of this embodiment and its various variations. Therefore, how the electronic device implements the method in the embodiment of the present application will not be introduced in detail here. As long as the equipment used by technical personnel in this field to implement the method in the embodiment of the present application falls within the scope of protection to be protected by this application.

[0121] During the specific implementation process, when the computer program 311 is executed by the processor, any implementation method of the embodiments corresponding to the first aspect can be implemented.

[0122] It should be noted that, 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.

[0123] Those skilled in the art will appreciate that embodiments of the present application may provide methods, systems, or computer program products. Thus, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-readable storage media containing computer-readable program code.

[0124] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0125] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0126] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0127] The present application also provides a computer program product, which includes computer software instructions. When the computer software instructions are executed on a processing device, the processing device executes Figure 1 The process of a method for analyzing vehicle control software function failure in the corresponding embodiment.

[0128] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium can be a magnetic medium, an optical medium or a semiconductor medium, etc.

[0129] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0132] In addition, the functional units in the various embodiments of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The above-mentioned integrated units may be implemented in the form of hardware and / or software functional units.

[0133] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device to execute all or part of the steps of the various embodiments of the method of the present application.

[0134] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0135] Although the preferred embodiments of this specification have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of this specification.

[0136] Obviously, those skilled in the art may make various changes and modifications to this specification without departing from the spirit and scope of this specification. Thus, if such changes and modifications fall within the scope of the claims of this specification and their equivalents, this specification is intended to include such changes and modifications.

Claims

1. A method for analyzing vehicle control software failure, characterized in that: include: Obtain the operation log data corresponding to the target function failure event; Determining a target signal identifier and a fault determination rule associated with the target function failure event based on a preset mapping model; extracting a signal sequence within a preset time window from the operation log data according to the target signal identifier; performing multi-level verification on the signal sequence to obtain a signal verification result; Based on the fault determination rule and the signal verification result, the fault type of the target function failure event is determined.

2. The method according to claim 1, characterized in that The determining, based on a preset mapping model, a target signal identifier and a fault determination rule associated with the target function failure event includes: Determining a target functional module that matches the functional description of the target functional failure event based on a mapping relationship between functional modules and signal identifiers in a preset mapping model; Filtering out a target signal identifier logically associated with the triggering logic of the target function failure event from a plurality of candidate signal identifiers corresponding to the target function module; Based on the target signal identifier, a fault determination rule in the preset mapping model is determined.

3. The method according to claim 1, characterized in that The extracting, from the operation log data according to the target signal identifier, a signal sequence within a preset time window includes: Based on the occurrence time of the target function failure event, the dynamic time offset is expanded to generate the preset time window, wherein the dynamic time offset is determined based on the preset delay threshold corresponding to the target signal identifier; The signal records of the target signal identifier within the preset time window are extracted from the operation log data, and are sorted by timestamp to generate a signal sequence.

4. The method according to claim 1, wherein The multi-level verification includes a first-level verification, a second-level verification, and a third-level verification. The multi-level verification is performed on the signal sequence to obtain a signal verification result, including: Performing a first level verification on the signal sequence to determine whether there is at least one issuance record of the target signal identifier in the signal sequence; If the sending record exists, perform the second level verification, calculate the time interval between the timestamp of the sending record and the timestamp of the reporting record corresponding to the target signal identifier, and determine whether the time interval is less than or equal to the preset delay threshold; If the time interval is less than or equal to the preset delay threshold, performing a third level verification to analyze whether the sending parameters in the sending record are consistent with the reporting parameters in the reporting record; A signal verification result is generated according to the verification results of the first level verification, the second level verification, and the third level verification, wherein the signal verification result includes at least one of a signal existence status, a timing compliance status, and a parameter matching status.

5. The method according to claim 4, characterized in that The determining the fault type of the target function failure event based on the fault determination rule and the signal verification result includes: Matching the fault triggering conditions defined in the fault determination rule based on the signal existence status, timing compliance status, and parameter matching status in the signal verification result; If the signal existence status is missing, determining that the fault type is a failure to send an application layer instruction; If the signal existence status is present and the timing compliance status is greater than the preset delay threshold, it is determined that the fault type is a communication link abnormality; If the signal existence status is present, the timing compliance status is less than or equal to the preset delay threshold, and the parameter matching status is inconsistent, it is determined that the fault type is a hardware actuator fault.

6. The method according to claim 2, characterized in that Also includes: In the case where the target function failure event is associated with multiple target signal identifiers, Determining the signal interaction logic between the plurality of target signal identifiers based on the dependency relationship of the functional modules in the preset mapping model; performing a joint analysis on the signal verification results of the plurality of target signal identifiers according to the signal interaction logic to generate a joint analysis result; Based on the joint analysis result, the fault type is determined.

7. The method according to claim 1, characterized in that Also includes: Obtaining diagnostic records of historical functional failure events, and extracting fault verification logic, signal verification results, and fault types from the diagnostic records; Analyze the mapping rules between the fault verification logic and the fault type based on the association rule mining algorithm; When the confidence of the mapping rule is greater than a preset confidence threshold, the mapping rule is stored in a fault knowledge base to optimize the fault judgment rule in the preset mapping model.

8. A device for analyzing vehicle control software failure, characterized in that: include: An operation data acquisition unit, used to acquire operation log data corresponding to a target function failure event; a target signal determination unit, which determines a target signal identifier and a fault determination rule associated with the target function failure event based on a preset mapping model; a signal sequence generating unit, configured to extract a signal sequence within a preset time window from the operation log data according to the target signal identifier; A signal result verification unit, configured to perform multi-level verification on the signal sequence to obtain a signal verification result; The fault type analysis unit determines the fault type of the target function failure event based on the fault determination rule and the signal verification result.

9. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to implement the steps of the vehicle control software function failure analysis method as described in any one of claims 1 to 7 when executing the computer program stored in the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for analyzing vehicle control software function failure according to any one of claims 1 to 7 is implemented.

Images