Vehicle fault diagnosis methods, devices, controllers and vehicles
By synchronizing the fault table with the algorithm model in the fault diagnosis system for new energy vehicles, the problem of large code adjustment workload is solved, modular fault handling is realized, the workflow of adding and updating faults is simplified, and maintenance complexity and code volume are reduced.
Patent Information
- Application Number
- CN202510146591.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-10
- Publication Date
- 2025-10-28
- Estimated Expiration
- 2045-02-10
AI Technical Summary
Existing fault diagnosis systems for new energy vehicles involve a large workload of code adjustment and high maintenance complexity when adding or maintaining faults, making it difficult to achieve efficient processing and maintenance.
By synchronizing the fault table with the algorithm model, fault information is managed through the fault table, reducing the workload of code adjustment and realizing modular fault handling.
It simplifies the workflow for adding and updating faults, reduces maintenance complexity and code volume, and improves the efficiency and flexibility of fault diagnosis.
Smart Images

Figure CN119916787B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicles, and more particularly to a vehicle fault diagnosis method, device, controller, and vehicle. Background Technology
[0002] In new energy vehicles, the fault diagnosis system is a crucial component in ensuring the reliability and safety of the vehicle's controller. New energy vehicles employ multiple complex subsystems, including a battery management system, a motor control system, and an energy management system. The stability of these systems directly impacts the vehicle's operational performance and safety. By monitoring and analyzing the operational status of various vehicle components in real time, the fault diagnosis system can promptly identify potential faults and take corresponding countermeasures, thereby preventing major malfunctions and safety hazards.
[0003] Current fault diagnosis systems for new energy vehicles still face some challenges in achieving efficient handling and maintenance. Currently, a common approach is to design a separate algorithm model for each fault based on fault data tables, with one algorithm model for each fault. This approach involves a large amount of modeling work, and if a fault mode changes or a new fault is added, a significant amount of code needs to be modified and adjusted, greatly increasing the maintenance workload.
[0004] Therefore, designing fault diagnosis schemes to reduce the workload of code adjustments when adding or maintaining faults is particularly important. Summary of the Invention
[0005] This application provides a vehicle fault diagnosis method, device, controller, and vehicle to synchronize the fault table with the algorithm model, thereby reducing the workload of code adjustment when adding or maintaining faults.
[0006] In a first aspect, this application provides a vehicle fault diagnosis method, the method comprising:
[0007] A pre-defined fault table is loaded into the data processing environment; wherein, the fault table includes a fault identifier, fault confirmation conditions, fault confirmation time, and fault details for each fault.
[0008] Obtain the fault identifier and fault set identifier of the subsystem controller;
[0009] Based on the fault identifier, determine the target fault confirmation conditions and the target fault confirmation time from the fault table;
[0010] If the vehicle meets the target fault determination conditions, and the duration of the fault setting flag is greater than the target fault confirmation time, then the vehicle is confirmed to have a fault.
[0011] Based on the fault identifier, the target fault details are determined from the fault table. The target fault details include fault location, fault type, fault light status, and fault activation status.
[0012] Output the target fault information.
[0013] Optionally, the fault table may also include fault degradation measures corresponding to each fault, and the method may further include:
[0014] Based on the fault identifier, determine the fault degradation measures from the fault table;
[0015] Implement the aforementioned fault degradation measures.
[0016] Optionally, the fault degradation measures include fault levels, and the method further includes:
[0017] Obtain the single-failure level of the subsystem controller;
[0018] The maximum value of the fault level and the single-shot fault level is taken as the target fault level;
[0019] Output the target fault level.
[0020] Optionally, outputting the target fault information includes:
[0021] If the fault activation status indicates fault activation, or the fault setting flag indicates fault triggering, the output of the target fault information will be triggered.
[0022] Optionally, the fault table may also include the fault recovery time for each fault, and the method may further include:
[0023] The target fault recovery time is determined based on the fault identifier;
[0024] Accordingly, confirming a vehicle malfunction if the vehicle meets the target fault determination conditions and the duration of the fault setting flag is greater than the target fault confirmation time includes:
[0025] If the vehicle meets the target fault determination conditions, and the duration of the fault setting indicator is greater than the target fault confirmation time, then it is determined whether the fault setting indicator returns to a non-fault state within the target fault recovery time.
[0026] If the fault setting indicator does not return to a non-fault state, then a vehicle malfunction is confirmed.
[0027] Optionally, the fault confirmation condition in the fault table is a fault confirmation condition mask, the fault confirmation time is a fault confirmation time mask, the fault recovery time is a fault recovery time mask, and the fault details include a fault type SPN mask and a fault mode and location FMI mask.
[0028] Optionally, the method further includes:
[0029] Obtain a new fault table, which includes a new fault identifier, new fault confirmation conditions, new fault confirmation time, and new fault details.
[0030] The new fault table is loaded into the data processing environment to replace the fault table.
[0031] Secondly, this application provides a vehicle fault diagnosis device, the device comprising:
[0032] The loading module is used to load a preset fault table into the data processing environment; wherein, the fault table includes a fault identifier, fault confirmation conditions, fault confirmation time and fault details for each fault.
[0033] The fault input module is used to obtain the fault identifier and fault set identifier of the subsystem controller;
[0034] The fault confirmation condition module is used to determine the target fault confirmation condition and the target fault confirmation time from the fault table based on the fault identifier.
[0035] The fault confirmation module is used to confirm that the vehicle has a fault if the vehicle meets the target fault determination conditions and the duration of the fault setting flag is greater than the target fault confirmation time.
[0036] The fault polling module is used to determine the detailed information of the target fault from the fault table based on the fault identifier. The detailed information of the target fault includes the fault location, fault type, fault light status and fault activation status.
[0037] The fault output module is used to output the target fault information.
[0038] Thirdly, this application provides a controller, including: a memory and a processor;
[0039] The memory stores computer-executed instructions;
[0040] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the first aspects.
[0041] Fourthly, this application provides a vehicle including a controller for performing the method as described in any of the first aspects.
[0042] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.
[0043] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0044] This application provides a vehicle fault diagnosis method, device, controller, and vehicle. The method includes: loading a preset fault table into a data processing environment, verifying fault confirmation conditions and confirmation time; after confirming the fault, obtaining detailed fault information from the fault table, and finally outputting the fault information. Fault information is centralized in a fault table, rather than being directly hard-coded into the control algorithm, making the entire fault handling process modular and easily scalable. The vehicle's controller can obtain and process fault information by reading this table without modifying the control algorithm or code each time. The controller also does not need to develop a separate processing model for each fault; it only needs to extract relevant information from the fault table through fault identifiers. Therefore, by managing faults in a table format, the modeling workload and code volume of the vehicle controller in fault signal processing are reduced, the work of adding and updating faults is simplified, and the complexity and workload of maintenance are significantly reduced. Attached Figure Description
[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0046] Figure 1 Flowchart of the vehicle fault diagnosis method provided in this application Figure 1 ;
[0047] Figure 2 Flowchart of the vehicle fault diagnosis method provided in this application Figure 2 ;
[0048] Figure 3 This application provides a schematic diagram of the structure of a vehicle fault diagnosis device.
[0049] Figure 4 A schematic diagram of the structure of the electronic device provided in this application.
[0050] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation
[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0052] Fault diagnosis in new energy sources is a key focus in controller development. Existing fault handling algorithms in controllers become increasingly complex as the number of faults grows, leading to increased model and code complexity and making later maintenance more difficult. Therefore, establishing modular fault model algorithms is crucial, as modular fault algorithms simplify later fault maintenance and additions.
[0053] In view of the above problems, this application provides a vehicle fault diagnosis method. First, a fixed-format fault data table is designed. New faults are added, and the fault table is updated or modified accordingly. The fault table is linked to the algorithm model through a data dictionary. The algorithm model is modularized. The fault input module reads faults in real time, performs fault parsing, and outputs fault identifiers and fault setting flags (flg). The fault confirmation module polls the contents of the fault table (fault confirmation condition mask, fault confirmation time mask, fault recovery time mask) based on the fault number to parse out the fault confirmation conditions, fault confirmation time, and fault recovery time. The current vehicle status is compared with the fault confirmation conditions corresponding to the fault number. If the conditions are met, the fault confirmation time and fault recovery time are confirmed to arrive at the final confirmed fault. For confirmed faults, the fault number and fault setting flag (flg) are stored in an array. The fault polling module polls the confirmed fault number and fault setting flag (flg) storage array in real time to parse out the fault number and fault setting flag, polls the fault table in real time, and outputs fault information. Through this method, the fault table and algorithm model are linked. Adding maintenance faults and modifying the fault table can be synchronized with the model, significantly reducing workload.
[0054] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.
[0055] Figure 1Flowchart of the vehicle fault diagnosis method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:
[0056] S101. Load the preset fault table into the data processing environment; wherein, the fault table includes the fault identifier, fault confirmation conditions, fault confirmation time and fault details for each fault.
[0057] In this step, the fault table data is read into the data processing environment each time the vehicle is powered on. The data processing environment can be the MATLAB workspace, the memory of the embedded controller, or other suitable runtime environment.
[0058] Each fault entry in the fault table includes:
[0059] Fault identifier: Used to uniquely identify each fault.
[0060] Fault confirmation conditions: Conditions used to determine whether a fault has occurred.
[0061] Fault confirmation time: The time required after a fault occurs to confirm the fault.
[0062] Detailed fault information: Specific information about when the fault occurred, including the location and type of the fault.
[0063] The fault table can be modified, for example, by changing the confirmation time of certain faults or the details, or by adding fault entries.
[0064] Optionally, the fault confirmation conditions, fault confirmation times, and other queryable fault confirmation criteria in the fault table can all be represented using a mask for easy querying.
[0065] S102. Obtain the fault identifier and fault setting identifier of the subsystem controller.
[0066] Subsystem controllers comprise various modules within the vehicle (such as the battery management system and drive controller), each independently detecting and marking fault states. The subsystem controllers transmit fault identifiers and fault set identifiers to the vehicle controller via communication protocols (such as the CAN bus). The vehicle controller monitors these identifiers in real time to respond when a fault occurs.
[0067] S103. Determine the target fault confirmation conditions and target fault confirmation time from the fault table based on the fault identifier.
[0068] Based on the obtained fault identifier, find the corresponding fault confirmation conditions and fault confirmation time from the fault table. The fault confirmation conditions are combinations of vehicle OFF state, vehicle ON state, vehicle Ready state, vehicle speed <5, and vehicle charging; different faults correspond to different combinations. The fault confirmation time refers to the time required to maintain this state after the fault occurs.
[0069] S104. If the vehicle meets the target fault determination conditions and the duration of the fault setting flag is greater than the target fault confirmation time, then the vehicle is confirmed to have a fault.
[0070] Real-time monitoring of fault indicators and fault set indicators, recording their duration. Acquiring the vehicle's actual status and comparing it with the target fault confirmation criteria. If the target fault confirmation criteria are met, and the fault indicator's duration exceeds the target fault confirmation time, then the fault is confirmed as a genuine fault.
[0071] S105. Determine the detailed information of the target fault from the fault table based on the fault identifier. The detailed information of the target fault includes the fault location, fault type, fault light status, and fault activation status.
[0072] From the fault table, find the detailed information about the fault based on the fault identifier. This typically includes:
[0073] Fault location: Indicate the location where the fault occurred (e.g., battery module, drive motor, etc.).
[0074] Fault type: Describes the nature of the fault, such as electrical fault, mechanical fault, etc.
[0075] Warning light status: Indicates whether the warning light on the instrument panel is illuminated, used to alert the driver.
[0076] Fault activation status: Indicates whether the fault has been activated and determines whether to trigger related protection measures.
[0077] S106, Output target fault information.
[0078] If a fault is confirmed, the target fault information is output. The vehicle controller can feed back the fault information to the driver through the vehicle display system, displaying the fault code, location, type, etc.; it can also send the fault information to external diagnostic equipment for viewing and analysis via the OBD interface.
[0079] The vehicle fault diagnosis method provided in this embodiment includes loading a fault table, real-time monitoring of fault identifiers, verification of fault confirmation conditions and confirmation time, acquisition of detailed fault information, and final output of fault information. By centralizing fault information in a fault table instead of hard-coding it directly into the control algorithm, the entire fault handling process becomes modular and easily extensible. The vehicle's controller can acquire and process fault information by reading this table without modifying the control algorithm or code each time. The controller also does not need to develop a separate processing model for each fault; it only needs to extract relevant information from the fault table using the fault identifier.
[0080] Therefore, by managing faults in a tabular format, not only can the modeling workload and code volume of the vehicle controller in fault signal processing be reduced, but the problem of asynchronous fault table maintenance and algorithm model can also be effectively solved. The table-driven approach simplifies the work of adding and updating faults, significantly reducing the complexity and workload of maintenance.
[0081] After outputting the target fault information, corresponding countermeasures can be automatically executed based on that information. The fault table also includes fault degradation measures for each fault, such as limiting motor speed and power after the motor temperature becomes too high. Fault degradation measures are determined from the fault table based on the fault identifier and then executed.
[0082] If a user modifies the fault table (either by adding a fault or modifying a fault), the controller needs to obtain the new fault table. The new fault table includes new fault identifiers, new fault confirmation conditions, new fault confirmation times, and new detailed fault information. The new fault table is then loaded into the data processing environment to replace the original fault table. This achieves synchronized operation between the table and the fault confirmation algorithm model.
[0083] The following examples illustrate the fault diagnosis methods.
[0084] 1) Design a data dictionary format based on Microsoft Excel (.xls). According to this method, the attributes of data objects are collected and organized into an Excel workbook (with the .xls extension) according to a predefined pattern. This file can then be used as a general interface and delivery for modeling, software integration, and calibration.
[0085] A data dictionary is a tool for defining, describing, and managing data; it stores and manages information such as data structure, data types, field meanings, and data constraints. The data dictionary records the definitions, structure, and constraints of each data element in the system. When table content changes (e.g., modifying field types, field names, or adding new fields), the data dictionary is updated accordingly to maintain accurate data description and consistency.
[0086] In addition, the data dictionary associates specific information about each fault (such as fault description, fault classification, triggering conditions, etc.) with the corresponding algorithm model. Each fault's unique identifier (such as fault ID) has a corresponding entry in the data dictionary, pointing to the associated algorithm module. In this way, every fault record in the fault table can find its corresponding algorithm processing module through the data dictionary.
[0087] When the fault table changes (e.g., fault items are added or modified), the data dictionary ensures that the new fault is automatically associated with the corresponding algorithm. This way, developers don't need to manually modify the relevant parts of the code; they only need to update the fault table and the data dictionary.
[0088] For example, if a new fault is added (such as "Battery overtemperature"), you only need to add the fault information to the fault table and associate it with an appropriate algorithm model in the data dictionary. The algorithm model will automatically adapt to the new fault.
[0089] In one implementation, each table, column in the database, or data structure in the API can be listed in detail in the data dictionary in tabular form.
[0090] For example, in a tabular data dictionary, the field "user_id" might be defined as an integer (int), with a length of 10, and cannot be empty. When requirements change, it might be changed to a "floating type," and the corresponding algorithm can be associated with the floating type algorithm.
[0091] 2) Fault Table: Contains 3 worksheets (MEASURE, CALIBRATION, MAP_DATA). MAP_DATA is a hyperlink in the CALIBRATION table, which defines the fault association attributes in detail.
[0092] 3) Fault Table Layout. The key names for the worksheets include MEASURE, CALIBRATION, and a separate worksheet named MAP_DATA for storing multidimensional MAP data. The MEASURE worksheet contains fault handling-related observations, the CALIBRATION worksheet contains fault handling-related calibration data, and the MAP_DATA worksheet contains hyperlinks to multidimensional calibration data within the CALIBRATION worksheet.
[0093] 4) Fault Table MAP_DATA Worksheet Data Arrangement. The data includes a header row and the following data. The keywords in the header row include: Fault Confirmation Condition Mask, Fault Confirmation Time Mask, Fault Recovery Time Mask, DM1_SPN Mask, DM1_FMI Mask, Fault Degradation Measures Mask, Fault Description, Fault Number, Fault Classification, Fault Confirmation Conditions (Vehicle OFF, Vehicle ON, Vehicle Ready, Vehicle Speed <5, Vehicle Charging), J1939DM1 (SPN, FMI, CM, LED, SaveFlg, Protection, Active), Fault Degradation Measures (Fault Level, Fast Power Down HV_Fa (The following are the parameters: stOff_Req, HV_NormalOff_Req, PwrReduce_pct, VehSpdLim_Open, VehSpdLim_kpd, Disregen_Req, DisDCDC_Req, DisOilPump_Req, DisAirPump_Req, DisAC_Req, DisPTC_Req, DisChrg_Req). Keywords are used to identify the title lines. The item before the fault description keyword is data dictionary content associated with the algorithm model, and the content after is comments for technical or related personnel to understand and use.
[0094] 5) Read the fault table data into the MATLAB workspace. Create a SeatTest.Parameter or SeatTest.Signal data object in the MATLAB workspace, and call the create_seat_parameter.m or create_seat_signal.m file through the script read_DD_xls.m.
[0095] 6) Fault Algorithm: 4 independent modules, namely fault confirmation condition module, fault confirmation module, fault polling module, and fault input / output module.
[0096] 7) Fault Polling Module. After receiving a fault confirmed by the fault confirmation module, this module polls the fault storage array in real time, parsing and outputting the fault sequence number and fault flag flg. These two values are fed into the J1939DM1 module. Based on the sequence number, it polls the corresponding DM1_SPN mask and DM1_FMI mask in the fault table, parsing out J1939DM1 (fault component or system number SPN, fault mode FMI, whether the fault is a conditional monitoring type CM, fault indicator LED status, whether to save fault information SaveFlg, fault priority Protect, and fault activation status Active). Active and fault flag flg are combined, meaning that if either the Active status or either the fault flag flg is "1", indicating fault activation, the fault is considered activated or triggered. The fault flag triggers the output of DM1 fault information. Two values are entered into the fault degradation measure module. Based on the sequence number, the corresponding fault degradation measure mask in the fault table is read in a round-robin fashion. The fault degradation measures are parsed out (fault level FaultLeve, fast power-off HV_FastOff_Req, normal power-off HV_NormalOff_Req, drive power reduction PwrReduce_pct, speed limit enable VehSpdLim_Open, speed limit value VehSpdLim_kpd, energy recovery off DisRegen_Req, DC-DC off operation DisDCDC_Req, oil pump off operation DisOilPump_Req, air pump off operation DisAirPump_Req, air conditioning off operation DisAC_Req, heating off operation DisPTC_Req, charging off DisChrg_Req). Each degradation measure item is calculated with the initial design value (MAX, or set), triggering confirmation of the fault degradation measure array storage (the order of degradation measure items is fixed).
[0097] Figure 2 Flowchart of the vehicle fault diagnosis method provided in this application Figure 2 ,like Figure 2 As shown, it includes the following steps:
[0098] S201, Fault Input.
[0099] Obtain fault identifiers from external interfaces. Fault identifiers can be SPN codes, FMI codes, etc., sent by the sub-controller system.
[0100] S202, Fault Analysis.
[0101] Based on the input fault identifier, the fault number in the fault table can be determined. This fault number is unique in the table and is the leftmost entry number in the table.
[0102] S203. Determine the fault confirmation condition mask from the fault table based on the fault number.
[0103] The fault confirmation condition mask is retrieved from the fault table by fault number. The fault confirmation condition mask is used to confirm whether the triggering requirements for the fault have been met.
[0104] For example, the fault confirmation conditions for each fault entry include the following five states: vehicle OFF, vehicle ON, vehicle Ready, vehicle speed <5, and vehicle charging status. Each state can be represented by 1 or 0. If it is 1, it means that the fault can only be triggered when this condition is activated; if it is 0, it means that this condition is not required to activate. The fault confirmation condition mask is a mask determined based on the combination of the five states. Different combinations form different masks, and the specific relationship is not limited. In practical applications, it is not necessary to obtain the five states one by one; it is sufficient to directly obtain the fault condition mask, which represents the combination of the five states.
[0105] Similarly, not only are the fault confirmation conditions represented in the form of a mask, but the fault confirmation time is represented by the fault confirmation time mask, the fault recovery time by the fault recovery time mask, and the fault details include the fault type SPN mask and the fault mode and location FMI mask.
[0106] S204. Determine whether the current vehicle status meets the fault confirmation conditions.
[0107] By obtaining the vehicle's current status and using the same mask association, the vehicle's current fault confirmation condition mask can be determined and compared with the fault confirmation condition mask determined from the fault table. If they are the same, it means that the fault confirmation condition is met.
[0108] S205. Combine the confirmed fault number and the fault setting flg.
[0109] S206. Query the fault confirmation time from the fault table and determine whether the fault duration meets the fault confirmation time.
[0110] If the fault persists within the fault confirmation time, it means that the fault continues.
[0111] S207. Query the fault recovery time from the fault table to determine whether the fault has been recovered within the fault recovery time.
[0112] Some faults are automatically recoverable and have a default fault recovery time. It is necessary to determine whether the fault has been recovered within the fault recovery time. If it has been recovered, no further steps are required.
[0113] S208. Confirm the fault and store the fault number and fault setting flag in an array.
[0114] At this point, it is determined that the vehicle has malfunctioned and cannot be automatically recovered. The fault number and fault setting flag are then stored in the fault storage array, indicating that the fault has been confirmed.
[0115] S209. Poll and parse the storage array, and parse the SPN mask and FMI mask from the fault table according to the fault number.
[0116] Parse J1939DM1 (part or system number SPN of the fault, fault mode FMI, whether the fault is a condition monitoring type CM, fault indicator LED status, whether to save fault information SaveFlg, fault priority Protity, fault activation status Active).
[0117] S210, the union of the fault's active state (Active) and the fault's set state (flg).
[0118] Perform a union operation on the fault's active state (Active) and the fault's set flag (flg). If either flag is "1", it indicates that the fault has been activated.
[0119] S211, Trigger fault information output.
[0120] If a fault has been activated, fault information is output, such as displaying the fault type and location on the screen, for further processing.
[0121] S212. Based on the fault sequence number, poll the table to parse the fault degradation measure mask.
[0122] The fault degradation measure mask includes the status of various parameters such as fault level (FaultLeve), fast power-off (HV_FastOff_Req), normal power-off (HV_NormalOff_Req), reduced drive power (PwrReduce_pct), speed limit enable (VehSpdLim_Open), speed limit value (VehSpdLim_kpd), energy recovery off (DisRegen_Req), DC-DC off operation (DisDCDC_Req), oil pump off operation (DisOilPump_Req), air pump off operation (DisAirPump_Req), air conditioning off operation (DisAC_Req), heating off operation (DisPTC_Req), and charging off (DisChrg_Req).
[0123] Different faults and different fault levels require different degradation measures, which need to be specifically configured by the developers.
[0124] S213. Compare each degradation measure item with the initial design value and take the maximum value of the degradation measure.
[0125] S214. Confirm the storage of the fault degradation measures array.
[0126] S215. Read the single-fault level information of each subsystem controller.
[0127] When the subsystem controller sends the fault identifier and fault set flag, it also sends its own determined single-fault level information.
[0128] S216. Read the fault degradation measures array and parse the fault level information.
[0129] S217. Take the maximum value of the two fault levels.
[0130] A secondary verification is performed by comparing the fault level information obtained from parsing with the fault level information received from the sub-controller to prevent parsing errors or controller errors.
[0131] S218, Output the highest fault level information.
[0132] The determined fault level information is displayed on the vehicle's monitor.
[0133] S219. Read and confirm the output of the fault degradation measures array.
[0134] With this technical solution, fault information is synchronized to the algorithm model through a fault table management system, and polled in real time. Every fault input is processed, and the algorithm model is modular, simple in design, and requires little code.
[0135] Figure 3 This is a schematic diagram of the structure of a vehicle fault diagnosis device provided in this application, as shown below. Figure 3 As shown, the vehicle fault diagnosis device 30 includes:
[0136] The loading module 301 is used to load a preset fault table into the data processing environment; wherein, the fault table includes a fault identifier, fault confirmation conditions, fault confirmation time and fault details for each fault.
[0137] The fault input module 302 is used to obtain the fault identifier and fault set identifier of the subsystem controller;
[0138] The fault confirmation condition module 303 is used to determine the target fault confirmation condition and the target fault confirmation time from the fault table based on the fault identifier.
[0139] The fault confirmation module 304 is used to confirm that the vehicle has a fault if the vehicle meets the target fault determination conditions and the duration of the fault setting flag is greater than the target fault confirmation time.
[0140] The fault polling module 305 is used to determine the detailed information of the target fault from the fault table according to the fault identifier. The detailed information of the target fault includes the fault location, fault type, fault light status and fault activation status.
[0141] The fault output module 306 is used to output the target fault information.
[0142] Optionally, the fault table also includes fault degradation measures corresponding to each fault, and the fault output module 306 is further used for:
[0143] Based on the fault identifier, determine the fault degradation measures from the fault table;
[0144] Implement the aforementioned fault degradation measures.
[0145] Optionally, the fault degradation measures include fault levels, and the fault output module 306 is further configured to:
[0146] Obtain the single-failure level of the subsystem controller;
[0147] The maximum value of the fault level and the single-shot fault level is taken as the target fault level;
[0148] Output the target fault level.
[0149] Optionally, the fault output module 306 is further configured to:
[0150] If the fault activation status indicates fault activation, or the fault setting flag indicates fault triggering, the output of the target fault information will be triggered.
[0151] Optionally, the fault table also includes the fault recovery time for each fault, and the fault confirmation condition module 303 is further used for:
[0152] The target fault recovery time is determined based on the fault identifier;
[0153] Accordingly, the fault confirmation module 304 is specifically used for:
[0154] If the vehicle meets the target fault determination conditions, and the duration of the fault setting indicator is greater than the target fault confirmation time, then it is determined whether the fault setting indicator returns to a non-fault state within the target fault recovery time.
[0155] If the fault setting indicator does not return to a non-fault state, then a vehicle malfunction is confirmed.
[0156] Optionally, the fault confirmation condition in the fault table is a fault confirmation condition mask, the fault confirmation time is a fault confirmation time mask, the fault recovery time is a fault recovery time mask, and the fault details include a fault type SPN mask and a fault mode and location FMI mask.
[0157] Optionally, the loading module 301 is further configured to:
[0158] Obtain a new fault table, which includes a new fault identifier, new fault confirmation conditions, new fault confirmation time, and new fault details.
[0159] The new fault table is loaded into the data processing environment to replace the fault table.
[0160] The vehicle fault diagnosis device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0161] Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application, which may be a vehicle controller. Figure 4 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.
[0162] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.
[0163] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0164] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0165] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0166] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0167] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0168] This application also provides a vehicle including a vehicle controller, which is capable of implementing the methods described in the above embodiments.
[0169] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.
[0170] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0171] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0172] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0173] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0174] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0175] If a function is implemented as 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 this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0176] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0177] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A vehicle fault diagnosis method, characterized in that, The method comprises: A pre-defined fault table is loaded into the data processing environment; wherein, the fault table includes a fault identifier for each fault, fault confirmation conditions, fault confirmation time, fault details, fault recovery time, and fault degradation measures, and the fault table is associated with the algorithm model through a data dictionary, which is used to establish an association between the fields in the fault table and the algorithms in the algorithm model; Obtain the fault identifier and fault set identifier of the subsystem controller; The following steps are performed using the algorithm model: Based on the fault identifier, determine the target fault confirmation conditions and the target fault confirmation time from the fault table; The target fault recovery time is determined from the fault table based on the fault identifier; If the vehicle meets the target fault determination conditions, and the duration of the fault setting indicator is greater than the target fault confirmation time, then it is determined whether the fault setting indicator returns to a non-fault state within the target fault recovery time. If the fault setting indicator does not return to a non-fault state, a vehicle fault is confirmed; based on the fault indicator, the target fault details are determined from the fault table, including the fault location, fault type, fault light status, and fault activation status. Output the target fault information; Based on the fault identifier, determine the fault degradation measures from the fault table; Implement the aforementioned fault degradation measures.
2. The method according to claim 1, characterized in that, The fault degradation measures include fault levels, and the method further includes: Obtain the single-failure level of the subsystem controller; The maximum value of the fault level and the single-shot fault level is taken as the target fault level; Output the target fault level.
3. The method according to claim 1 or 2, characterized in that, The output of the target fault information includes: If the fault activation status indicates fault activation, or the fault setting flag indicates fault triggering, the output of the target fault information will be triggered.
4. The method according to claim 1 or 2, characterized in that, The fault table contains a fault confirmation condition mask, a fault confirmation time mask, a fault recovery time mask, and detailed fault information including a fault type (SPN) mask and a fault mode and location (FMI) mask.
5. The method according to claim 1 or 2, characterized in that, The method further includes: Obtain a new fault table, which includes a new fault identifier, new fault confirmation conditions, new fault confirmation time, and new fault details. The new fault table is loaded into the data processing environment to replace the fault table.
6. A vehicle fault diagnosis device, characterized in that, The device includes: A loading module is used to load a preset fault table into the data processing environment; wherein, the fault table includes a fault identifier for each fault, fault confirmation conditions, fault confirmation time, fault details, fault recovery time, and fault degradation measures; the fault table is associated with the algorithm model through a data dictionary, and the data dictionary is used to establish an association between the fields in the fault table and the algorithms in the algorithm model. The fault input module is used to obtain the fault identifier and fault set identifier of the subsystem controller; The fault confirmation condition module is used to determine the target fault confirmation condition and the target fault confirmation time from the fault table based on the fault identifier. The fault confirmation module is used for: If the vehicle meets the target fault determination conditions, and the duration of the fault setting indicator is greater than the target fault confirmation time, then it is determined whether the fault setting indicator returns to a non-fault state within the target fault recovery time. If the fault setting indicator does not return to a non-fault state, then a vehicle fault is confirmed. The fault polling module is used to determine the detailed information of the target fault from the fault table based on the fault identifier. The detailed information of the target fault includes the fault location, fault type, fault light status and fault activation status. The fault output module is used to output the target fault information; The fault output module is also used for: Based on the fault identifier, determine the fault degradation measures from the fault table; Implement the aforementioned fault degradation measures.
7. A controller, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-5.
8. A vehicle, characterized in that, Includes a controller for performing the method as described in any one of claims 1-5.
Citation Information
Patent Citations
Intermittent fault detection and reasoning
US20100082197A1
Failure prediction system
US20230147470A1