Fault code generation method and vehicle

Abstract

The invention provides a fault code generation method and a vehicle, and the method is applied to the technical field of vehicle diagnosis, and the method comprises the steps: obtaining a configuration list text of a whole vehicle function, and the whole vehicle function comprises a plurality of system functions; identifying a function implementation strategy of each system function from the configuration list text, and performing failure analysis on the system functions based on the function implementation strategies to obtain an analysis report text; and generating a fault code list of the whole vehicle function according to the analysis report text. According to the method, the complete coverage of the whole vehicle fault code can be realized, so that the fault true cause can be quickly positioned when the fault occurs, and the after-sales maintenance efficiency and the user experience are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and more specifically, to a fault code generation method and vehicle in the field of vehicle diagnostics. Background Technology

[0002] As vehicle functions become increasingly sophisticated, the interaction logic between various electronic control units becomes more complex. To ensure rapid fault location after a fault occurs, the entire vehicle needs to have comprehensive fault code coverage capabilities.

[0003] However, some faults in related technologies have no corresponding fault codes, or there are a large number of fault codes, but they may not be effective. This leads to redundant or invalid fault codes interfering with diagnosis, resulting in poor fault code coverage and seriously affecting after-sales maintenance efficiency and user experience. Summary of the Invention

[0004] This application provides a fault code generation method and a vehicle. The method can achieve complete coverage of fault codes for the entire vehicle, enabling rapid location of the root cause of the fault and improving after-sales maintenance efficiency and user experience.

[0005] Firstly, a fault code generation method is provided, which includes: obtaining a configuration list text of vehicle functions, wherein the vehicle functions include multiple system functions; identifying the function implementation strategy of each system function from the configuration list text; performing failure analysis on the system functions based on the function implementation strategy to obtain an analysis report text; and generating a fault code list of vehicle functions based on the analysis report text.

[0006] The above technical solution enables the system functions of the entire vehicle to be sorted out based on the configuration list text of the vehicle functions, and failure analysis of the system functions can be performed. Through failure analysis, the possible failure modes of each system function and their impact on vehicle performance can be identified, thereby formulating corresponding fault diagnosis strategies for each potential fault situation. Based on the analysis report text obtained from the failure analysis, a fault code list with sufficient complete coverage is generated, achieving complete coverage of the vehicle's fault codes. This ensures that all possible faults can be identified and located, enabling the rapid location of the root cause of the fault when it occurs, thereby improving after-sales maintenance efficiency and user experience.

[0007] In conjunction with the first aspect, in some possible implementation methods, failure analysis of system functions is performed based on the function implementation strategy, including: analyzing at least one functional failure scenario of the system function according to the function implementation strategy; evaluating the functional failure mode of the system function under each functional failure scenario; and determining at least one of the requirement level, scope of application, and impact level of the fault code according to the functional failure mode.

[0008] The above technical solutions enable failure analysis of system functions, identifying which faults have a critical impact on functional safety and user experience. This allows for the determination of fault code requirements, applicability, and impact levels, providing a basis for the targeted design of high-value, fault-correlated fault codes. Specifically, it enables refined, scenario-driven failure analysis of system functions, not only identifying potential functional failure scenarios under specific operating conditions or triggers but also deeply analyzing the specific failure modes exhibited by the system functions in each scenario. Based on this, and considering factors such as functional safety requirements, user experience, and regulatory compliance, the system can scientifically assess and clarify the failure modes. The structured analysis process, which identifies the fault code requirements, scope of application, and impact level corresponding to each failure mode, ensures that fault code design no longer relies on empirical guesswork or simply covering hardware interfaces. Instead, it focuses on faults that truly have a substantial impact on vehicle safety, performance, and user experience. The resulting diagnostic requirements are highly targeted and relevant, avoiding redundant alarms and resource waste caused by low-value fault codes. It also ensures that critical failures are captured first and accurately, providing a solid basis for subsequently developing precise detection logic, alarm strategies, and handling mechanisms. Ultimately, this supports the construction of an efficient, reliable, user-friendly vehicle diagnostic system that meets functional safety standards.

[0009] Combining the first aspect and the above implementation methods, in some possible implementation methods, generating a fault code list for the whole vehicle function based on the analysis report text includes: obtaining a pre-set list of detection types and a list of handling strategies; generating a fault code list text based on the analysis report text and the list of detection types; and generating a fault code list based on the fault code list text and the list of handling strategies.

[0010] The above technical solution can match appropriate fault detection methods to the key failure modes identified in the analysis report based on a preset list of detection types, forming a fault code list text. Combined with the processing strategy list, corresponding system response behaviors are configured for each fault code, and finally, a complete and logically rigorous list of vehicle fault codes is output. This ensures that the design of the fault codes not only fits the actual failure scenarios, but also meets the needs of functional safety, user experience, and after-sales diagnosis, thereby improving the integrity of the diagnostic system and maintenance efficiency.

[0011] Combining the first aspect and the above implementation methods, in some possible implementation methods, generating a fault code list text based on the analysis report text and the detection type list includes: identifying at least one of the requirement level, scope of application, and impact level in the analysis report text; in response to a time when the requirement level is greater than a preset requirement threshold, determining the detection type of the fault code corresponding to the system function based on the scope of application and the detection type list; and generating a fault code list text based on the detection type and impact level.

[0012] The above technical solutions can determine whether corresponding system functions need to be set with corresponding fault codes by using demand levels and demand thresholds. This ensures that fault codes are generated only for truly critical failure scenarios, avoiding the generation of redundant or invalid fault codes, improving the effectiveness of diagnostic information, determining the detection type of fault codes corresponding to system functions, and accurately selecting the detection mechanism most suitable for the failure mode of the function. This makes the fault codes technically feasible and engineering implementable. By introducing an impact level to reflect the degree of impact of the fault, it lays the groundwork for subsequent guidance on fault code response strategies.

[0013] Combining the first aspect and the above implementation methods, in some possible implementation methods, the detection type of the fault code corresponding to the system function is determined according to the adaptation range and the detection type list, including: identifying the fault code corresponding to the system function within the adaptation range; querying the fault code detection type list using the fault code as an index; querying the detection type of the fault code from the detection type list; if no detection type is found, then responding to the user's interaction action, determining the detection type of the user-defined fault code based on the interaction action.

[0014] The above technical solutions not only ensure that each system function's associated fault codes have a clear, feasible, and highly application-specific detection mechanism, effectively avoiding false alarms, missed alarms, or diagnostic failures caused by ambiguous or inapplicable detection logic, but also significantly improve the engineering feasibility of fault code design and the robustness of the diagnostic system. Furthermore, by introducing a user-interactive, customizable mechanism, new detection types can be flexibly defined through the human-machine interface when the preset detection type list cannot cover new failure modes caused by new electronic components or innovative functions. This maintains the standardized backbone of the diagnostic system while giving it openness and scalability for future technological evolution. It ensures the consistency and reusability of traditional functional diagnostics while rapidly responding to new diagnostic needs arising from continuous iterations in vehicle electronic and electrical architecture, software-defined functions, and cybersecurity. This provides technical support for OEMs to build a forward-looking, highly adaptable, and lifecycle-maintainable diagnostic system.

[0015] Combining the first aspect and the above implementation methods, in some possible implementation methods, generating a fault code list based on the fault code list text and the processing strategy list includes: identifying the detection type and impact level of the fault codes in the fault code list text; determining the processing strategy for the fault codes based on the detection type and the processing strategy list; determining the alarm prompt information for the fault codes based on the impact level; and generating the fault code list based on the fault code processing strategy and the alarm prompt information.

[0016] The above technical solution can systematically generate an executable fault code list with complete diagnostic behavior definitions. This list includes the basic identifier of each fault code, as well as closely related processing strategies and alarm prompts. All content is generated by automatically matching preset rules according to the detection type and impact level, ensuring logical consistency and no subjective bias. This provides a technical basis for the implementation of vehicle functional safety strategies and the efficient operation of the after-sales diagnostic system. When faced with a fault, maintenance personnel can directly and quickly understand the nature of the fault, judge its severity, and take precise measures based on the complete semantic information carried by the fault code, significantly shortening troubleshooting time.

[0017] In combination with the first aspect and the above implementation methods, in some possible implementation methods, determining the processing strategy of the fault code based on the detection type and the processing strategy list includes: determining the classification type of the fault code based on the detection type; and determining the processing strategy of the fault code based on the classification type and the processing strategy list.

[0018] The above technical solution first categorizes fault codes into predefined classification types based on their detection type, and then automatically matches the corresponding system response logic from a unified list of processing strategies according to the classification type. Since faults of different classification types have significant differences in physical nature, impact mechanism, and safety attributes, this method ensures that the configured processing strategy is highly consistent with the fundamental characteristics of the fault, avoiding over-response or under-response problems caused by strategy mismatch, such as the failure to alarm for critical safety faults. At the same time, by using classification type as an intermediate abstraction layer to drive strategy allocation, there is no need to manually define processing logic for hundreds or thousands of specific fault codes one by one, which greatly reduces repetitive configuration work and significantly improves the development efficiency, consistency, and maintainability of fault codes. When diagnostic requirements are updated or new fault types appear, only the classification mapping or strategy template needs to be adjusted to apply the changes to all similar fault codes in batches, enhancing the flexibility and scalability of the diagnostic system and providing technical support for OEMs to build a standardized, modular, and highly cohesive diagnostic architecture.

[0019] Combining the first aspect and the above implementation methods, in some possible implementation methods, the classification type of the fault code is determined according to the detection type, including: obtaining a first correspondence table between the detection type and the classification type; and determining the classification type according to the detection type and the first correspondence table.

[0020] The above technical solution enables the automation and standardization of fault code classification. After obtaining the detection type of a fault code, the first correspondence table can be directly queried to quickly and accurately determine its classification type. This ensures the consistency and traceability of the classification logic, avoids subjective bias or omissions caused by manual judgment, and lays a structured foundation for subsequent unified matching processing strategies and alarm rules based on classification types. Since the classification process relies on a configurable mapping table, when a new detection type is added or the classification system is adjusted, only the table needs to be updated for global effect. This significantly improves the development efficiency, maintenance flexibility, and engineering scalability of the diagnostic system design, effectively supporting the standardization and modular construction of the vehicle-level fault code system.

[0021] Combining the first aspect and the above implementation methods, in some possible implementation methods, the alarm prompt information of the fault code is determined according to the impact level, including: obtaining a second correspondence table between the impact level and the alarm prompt information; and determining the alarm prompt information according to the impact level and the second correspondence table.

[0022] The above technical solution enables automatic querying and matching of corresponding alarm prompts based on the impact level associated with the fault code, thereby achieving precision and standardization of alarm strategies. This mechanism ensures that the prompts received by the user are strictly aligned with the severity of the fault, avoiding both excessive alarms caused by low-risk faults that cause user anxiety and delays in handling high-risk faults due to insufficient prompts, effectively improving the rationality and safety of human-computer interaction.

[0023] In a second aspect, a vehicle is provided, the vehicle including: a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to perform fault diagnosis based on a fault code list, the fault code list being generated based on the fault code generation method of the above embodiments. Attached Figure Description

[0024] Figure 1 This is a schematic flowchart of a fault code generation method provided in an embodiment of this application; Figure 2 This is a flowchart of the fault code design provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a functional DFEMA analysis example provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a fault code generation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the vehicle structure provided in the embodiments of this application. Detailed Implementation

[0025] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0026] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0027] The vehicle fault code generation methods in related technologies have significant limitations. The core problem lies in the fact that they are designed at the level of individual ECUs (Electronic Control Units) or components, lacking a comprehensive planning and coordination mechanism at the vehicle system level. Specifically, each ECU supplier typically defines the fault codes that their module may generate independently based on the hardware interface capabilities (such as drive type and communication resources) and existing project experience. This "bottom-up" design approach often focuses only on "what I can detect," rather than "what the entire vehicle needs to diagnose."

[0028] Due to the lack of unified diagnostic requirements input, different suppliers may use different DTC (Diagnostic Trouble Code) numbers, detection logic, or reporting conditions for similar failure scenarios, leading to inconsistent fault code semantics across ECUs. Simultaneously, the root cause of failures in certain vehicle functions involving multi-module collaboration (such as automatic parking and energy recovery) may be distributed across multiple ECUs. However, because each module defines DTCs only from a local perspective, it cannot cover cross-domain coupled failure scenarios, resulting in missed detections. Furthermore, some non-critical signals or internal debugging information may be mistakenly set as user-visible DTCs, causing redundancy or false alarms.

[0029] More importantly, the methods in these technologies do not take the actual user experience and after-sales maintenance efficiency into account in their design. For example, a fault that causes high beams to fail to illuminate might only be recorded as "output drive abnormality" in the BCM (Body Control Module) without being linked to the user-perceptible level of "high beam malfunction." Repair personnel would then have to check multiple DTCs layer by layer to pinpoint the root cause, significantly reducing diagnostic efficiency. Furthermore, because systematic reverse engineering based on functional safety or cybersecurity requirements is not incorporated, critical safety-related faults may not be adequately covered, leading to compliance and safety risks.

[0030] In summary, the DTC design methods in related technologies are insufficient to support the precise diagnostic needs of highly integrated electronic and electrical architectures, and also fail to meet users' expectations for reliability, transparency, and rapid service. Therefore, this application provides a vehicle control method that adopts a positive DTC design system centered on vehicle functions, driven by failure scenarios, and guided by user experience, achieving a fundamental shift from "being able to report codes" to "reporting accurate codes and useful codes."

[0031] The application scenarios or system architecture of the embodiments of this application will be described next.

[0032] Generally, the embodiments of this application aim to solve the core problem of insufficient fault diagnosis coverage in current vehicle electronic systems. The embodiments of this application perform failure analysis on each system function, thereby defining the demand level, scope of application, and impact level of each fault code; then, combined with a preset list of detection types and classification types, the detection type and classification type of each fault code are determined; and then, based on the list of processing strategies and impact level, a standardized fault code list containing processing logic and alarm prompt information is automatically generated, achieving complete coverage of vehicle fault codes, enabling rapid location of the root cause of faults, and improving after-sales maintenance efficiency and user experience.

[0033] Figure 1 This is a schematic flowchart of a fault code generation method provided in an embodiment of this application.

[0034] For example, such as Figure 1 As shown, the fault code generation method includes the following steps: In step S101, the configuration list text of the vehicle functions is obtained, and the vehicle functions include multiple system functions.

[0035] Among them, vehicle functions refer to the complete capabilities provided by a vehicle to achieve specific user needs or technical goals, which are usually completed collaboratively by multiple electronic control units, such as automatic emergency braking and remote start; system functions are the basic building blocks of vehicle functions, usually implemented by one or more electronic control units, and belong to the lower-level decomposition of vehicle functions. For example, vehicle functions such as automatic parking may include system functions such as ultrasonic radar obstacle detection and steering control; the configuration list text of vehicle functions refers to a table that includes the vehicle functions supported by the current model and their corresponding system function decompositions.

[0036] It is understood that the embodiments of this application can first obtain the configuration list text of the vehicle functions. The configuration list text includes all vehicle functions supported by the current model and their corresponding system function decompositions, providing a basis for the fault code design below. Specifically, this step takes the system function configuration list as input, performs a structured sorting of all system functions of the vehicle, clarifies the implementation method of each function, and outputs the subsystem function implementation strategy. The content covers key information such as the function implementation system block diagram, the ECUs involved, bus communication methods, interaction signals, peripheral loads, and hardware types, providing basic input for subsequent analysis. Among them, interaction signals and logic include LIN (Local Interconnect Network), CAN (Controller Area Network), Ethernet, LVDS (Low-Voltage Differential Signaling), etc. Interaction signals include hardware signals, bus signals, etc., and peripheral loads include power supplies, relays, sensors, and actuators, etc.

[0037] like Figure 2As shown, the system function analysis uses the vehicle system function configuration list as input. It systematically and structurally analyzes all subsystem functions of the vehicle, such as high beam control, automatic emergency braking, and thermal management. It clarifies the specific implementation path of each function at the engineering level and outputs detailed subsystem function implementation strategies. The function implementation strategies comprehensively cover: the system architecture block diagram of the function, clearly showing the signal flow and control logic; the ECU nodes involved, such as BCM and domain controllers; the bus communication methods used between and within each ECU, including CAN, LIN, Ethernet, and low-voltage differential signals; key interaction signals and logic, including hardware hardwired signals such as switch / analog signals, and bus messages such as CAN ID (Controller Area Network Identifier), signal period, and effective range; the connected peripheral loads and interface resources, such as power supply type, relay driver, sensor model, and actuator specifications; and the underlying hardware type, such as high-side / low-side drivers and chip selection. This structured output not only fully depicts the technical implementation details of the function, but also provides a traceable engineering foundation for subsequent accurate failure mode analysis, fault detection capability assessment, and fault code design.

[0038] In step S102, the function implementation strategy of each system function is identified from the configuration list text, and the failure analysis of the system function is performed based on the function implementation strategy to obtain the analysis report text.

[0039] The functional implementation strategy refers to the technical solutions, architecture design, signal flow, control logic, and dependent hardware and software resources used to implement a certain system function. Failure analysis, based on the functional implementation strategy, systematically identifies potential failure scenarios and failure modes that may lead to the abnormality or loss of the function, such as sensor failure and communication interruption. The analysis report text is a document generated during the vehicle functional failure analysis phase. This text records the potential risks and diagnostic requirements of each system function under a specific functional implementation strategy, including but not limited to: the system function name and its corresponding vehicle function; a description of the functional implementation strategy, such as the dependent sensors, actuators, communication buses, control logic, and hardware and software resources; and identification. The report identifies at least one functional failure scenario; the corresponding functional failure mode for each scenario; the requirement level based on the failure consequence assessment, used to determine whether a fault code needs to be configured for that functional failure mode; the scope of application, specifying the applicable vehicle platform, ECU version, power status, or operating conditions for the fault code; and the impact level, quantifying the degree of impact of the fault on safety, regulations, functional performance, or user experience, such as classifying it into levels 1, 2, 3, etc., from low to high severity, which will be specifically set according to actual needs and is not specifically limited here. This report serves as the design input for subsequent fault codes, ensuring that the generated fault codes cover real failure risks and supporting the construction of a highly complete and efficient vehicle diagnostic system.

[0040] It is understood that this application embodiment extracts each system function from the configuration list text and further identifies the function implementation strategy on which it implements the function. Based on this, failure analysis is carried out to sort out various failure scenarios and failure modes that may occur under the strategy, assess their impact on functional performance and vehicle safety, and compile the analysis results into an analysis report text. Through failure analysis, the possible failure modes of each system function and their impact on vehicle performance can be identified, thereby designing corresponding fault codes for each potential failure situation, achieving complete coverage of vehicle fault codes. Specifically, taking the system function implementation strategy as input, functional-level failure mode and effect analysis (DFEMA, Design Failure Mode and Effects Analysis) is carried out to identify the possible failure scenarios and corresponding failure modes of each function, output a DFEMA analysis report, clarify which failures need diagnostic coverage, define the impact of failure modes on functions, and define severity levels based on the degree of impact, matching them with the impact level of fault codes, providing a basis for fault code definition.

[0041] In this embodiment of the application, failure analysis of system functions based on function implementation strategy includes: analyzing at least one functional failure scenario of system functions according to function implementation strategy; evaluating the functional failure mode of system functions under each functional failure scenario; and determining at least one of the requirement level, scope of application, and impact level of fault codes according to the functional failure mode.

[0042] Among them, the functional failure scenario refers to a typical situation in which the system function cannot perform as expected under specific conditions or causes, such as sensor power failure, communication interruption, software deadlock, etc.; the functional failure mode describes the abnormal behavior or output state of the function under the failure scenario, such as "loss of high beam control signal" or "brake request value is always zero"; the fault code requirement level is the degree to which a fault code needs to be set according to the functional failure mode definition, which is used to guide whether the fault code needs to be designed and its design priority; the scope of application refers to the specific conditions under which the fault code applies; the impact level measures the degree of impact of the failure function corresponding to the fault code on the overall vehicle safety, user experience, or functional performance. For example, if the functional failure will affect vehicle safety, its impact level is set to the highest level.

[0043] It is understood that the embodiments of this application identify possible functional failure scenarios under the system function based on the system function implementation strategy, analyze the specific functional failure modes of the system function under these functional failure scenarios, and then determine the demand level, scope of application and impact level of the corresponding fault code according to the actual impact of the functional failure mode on vehicle safety, regulations or user experience, so as to ensure that the fault codes generated subsequently can not only cover real risks, but also have engineering feasibility and after-sales diagnostics. For example, the functional failure scenario is that the high beam cannot be turned on, and the functional failure mode is that the switch is open, etc. This functional failure does not affect the use of the vehicle and can be perceived by the user. Based on this, the demand level, scope of application and impact level of the fault code are set.

[0044] like Figure 2As shown, functional DFEMA analysis takes the subsystem function implementation strategy as input and systematically conducts functional-level failure mode and effect analysis. It deeply analyzes the various failure paths that each subsystem function may encounter under its specific implementation architecture. During the analysis, it combines factors such as the ECUs, communication buses (e.g., CAN / LIN / Ethernet), hardware interfaces (e.g., sensors, actuators, drive circuits), signal interaction logic, and peripheral loads to identify potential functional failure scenarios under specific triggers (e.g., power supply anomalies, communication interruptions, component aging, software deadlocks), and further refines them into specific failure modes (e.g., "BCM cannot output high-side drive signal"). For each failure mode, its actual impact on the vehicle's functional performance, safety, compliance, and user experience is assessed, and a severity level is defined accordingly. This level directly maps to the impact level in subsequent fault code design. The final DFEMA analysis report not only clearly identifies which failures must be covered by DTCs, but also provides a structured basis for diagnostic requirements for each failure mode that needs to be covered, ensuring that fault code design is targeted, accurate and effective, and supporting the integrity and engineering feasibility of the whole vehicle diagnostic system.

[0045] like Figure 3 The image shows an example of a functional DFEMA analysis, such as... Figure 3 The diagram illustrates the analysis process based on system function identification, failure mode identification, failure mode impact, and severity assessment, as detailed below: First, the key components involved in turning on the high beams are identified through system function identification: the switch, BCM, CAN bus, lamps, and power relays. Next, the failure mode identification phase is initiated, listing possible fault types for each component, such as switch jamming, BCM software or memory failure, CAN communication anomalies (e.g., busoff), internal short circuits or open circuits in the lamps, and poor relay contact. Then, in the failure mode impact phase, the specific impact of each fault on the function is analyzed; for example, signal transmission failure causing the high beams to not illuminate. Finally, a severity assessment is performed to comprehensively determine the fault. For instance, if it causes a perceptual problem for the customer (inability to turn on the high beams) but does not affect basic vehicle driving safety, it falls under the category of functional degradation faults and is classified as "Fault Level 2". This entire process embodies a function-centric systemic failure analysis method, supporting the design of subsequent fault codes and the formulation of diagnostic strategies.

[0046] In step S103, a list of fault codes for the vehicle's functions is generated based on the analysis report text.

[0047] It is understood that, after obtaining the analysis report text, this application embodiment generates a complete and executable list of fault codes based on the analysis report text, providing a technical basis for the development, testing and after-sales application of vehicle diagnostic functions.

[0048] In this embodiment of the application, generating a fault code list for vehicle functions based on the analysis report text includes: obtaining a pre-set list of detection types and a list of processing strategies; generating a fault code list text based on the analysis report text and the list of detection types; and generating a fault code list based on the fault code list text and the list of processing strategies.

[0049] The fault code detection type list is a predefined structured mapping table that clearly categorizes various low-level fault detection methods (such as abnormal switch input, analog signal over-limit, bottom-side or high-side drive output faults, ECU external circuit open / short circuits, etc.) under a unified detection type name, for example, categorized as "external electrical circuit fault detection," thus standardizing the description of how faults are identified. The fault code processing strategy list is a set of preset system response rules that specify the specific behaviors to be triggered after different types of faults are confirmed, such as "record the fault code and illuminate the fault light," "store only without alarm," or "restrict related function outputs." These two lists together form a bridge from fault perception to system response, ensuring that the design of fault codes has both technical consistency and can accurately match appropriate diagnostic and control strategies according to the nature of the fault, thereby improving the reliability, maintainability, and user experience of the vehicle diagnostic system.

[0050] Understandably, after obtaining the analysis report text generated by the functional failure analysis, its content is first structured and parsed to extract key attributes such as failure scenarios, failure modes, requirement levels, adaptation scope, and impact levels for each system function. Subsequently, combined with a pre-set list of fault code detection types, which defines various underlying detection mechanisms, and further combined with a pre-set list of fault code handling strategies, covering response rules for general and hardware faults, such as alarm methods, function degradation measures, and recovery conditions, a complete diagnostic behavior logic is configured for each fault code. Finally, a complete and engineering-executable list of vehicle fault codes is output, thus providing a unified, reliable, and traceable technical basis for the forward development, efficient verification, and precise operation and maintenance of vehicle diagnostic functions, significantly improving fault coverage, location accuracy, and user satisfaction.

[0051] In this embodiment of the application, generating a fault code list text based on the analysis report text and the detection type list includes: identifying at least one of the demand level, scope of application, and impact level in the analysis report text; in response to a time when the demand level is greater than a preset demand threshold, determining the detection type of the fault code corresponding to the system function based on the scope of application and the detection type list; and generating a fault code list text based on the detection type and impact level of the fault code.

[0052] The requirement threshold is a pre-defined criterion used to filter which failure modes require fault codes. Fault codes are generated when the requirement level in the analysis report is higher than or equal to this threshold. The requirement threshold is set according to actual needs and is not specifically limited here.

[0053] It is understood that, in generating the fault code list text, this application embodiment first extracts the key attributes of each failure mode from the analysis report text, including at least one of the requirements level, scope of application, and impact level; then it determines whether the requirements level of the failure mode reaches or exceeds a preset requirements threshold, which serves as a filtering mechanism to determine which failure modes are necessary to configure fault codes; when the requirements level meets the threshold condition, it further combines its scope of application with a preset list of detection types to match the fault code detection type most suitable for the system function; finally, it associates the determined detection type with its corresponding impact level to generate a structured fault code list text, thereby ensuring that the design of fault codes focuses on truly critical failure risks and matches specific application scenarios and technical implementation capabilities, avoiding redundancy or omissions, and laying the foundation for subsequent diagnostic strategy formulation.

[0054] Specifically, such as Figure 2 As shown, the fault code definition is based on the DFEMA analysis report, combined with dimensions such as requirement level, scope of application and impact level, to evaluate each failure mode, determine whether a fault code needs to be generated, and define its detection type, classification type and other attributes, and finally output the fault code list text to ensure that all critical failures are effectively covered.

[0055] In this embodiment of the application, the detection type of the fault code corresponding to the system function is determined according to the adaptation range and the detection type list, including: identifying the fault code corresponding to the system function within the adaptation range; querying the detection type list of fault codes using the fault code as an index; querying the detection type of the fault code from the detection type list; if no detection type is found, then responding to the user's interaction action, determining the detection type of the user-defined fault code based on the interaction action.

[0056] The detection types can be broadly categorized as follows: 1. Bus-related issues, such as invalid signals / message loss / busoff / overvoltage / undervoltage; 2. Information security or functional safety, such as E2E (End-to-End) protection / Secoc (Secure Onboard Communication), etc. 3. I / O (Input / Output) output types, including various pins, short circuit / open circuit / short current / stuck; 4. ECU internal fault detection, including storage devices / communication devices / actuators / sensors; 5. Determine if certain functions require special configuration, such as configuration words not written / incorrect configuration words / software version errors, etc. Define fault code numbers / names to create an initial fault code list text.

[0057] The classification of fault code detection types is shown in Table 1, which is a list of fault code detection types.

[0058] Table 1

[0059] It is understood that, in order to determine the detection type of the fault code corresponding to the system function, this application embodiment first filters out the currently valid and required system function corresponding fault codes based on the scope of adaptation; then, using the fault code as an index, it searches in the pre-set fault code detection type list. If a matching item is found, the standard detection type is directly adopted; if no corresponding detection type is found, for example, in the face of new intelligent components or new failure modes caused by innovative functions, the system will trigger the user interaction mechanism to respond to the user's operation, such as selecting or inputting through the configuration tool, allowing the user to customize the detection type of the fault code. This method ensures both the standardized processing of existing standard faults and the flexible expansion capability for cutting-edge technologies or special scenarios, thereby ensuring that all key faults have clear, feasible, and implementable detection logic, effectively supporting the integrity, foresight, and engineering feasibility of the vehicle diagnostic system.

[0060] like Figure 2 As shown, the definition of fault codes uses the DFEMA analysis report as the core input, and performs a multi-dimensional comprehensive evaluation of each identified failure mode: First, it determines whether it is necessary to configure a fault code based on its demand level. When the demand level reaches or exceeds a preset threshold, it is included in the diagnostic coverage. Second, it considers the adaptation range, including applicable vehicle platform, ECU hardware version, power status, vehicle speed range, and other operating conditions to ensure that the fault code is activated in a real and effective scenario. At the same time, it refers to the impact level to associate with subsequent alarm and handling strategies. Based on this, it matches and defines the detection type (such as "external electrical circuit fault", "voltage anomaly detection", "internal circuit fault detection", etc.) and classification type (i.e., "general type" or "hardware type") for each failure mode to be covered, forming a structured combination of technical attributes. Finally, the above information is integrated and output as a fault code list text. This list not only clearly lists the fault codes and their related attribute information, but also ensures that key failure situations that have a substantial impact on the vehicle's function, safety, or user experience can be covered, laying the foundation for the subsequent generation of a complete and executable fault code list.

[0061] In this embodiment of the application, generating a fault code list based on a fault code list text and a processing strategy list includes: identifying the detection type and impact level of the fault codes in the fault code list text; determining the processing strategy for the fault codes based on the detection type and the processing strategy list; determining the alarm prompt information for the fault codes based on the impact level; and generating a fault code list based on the fault code processing strategy and the alarm prompt information.

[0062] The handling strategies for fault codes, determined based on the detection type and handling strategy list, will be described in detail below and will not be repeated here. Alarm prompts are fault prompts for users or maintenance personnel, such as instrument icons, text messages, sound warnings, or remote APP (Application) push information. Their form and urgency are determined by the impact level.

[0063] It is understood that the process of generating a fault code list in this application embodiment is as follows: First, the detection type and impact level of each fault code are extracted from the fault code list text. Then, based on the detection type and in conjunction with a pre-set list of processing strategies, the system-level processing strategy corresponding to the fault code is determined. The specific matching logic will be detailed later and will not be repeated here. At the same time, according to the impact level, the corresponding alarm prompt information is determined from the preset rules, that is, the alarm form for users or maintenance personnel, including dashboard icons such as red warning lights, text messages, sound prompts, or notifications pushed through a mobile APP. The presentation method and the urgency level correspond to the impact level. Finally, the determined processing strategy and alarm prompt information are integrated to generate a fault code list with a complete structure that can be directly used for ECU development and diagnostic systems. This ensures that each fault is not only accurately detected, but also triggers an appropriate system response and clear user feedback, thereby improving vehicle safety, compliance, and user experience.

[0064] In this embodiment of the application, determining the processing strategy for the fault code based on the detection type and the processing strategy list includes: determining the classification type of the fault code based on the detection type; and determining the processing strategy for the fault code based on the classification type and the processing strategy list.

[0065] The fault codes are classified into general types and hardware types. General types refer to fault types that do not depend on specific ECU hardware implementation and have commonalities across modules or platforms. They are usually related to system-level logic, communication protocols, or vehicle status, such as bus-related, safety-related, and vehicle battery-depleted faults. Bus-related faults include CAN communication loss and LIN timeout; safety-related faults include function monitoring timeout and watchdog reset; and vehicle battery-depleted faults include abnormal dormant current. Hardware-related faults refer to faults directly caused by the failure of internal or external hardware components of the ECU. Their detection and coding capabilities are highly dependent on specific circuit design, sensor and actuator selection, and chip support.

[0066] It is understood that, in the process of generating the fault code list in this application embodiment, the fault codes are first classified into general types or hardware types according to the detection type. The general type refers to fault categories that do not depend on specific ECU hardware and have commonalities across modules or platforms, covering bus-related faults (such as CAN communication loss, LIN timeout), safety-related faults (such as function monitoring timeout, watchdog reset), and vehicle-wide battery depletion faults (such as abnormal dormant current), mainly reflecting system-level logic or vehicle status problems. The hardware type refers to faults caused by the failure of specific hardware components (such as sensors, actuators, drive circuits, power management chips, etc.) inside or outside the ECU. The detection and coding capabilities of faults are highly dependent on the actual circuit design and component selection. Subsequently, based on the classification type, the corresponding standardized response rules are matched in the preset processing strategy list. For example, general fault types may uniformly adopt "record fault code + function degradation + alarm according to impact level", while critical hardware types may trigger "light up fault light + limit output + enter safe mode". Through this classification-driven strategy matching mechanism, the consistency and reusability of diagnostic logic are ensured, and the response behavior can be precisely configured according to hardware characteristics. Ultimately, it supports the generation of a fault code list that is clearly structured, comprehensive, and engineering-applicable.

[0067] In this embodiment of the application, determining the classification type of the fault code based on the detection type includes: obtaining a first correspondence table between the detection type and the classification type; and determining the classification type based on the detection type and the first correspondence table.

[0068] The first correspondence table is a predefined mapping table, usually existing in the form of a database or configuration file. It clearly lists the classification type corresponding to each detection type, including common fault detection types and their corresponding specific classification descriptions. It aims to provide a standardized classification basis for fault code design. Each detection type corresponds to a specific set of physical or logical fault scenarios. For example, "external electrical circuit fault detection" covers external signal abnormalities such as switches, sensors, drive outputs, and network interfaces; "voltage abnormality detection" includes overvoltage and undervoltage; "internal circuit fault detection" involves internal hardware problems such as memory, communication modules, and execution units; "system behavior inference fault" identifies system abnormalities that are not directly measurable through logical judgment; in addition, it can also include faults caused by configuration errors, signal mistransmission, environmental factors, or excessive static current. This table provides a structured detection type mapping for the whole vehicle diagnostic system, supports accurate matching from failure modes to fault code detection methods, and is an important foundation for achieving complete fault code coverage and unified management.

[0069] It is understood that the embodiments of this application accurately determine the classification type of fault codes through the following method: First, a predefined first correspondence table is obtained. This table exists in the form of a database or configuration file, and a mapping relationship between detection types (such as "CAN communication timeout", "sensor signal open circuit", "power supply undervoltage", etc.) and classification types (i.e., general type or hardware type) is systematically established. Subsequently, when processing each fault code, the system queries the first correspondence table according to its specific detection type, so as to accurately match and determine its classification type. For example, "LIN bus timeout" is mapped to the general type, while "high-side drive short circuit" is classified as the hardware type. This mechanism ensures the standardization, automation and traceability of the classification process, and lays a structured foundation for subsequent unified configuration processing strategies and alarm logic.

[0070] In this embodiment of the application, determining the alarm prompt information of the fault code based on the impact level includes: obtaining a second correspondence table between the impact level and the alarm prompt information; and determining the alarm prompt information based on the impact level and the second correspondence table.

[0071] It is understood that, in order to ensure the rationality and effectiveness of conveying fault information to users or maintenance personnel, this application embodiment needs to obtain a predefined second correspondence table. This table establishes a mapping rule between impact level and alarm prompt information in a structured form. When generating a fault code list, the system queries the second correspondence table according to the impact level associated with each fault code, and automatically determines the specific alarm prompt information that should be triggered, including the instrument panel indicator light type (such as a red warning light or a yellow warning light), the text message content (such as "Brake system failure, please check immediately"), whether to enable sound alarm, and whether to push notifications via remote APP, etc. This mechanism effectively avoids the problem of user panic caused by excessive alarms or safety hazards caused by insufficient alarms, realizes accurate fault prompt classification, standardized output and optimization of human-machine interaction experience, and improves after-sales diagnostic efficiency and vehicle intelligent service level.

[0072] like Figure 2 As shown in the embodiment of this application, when defining the fault code reporting strategy, the fault code list text is used as input. Combined with the general reporting strategy and hardware characteristics, a processing strategy (such as enabling conditions, alarm prompts, recovery mechanisms, etc.) for each fault code is formulated. Based on the unified diagnostic template of the car manufacturer, the final fault code list and the requirement specification including the reporting strategy are generated to guide ECU development and diagnostic database construction.

[0073] Specifically, using the fault code list text as input, and combining the vehicle manufacturer's defined general code reporting strategy (such as unified response rules for bus-related, safety-related, or power-related faults) with the specific hardware characteristics of each ECU (such as drive capability, sensor interface type, and diagnostic functions supported by the chip), a complete and refined processing strategy is formulated for each fault code in the list. This includes: enabling conditions (such as KL15 power-on, activation of detection when vehicle speed is greater than 5km / h), alarm prompting methods (such as illuminating a red warning light, displaying specific text information, triggering an audible alarm or APP push), and function degradation measures (such as disabling related functions or switching to redundant functions). The system includes fault code analysis, recovery mechanisms (such as automatic recovery after 10 consecutive normal cycles), and clearing strategies (such as supporting manual clearing with the diagnostic tool or not supporting automatic clearing). Based on this, and strictly following the unified diagnostic development templates and specifications of car manufacturers, the above strategies are structurally integrated to generate the final fault code list and the corresponding reporting strategy requirement specification document. This output can be directly used for ECU software development, test case generation, diagnostic database construction, and after-sales maintenance manual compilation, ensuring the consistency, compliance, and maintainability of diagnostic functions throughout the entire lifecycle, and effectively supporting accurate and efficient vehicle fault diagnosis and user service experience.

[0074] The fault code generation method and the proposed forward fault code design approach in this embodiment achieve a systematic diagnostic framework built from the perspective of vehicle functionality and driven by failure scenarios. This framework comprehensively covers all possible anomalies that may occur in real-world vehicle use, ensuring the completeness and relevance of fault codes. It effectively meets automakers' core requirements for diagnostic coverage, consistency, and manageability. This method abandons the traditional fragmented fault code definition model that relies on supplier experience, instead basing fault codes on vehicle-level functional failure analysis and directly associating them with user-perceptible fault phenomena. This significantly improves the after-sales service's ability to handle complex faults. The ability to quickly locate and troubleshoot root causes significantly improves repair efficiency and service quality. Simultaneously, by providing a standardized fault code list with a unified structure, complete attributes, and clear rules, along with supporting requirement specifications, this authoritative guidance document is distributed to all ECU suppliers. This mandates that they adhere to unified detection logic, reporting strategies, and classification rules during the development phase. This not only avoids redundancy, conflicts, or omissions but also fundamentally improves the correctness, rationality, and engineering feasibility of fault code design. It drives a high-quality leap in vehicle diagnostic capabilities from "passive response" to "proactive prevention and precise diagnosis," enhancing the correctness and rationality of fault code design.

[0075] In summary, this application embodiment obtains the configuration list text of the vehicle's functions, identifies the function implementation strategy of each system function from the configuration list text, performs failure analysis on the system functions based on the function implementation strategy to obtain an analysis report text, generates a fault code list text based on the analysis report text and a pre-set list of fault code detection types, and generates a fault code list based on the fault code list text and a pre-set list of fault code handling strategies. This achieves complete coverage of the vehicle's fault codes, enabling rapid location of the root cause of a fault when it occurs, thus improving after-sales maintenance efficiency and user experience.

[0076] Figure 4 This is a schematic diagram of a fault code generation device provided in an embodiment of this application.

[0077] For example, such as Figure 4 As shown, the device may include: an acquisition module 201, an analysis module 202, and a generation module 203.

[0078] The acquisition module 201 is used to acquire the configuration list text of the vehicle functions, which includes multiple system functions; the analysis module 202 is used to identify the function implementation strategy of each system function from the configuration list text, and perform failure analysis on the system functions based on the function implementation strategy to obtain the analysis report text; the generation module 203 is used to generate a fault code list of the vehicle functions based on the analysis report text.

[0079] In this embodiment of the application, the analysis module 202 is further configured to: analyze at least one functional failure scenario of the system function according to the functional implementation strategy; evaluate the functional failure mode of the system function under each functional failure scenario, and determine at least one of the requirement level, adaptation range and impact level of the fault code according to the functional failure mode.

[0080] In this embodiment, the generation module 203 is further configured to: obtain a pre-set list of detection types and a list of processing strategies; generate a fault code list text based on the analysis report text and the list of detection types; and generate a fault code list based on the fault code list text and the list of processing strategies.

[0081] In this embodiment of the application, the generation module 203 is further configured to: identify at least one of the demand level, scope of application, and impact level in the analysis report text; in response to a time when the demand level is greater than a preset demand threshold, determine the detection type of the fault code corresponding to the system function based on the scope of application and the detection type list; and generate a fault code list text based on the detection type and impact level.

[0082] In this embodiment of the application, the generation module 203 is further configured to: identify the fault codes corresponding to system functions within the adaptation range; query the list of fault code detection types using the fault codes as indexes; query the detection type of the fault code from the list of detection types; if no detection type is found, then respond to the user's interaction action and determine the detection type of the user-defined fault code based on the interaction action.

[0083] In this embodiment of the application, the generation module 203 is further configured to: identify the detection type and impact level of the fault codes in the fault code list text; determine the processing strategy of the fault codes according to the detection type and the processing strategy list; determine the alarm prompt information of the fault codes according to the impact level; and generate a fault code list according to the processing strategy and the alarm prompt information of the fault codes.

[0084] In this embodiment, the generation module 203 is further configured to: determine the classification type of the fault code based on the detection type; and determine the processing strategy for the fault code based on the classification type and the processing strategy list.

[0085] In this embodiment of the application, the generation module 203 is further configured to: obtain a first correspondence table between detection type and classification type; and determine the classification type based on the detection type and the first correspondence table.

[0086] In this embodiment of the application, the generation module 203 is further configured to: obtain a second correspondence table between the impact level and the alarm prompt information; and determine the alarm prompt information based on the impact level and the second correspondence table.

[0087] In summary, this application embodiment obtains the configuration list text of the vehicle's functions, identifies the function implementation strategy of each system function from the configuration list text, performs failure analysis on the system functions based on the function implementation strategy to obtain an analysis report text, generates a fault code list text based on the analysis report text and a pre-set list of fault code detection types, and generates a fault code list based on the fault code list text and a pre-set list of fault code handling strategies. This achieves complete coverage of the vehicle's fault codes, enabling rapid location of the root cause of a fault when it occurs, thus improving after-sales maintenance efficiency and user experience.

[0088] Figure 5 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 301, the processor 302, and the computer program stored on the memory 301 and capable of running on the processor 302.

[0089] When the processor 302 executes the program, it implements the fault code generation method provided in the above embodiments.

[0090] Furthermore, the vehicle also includes: Communication interface 303 is used for communication between memory 301 and processor 302.

[0091] The memory 301 is used to store computer programs that can run on the processor 302.

[0092] The memory 301 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0093] If the memory 301, processor 302, and communication interface 303 are implemented independently, then the communication interface 303, memory 301, and processor 302 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0094] Optionally, in a specific implementation, if the memory 301, processor 302, and communication interface 303 are integrated on a single chip, then the memory 301, processor 302, and communication interface 303 can communicate with each other through an internal interface.

[0095] Processor 302 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0096] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described fault code generation method.

[0097] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0098] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0099] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method of generating a fault code, the method comprising: The method comprises: obtaining a configuration list text of a whole vehicle function, the whole vehicle function comprising a plurality of system functions; identifying a function implementation strategy of each of the system functions from the configuration list text, performing failure analysis on the system functions based on the function implementation strategy to obtain an analysis report text; generating a fault code list of the whole vehicle function according to the analysis report text.

2. The failure code generation method according to claim 1, characterized by, The failure analysis on the system functions based on the function implementation strategy comprises: analyzing function failure scenarios of the system functions according to the function implementation strategy; evaluating function failure modes of the system functions under each of the function failure scenarios; determining at least one of a requirement level, an adaptation range and an influence level of a fault code according to the function failure modes.

3. The fault code generation method according to claim 1, wherein the generating of the fault code list of the whole vehicle function according to the analysis report text comprises: obtaining a pre-set detection type list and a processing strategy list; generating a fault code list text according to the analysis report text and the detection type list; generating the fault code list according to the fault code list text and the processing strategy list.

4. The fault code generation method of claim 3, wherein, The generating of the fault code list text according to the analysis report text and the detection type list comprises: identifying at least one of a requirement level, an adaptation range and an influence level in the analysis report text; in response to a moment when the requirement level is greater than a pre-set requirement threshold, determining a detection type of a fault code corresponding to the system function according to the adaptation range and the detection type list; generating the fault code list text according to the detection type and the influence level.

5. The fault code generation method of claim 4, wherein, The determining of the detection type of the fault code corresponding to the system function according to the adaptation range and the detection type list comprises: identifying the fault code corresponding to the system function in the adaptation range; querying a detection type list of the fault code with the fault code as an index; if the detection type is not queried, determining a detection type of the fault code customized by a user according to an interactive action of the user in response to the interactive action.

6. The fault code generation method of claim 3, wherein, The generating of the fault code list according to the fault code list text and the processing strategy list comprises: identifying a detection type and an influence level of a fault code in the fault code list text; determining a processing strategy of the fault code according to the detection type and the processing strategy list; determining alarm prompt information of the fault code according to the influence level, and generating the fault code list according to the processing strategy and the alarm prompt information.

7. The fault code generation method of claim 6, wherein, The determining of the processing strategy of the fault code according to the detection type and the processing strategy list comprises: determining a classification type of the fault code according to the detection type; determining the processing strategy of the fault code according to the classification type and the processing strategy list.

8. The fault code generation method of claim 7, wherein, The determining of the classification type of the fault code according to the detection type comprises: obtaining a first correspondence table of the detection type and the classification type; determining the classification type according to the detection type and the first correspondence table.

9. The fault code generation method of claim 6, wherein, The determining of the alarm prompt information of the fault code according to the influence level comprises: obtain a second correspondence table of the influence level and the alarm prompt information; determine the alarm prompt information according to the influence level and the second correspondence table.

10. A vehicle characterized by comprising: The vehicle comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor executes the program to realize fault diagnosis based on a fault code list, and the fault code list is generated based on the fault code generation method in any one of claims 1-9.

Images