A vehicle failure strategy design system and determination method
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA FAW CO LTD
- Filing Date
- 2023-06-30
- Publication Date
- 2026-06-09
Smart Images
Figure CN117452906B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle diagnostic technology, and in particular to a vehicle fault strategy design system and determination method. Background Technology
[0002] As cars become increasingly intelligent and their functions become more complex, the requirements for the capabilities and coordination of vehicle controllers also increase, leading to the emergence of domain controllers.
[0003] Domain controllers integrate the functions of multiple controllers into a single controller. As the functions become more complex, troubleshooting becomes increasingly difficult. To address this issue, gateway controllers record all CAN (Controller Area Network) bus messages from different paths. This allows for troubleshooting when problems occur, or by diagnosing all vehicle controllers, faults and their causes can be identified.
[0004] The above solution addresses the increasingly complex problem of troubleshooting, requiring significant time to analyze and troubleshoot CAN bus messages. Acquiring all messages places high demands on the gateway's large cache and short storage time. As functionality increases and data volume grows, the gateway's data storage will be insufficient. Diagnosing all controllers in the vehicle requires considerable time and cost, resulting in low vehicle diagnostic efficiency. Summary of the Invention
[0005] This invention provides a vehicle fault strategy design system and determination method, which solves the problems of high difficulty and low efficiency in vehicle fault diagnosis caused by the increasing complexity of vehicle functions by designing a whole vehicle fault strategy.
[0006] According to one aspect of the present invention, a vehicle fault diagnosis strategy design system is provided, comprising:
[0007] The first device is used to acquire vehicle equipment data and software function data, and to determine vehicle functional scenario data based on the vehicle equipment data and software function data; wherein, the functional scenario data includes vehicle function definitions and vehicle function implementation processes;
[0008] The second device is used to determine functional requirement data based on functional scenario data;
[0009] The third device is used to perform functional feasibility analysis based on functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and to determine diagnostic feasibility analysis result data based on diagnostic feasibility analysis requirement data and actual vehicle operation data.
[0010] The fourth device is used to determine the initial fault strategy based on the results of the diagnostic feasibility analysis.
[0011] The third device is also used to transmit the diagnostic feasibility analysis results to the domain controller software test model for fault analysis and to determine the domain controller fault strategy; based on the domain controller fault strategy and the initial fault strategy, it performs fault verification to determine the target fault strategy.
[0012] Optionally, vehicle equipment data includes vehicle equipment and functional information of the vehicle equipment, including domain controllers;
[0013] The first device is specifically used for:
[0014] The corresponding software function data for each vehicle device is determined by matching the functional information and software function data of each device.
[0015] Optionally, the second device is specifically used for:
[0016] Obtain the control policy of the domain controller;
[0017] Functional requirement data is determined based on the control strategy and functional scenario data of the domain controller.
[0018] Optionally, the third device is specifically used for:
[0019] Based on the functional requirements data, a feasibility analysis was conducted on each function according to the diagnostic dimensions to obtain the diagnostic feasibility analysis requirements data for each function. The diagnostic dimensions include inability to start, inability to stop, inability to execute, output exceeding limits, and uncontrollable task behavior.
[0020] Optionally, the third device is specifically used for:
[0021] Obtain actual vehicle operating data;
[0022] Based on the diagnostic feasibility analysis requirements data and the actual vehicle operation data, the fault name and its failure information are determined, and the diagnostic feasibility analysis result data is obtained.
[0023] Optionally, the third device is also used for:
[0024] Before determining the target fault strategy, a test coverage assessment is performed on the domain controller fault coverage of the domain controller fault strategy to determine the domain controller fault strategy that meets the test requirements; fault points in the domain controller fault strategy that meets the test requirements are embedded to identify and capture fault problems during vehicle function operation.
[0025] Optionally, the fourth device is also used to determine controller software data based on the target fault strategy;
[0026] The system also includes: a fifth device;
[0027] The fifth device is used to determine test report data based on diagnostic feasibility analysis results, target fault strategies, and controller software data.
[0028] Optionally, a second device is used to acquire electrical equipment data of the vehicle, including system association block diagram, wiring harness schematic diagram, and electrical attribute table;
[0029] The third device is used to construct a fault failure model based on the target fault strategy and electrical equipment data. The fault failure model is a model that represents the relationship between hardware, software and functions. The fault failure model is combined with a data analysis engine to determine the vehicle fault problem. The fault problem is sent to the after-sales diagnostic instrument, which is used to display the fault problem and feed it back to the fault failure model to update the fault failure model.
[0030] According to another aspect of the present invention, a method for determining a vehicle fault strategy is provided, comprising:
[0031] The vehicle equipment data and software function data are acquired through the first device, and the vehicle's functional scenario data is determined based on the vehicle equipment data and software function data; wherein, the functional scenario data includes the vehicle function definition and the vehicle function implementation process;
[0032] The functional requirement data is determined by the second device based on the functional scenario data;
[0033] The third device performs a functional feasibility analysis based on functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and determines diagnostic feasibility analysis result data based on diagnostic feasibility analysis requirement data and actual vehicle operation data.
[0034] The initial fault strategy is determined by the fourth device based on the results of the diagnostic feasibility analysis.
[0035] The diagnostic feasibility analysis results are transmitted to the domain controller software test model via a third device for fault analysis to determine the domain controller fault strategy. Based on the domain controller fault strategy and the initial fault strategy, fault verification is performed to determine the target fault strategy.
[0036] Optionally, the diagnostic feasibility analysis results data are determined based on the diagnostic feasibility analysis requirements data and the actual vehicle operation data, including:
[0037] Obtain actual vehicle operating data;
[0038] Based on the diagnostic feasibility analysis requirements data and the actual vehicle operation data, the fault name and its failure information are determined, and the diagnostic feasibility analysis result data is obtained.
[0039] The technical solution of this invention involves acquiring vehicle equipment data and software function data using a first device, and determining vehicle functional scenario data based on these data; determining functional requirement data based on the functional scenario data using a second device; performing functional feasibility analysis based on the functional requirement data using a third device to obtain diagnostic feasibility analysis requirement data for vehicle functions; determining diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and actual vehicle operation data; determining an initial fault strategy based on the diagnostic feasibility analysis result data using a fourth device; transmitting the diagnostic feasibility analysis result data to a domain controller software test model for fault analysis to determine a domain controller fault strategy; and performing fault verification based on the domain controller fault strategy and the initial fault strategy to determine a target fault strategy. This achieves the function of designing vehicle fault strategies, enabling rapid troubleshooting of fault causes for different functional scenarios. It solves the problem of high difficulty and low efficiency in vehicle fault troubleshooting caused by increasingly complex vehicle functions, thus improving the efficiency of vehicle fault diagnosis.
[0040] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0042] Figure 1 This is a schematic diagram of the structure of a vehicle fault strategy design system provided in Embodiment 1 of the present invention;
[0043] Figure 2 This is a flowchart of a vehicle fault strategy design system applicable to an embodiment of the present invention;
[0044] Figure 3 This is a flowchart of a vehicle fault strategy determination method provided in Embodiment 2 of the present invention. Detailed Implementation
[0045] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0046] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0047] Example 1
[0048] Figure 1 This is a schematic diagram of a vehicle fault diagnosis strategy design system provided in Embodiment 1 of the present invention. This vehicle fault diagnosis strategy design system can be configured in a vehicle. Figure 1 As shown, the system includes: a first device 110, a second device 120, a third device 130, and a fourth device 140. Any one of the first device 110, the second device 120, the third device 130, and the fourth device 140 can be an electronic device such as a computer or a mobile phone, capable of information input, data display, and data processing functions, and the first device 110, the second device 120, the third device 130, and the fourth device 140 can transmit data to each other, for example, by connecting wirelessly or by connecting via a network cable.
[0049] The system comprises the following components: a first device 110, used to acquire vehicle equipment data and software function data, and determine vehicle functional scenario data based on the vehicle equipment data and software function data; wherein the functional scenario data includes vehicle function definitions and vehicle function implementation processes; a second device 120, used to determine functional requirement data based on the functional scenario data; a third device 130, used to perform functional feasibility analysis based on the functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and to determine diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and actual vehicle operation data; a fourth device 140, used to determine an initial fault strategy based on the diagnostic feasibility analysis result data; the third device 130 is also used to transmit the diagnostic feasibility analysis result data to the domain controller software test model for fault analysis to determine the domain controller fault strategy; and to perform fault verification based on the domain controller fault strategy and the initial fault strategy to determine the target fault strategy.
[0050] The first device 110 is used to acquire vehicle equipment data and software function data. This data can be input via an input device connected to the first device, and can also be retrieved from a server. The entire vehicle level can contain more than 300 functions. For example, both the vehicle equipment data and the software function data can be recorded in a document format. The vehicle equipment data includes vehicle equipment and its functional information. Vehicle equipment refers to the hardware devices included in the vehicle, including but not limited to electric motors, engines, sensors, audio systems, domain controllers, etc. The software function data can be specifically understood as the program that implements the device functions and its functional definitions.
[0051] The first device 110 can be specifically understood as a device used to design the functions of the entire vehicle. Based on vehicle equipment data and software function data, it determines the functional scenario data of the vehicle. The functional scenario can be specifically understood as an abstract and modeled description of the entire process of vehicle functions, such as the window opening function scenario, the voice navigation function scenario, and the vehicle driving function scenario. Functional scenarios can be defined for the entire vehicle functions based on vehicle equipment data and software function data. The functional scenario data includes the vehicle function definition and the vehicle function implementation process.
[0052] Optionally, the first device 110 is specifically used for: matching the functional information of each vehicle device with the software functional data to determine the corresponding software functional data of the vehicle device. This can be done by matching the functional information of the vehicle device in the vehicle device data with the software function name and function definition in the software functional data. If the functional information of the vehicle device and the function definition in the software functional data are the same, the match is considered successful; otherwise, it is unsuccessful. By sequentially matching each vehicle device and its functional information in the vehicle device data with the software functional data, the successfully matched functions can be classified into a functional scenario. While determining the functional scenario, the functional scenario is defined. The functional scenario definition is used to describe the implementation process of each function, that is, how each function of the whole vehicle is implemented and the information transmission between devices in the process of implementing the function.
[0053] The second device 120 can be specifically understood as a device for defining and managing controller functions. It is used to determine functional requirement data based on functional scenario data, and can determine the functions controlled by the domain controller based on the functional scenario data. Optionally, the second device is specifically used to: obtain the control policy of the domain controller; and determine functional requirement data based on the domain controller's control policy and the vehicle function definition in the functional scenario data. The functional requirement data can be specifically understood as the detailed requirements for the implementation of a function, that is, it may include, but is not limited to, vehicle functions and the parameter values of the controllers and devices that need to be met for the function to be implemented. The second device obtains the controllers and their corresponding control policies required for the vehicle functions according to the vehicle function definitions in the functional scenario data, thus obtaining the requirements for the implementation process of the function, and thus obtaining the functional requirement data.
[0054] The third device 130 can be specifically understood as a device used for fault analysis and diagnosis. Specifically, it is used to perform functional feasibility analysis based on functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and to determine diagnostic feasibility analysis result data based on diagnostic feasibility analysis requirement data and actual vehicle operation data. Among them, functional feasibility analysis can be specifically understood as analyzing functions through pre-designed diagnostic dimensions to determine the feasibility of vehicle functions.
[0055] Specifically, the third device 130 is used to perform feasibility analysis on each function according to diagnostic dimensions based on functional requirement data, and obtain diagnostic feasibility analysis requirement data for each function. The diagnostic dimensions include inability to start, inability to stop, inability to execute, output exceeding limits, and uncontrollable task behavior.
[0056] Specifically, the diagnostic feasibility analysis requirement data can be understood as preliminary feasibility analysis results, including the feasibility of the function, diagnostic dimensions, and corresponding judgments. Feasibility analysis determines whether a function meets the characteristics of being unable to start, unable to stop, unable to execute, having output exceeding limits, or having uncontrollable task behavior based on the functional requirement data. For example, performing a feasibility analysis on the window opening function, based on the requirement data, we can obtain the maximum opening height of the window (i.e., the height of the window frame). We can determine that there will be no situation where the window opening function cannot be stopped, thus confirming that the window opening function is not feasible for the diagnostic dimension of being unable to stop. By iterating through all the functional requirement data and performing feasibility analysis according to the diagnostic dimensions, we obtain the diagnostic feasibility analysis requirement data for each function.
[0057] The third device 130 determines the diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and the vehicle's actual operating data; optionally, it acquires the vehicle's actual operating data; based on the diagnostic feasibility analysis requirement data and the vehicle's actual operating data, it determines the fault name and its failure information, thus obtaining the diagnostic feasibility analysis result data. Specifically, the diagnostic feasibility analysis result data can be understood as a detailed definition of the diagnostic feasibility analysis requirement data according to actual functions and actual operating data. For example, if the requirement defines battery function failure, the third device 130 defines the failure conditions, such as a battery voltage below 7V. Specifically, the third device 130 determines the conditions for vehicle function failure based on the diagnostic feasibility analysis requirement data and the vehicle's actual operating conditions, thus obtaining the diagnostic feasibility analysis result data.
[0058] The fourth device 140 can be specifically understood as a software function development system, used to determine the initial fault strategy based on the diagnostic feasibility analysis results data; wherein, the initial fault strategy can be specifically understood as the initial fault code and fault specification of the function, which can define the fault code based on the fault type in the diagnostic feasibility analysis results data according to the fault diagnosis code definition rules, and determine the fault specification based on the fault information in the diagnostic feasibility analysis results data to obtain the initial fault strategy.
[0059] Optionally, the third device 130 is also used to transmit the diagnostic feasibility analysis results data to the domain controller software test model for fault analysis, determine the domain controller fault strategy, and perform fault verification based on the domain controller fault strategy and the initial fault strategy to determine the target fault strategy.
[0060] Among them, the domain controller software test model is a pre-trained test model used to take the diagnostic feasibility analysis results data as input to the model, introduce test methodology, analyze the functions and hardware links in the domain controller, perform fault analysis on each domain controller, and define hardware failures based on system reliability analysis technology. For example, internal short-circuit and open-circuit faults, watchdog faults, time module fault lights, etc. need to be defined to determine the domain controller fault strategy, etc.
[0061] Optionally, the third device 130 is used to perform fault verification based on the domain controller fault policy and the initial fault policy to determine the target fault policy. The domain controller fault policy and the initial fault policy can be matched with pre-set theoretical data on the achievable functions to determine the conditions for each function's failure and verify the accuracy of the fault policy settings for each function.
[0062] Optionally, before determining the target fault policy, a test coverage assessment is performed on the domain controller fault coverage of the domain controller fault policy to determine the domain controller fault policies that meet the test requirements. Fault points in the domain controller fault policies that meet the test requirements are then embedded to identify and capture fault issues during vehicle operation. Specifically, test requirements can be understood as the criteria for judging fault points, that is, whether the fault issues in the domain controller fault policy meet the criteria for judging fault points. Test requirements can be pre-set based on factors such as the severity of the fault and the cost of treating it as a fault point. Embedding can be understood as an event tracking method, which is the technology and implementation process for capturing, processing, and sending specific user behaviors or events to obtain fault point information in a timely manner.
[0063] Specifically, a testability methodology is introduced to evaluate the fault coverage of the domain controller, determine whether each fault point meets the testability requirements, and obtain the evaluation results. If the fault of the domain controller meets the testability requirements, it is regarded as a fault point and a data entry point is added to it.
[0064] Optionally, the fourth device is also used to determine controller software data based on the target fault strategy.
[0065] Specifically, controller software data can be understood as code blocks that implement control functions.
[0066] Specifically, software development is carried out based on the functional and fault information in the target fault strategy to obtain controller software data.
[0067] Optionally, the system may also include: a fifth device; the fifth device is used to determine test report data based on diagnostic feasibility analysis results data, target fault strategies, and controller software data.
[0068] Specifically, the fifth device can be understood as a system used for functional testing. It acquires diagnostic feasibility analysis results data, target fault strategies, and controller software data, and performs testing, analysis, and verification on the above data. It comprehensively tests whether the fault codes and fault specifications corresponding to the functions of each domain controller and its components are the same, and obtains a test report.
[0069] Furthermore, the second device 120 is used to acquire electrical equipment data of the vehicle, including system association diagrams, wiring harness schematics, and electrical attribute tables; the third device is used to construct a fault failure model based on the target fault strategy and the electrical equipment data, wherein the fault failure model is a model representing the relationship between hardware, software, and functions; the fault failure model is combined with a data analysis engine to determine vehicle fault problems; the fault problems are sent to an after-sales diagnostic instrument, which is used to display the fault problems and feed them back to the fault failure model to update the fault failure model.
[0070] The failure model can be understood as a framework model, which is a model that represents the relationship between hardware, software and functions.
[0071] Specifically, the second device 120 acquires the vehicle's electrical equipment data and transmits it to the third device 130. The target fault strategy and electrical equipment data are input parameters to the fault failure model, which processes the data and sends the results to the data analysis engine. The engine analyzes the fault to determine the vehicle's fault problem and sends the problem to the after-sales diagnostic instrument, which displays the information to the user. The after-sales diagnostic instrument also sends the diagnostic results to the fault failure model. The fault failure model combines the target fault strategy, electrical equipment data, and diagnostic results to perform self-learning, update and improve the model's parameters, and enhance its accuracy.
[0072] In a specific embodiment, such as Figure 2The diagram illustrates a vehicle fault strategy design system flowchart. A first device acquires equipment definition data and software function definition data, processes this data, defines corresponding functional scenarios based on the functional information, and obtains functional scenario data. This functional scenario data includes vehicle function definitions and vehicle function implementation processes; that is, the functional scenario definitions describe how each function of the vehicle is implemented and transmitted. A second device receives the functional scenario data and determines functional requirement data based on it. A third device acquires the functional requirement data, performs functional feasibility analysis based on it, and obtains diagnostic feasibility analysis requirement data for vehicle functions. It then performs failure analysis based on the diagnostic feasibility analysis requirement data and actual vehicle operating data to determine the diagnostic feasibility analysis result data. According to fault code definition rules, it defines fault codes for the faults in the diagnostic feasibility analysis result data to obtain an initial fault strategy. The third device sends the diagnostic feasibility analysis requirement data to the domain controller software test model for fault analysis to determine the domain controller fault strategy. It performs a test coverage evaluation of the domain controller fault strategy and verifies the evaluation results against the initial fault strategy to obtain the target fault strategy. Further, a fourth device develops software based on the target fault strategy to obtain the developed controller software. The fifth device acquires diagnostic feasibility analysis results, target fault strategies, and controller software data, and performs testing, analysis, and verification on the aforementioned data. It comprehensively tests whether the fault codes and fault specifications corresponding to the functions of each domain controller and its constituent components are consistent, generating a test report. Further, the second device acquires vehicle electrical equipment data and transmits it to the third device. The target fault strategy and electrical equipment data are input parameters to the fault failure model, which processes the data and sends the results to the data analysis engine. The engine analyzes the fault, identifies the vehicle fault problem, and sends it to the after-sales diagnostic instrument for display to the user. The after-sales diagnostic instrument also sends the diagnostic results to the fault failure model. The fault failure model combines the target fault strategy, electrical equipment data, and diagnostic results to perform model self-learning, updating and improving its parameters to enhance accuracy.
[0073] The technical solution of this embodiment processes vehicle equipment data and software function data through a vehicle fault strategy design system to obtain initial fault strategies at the system level and domain controller fault strategies at the component level. Then, it performs fault verification on the initial fault strategies and domain controller fault strategies to obtain accurate target fault strategies. This realizes the function of obtaining target fault strategies through a forward process fault design method. It helps to obtain only the parts that may cause problems in the diagnostic procedure without having to obtain all message information. This solves the problem of increasing difficulty in vehicle fault diagnosis caused by increasingly complex vehicle functions and improves the efficiency of vehicle fault diagnosis.
[0074] Example 2
[0075] Figure 3 This is a flowchart of a vehicle fault strategy determination method provided in Embodiment 2 of the present invention. This embodiment is applicable to situations involving the determination of vehicle fault strategies. This method can be executed by the aforementioned vehicle fault strategy design system, which can be implemented in hardware and / or software. This vehicle fault strategy design system can be configured in a vehicle control system or a computer. Figure 3 As shown, the method includes:
[0076] S210. Obtain vehicle equipment data and software function data through the first device, and determine the vehicle's functional scenario data based on the vehicle equipment data and software function data.
[0077] The functional scenario data includes vehicle function definitions and vehicle function implementation processes. Vehicle equipment data and software function data can be input through an external input device connected to the first device, or vehicle equipment data and software function data can be retrieved from the server.
[0078] Specifically, vehicle equipment data and software function data are acquired through a first device. This data is then processed, and functional scenarios can be predefined based on the vehicle equipment function information and software functions within the vehicle equipment data. The functional scenario definition describes the implementation process of each function of the vehicle and the transmission process between devices within that scenario. Alternatively, the vehicle equipment data and software function data can be processed through a functional scenario definition model to determine the vehicle's functional scenario data.
[0079] S220, Determine functional requirement data based on functional scenario data using the second device.
[0080] Specifically, the second device determines the implementation requirements of each function scenario based on functional scenario data. These implementation requirements can be determined by acquiring relevant survey data or experimental data. Functional requirement data is obtained by determining the implementation requirements for different functions. For example, defining a battery function scenario, experimental data shows that this function requires a battery voltage of 7V to function.
[0081] S230. The third device performs a functional feasibility analysis based on the functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and determines the diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and the actual vehicle operation data.
[0082] Specifically, a third-party device performs a functional feasibility analysis based on functional requirement data. Diagnostic criteria are established according to dimensions such as inability to start, inability to stop, inability to execute, output exceeding limits, and uncontrollable task behavior. Each functional requirement is assessed according to these diagnostic dimensions to determine its feasibility, resulting in a judgment and diagnostic feasibility analysis requirement data. The diagnostic feasibility analysis requirement data is then modified based on actual operational data to determine the conditions for functional failure, yielding the diagnostic feasibility analysis result data.
[0083] Optionally, the diagnostic feasibility analysis result data can be determined based on the diagnostic feasibility analysis requirement data and the vehicle's actual operating data, including: obtaining the vehicle's actual operating data; determining the fault name and its failure information based on the diagnostic feasibility analysis requirement data and the vehicle's actual operating data, and obtaining the diagnostic feasibility analysis result data.
[0084] Specifically, actual vehicle operating data can be obtained through a third device. By matching the operating data with the diagnostic feasibility analysis requirement data, the actual operating data of each function in the diagnostic feasibility analysis requirement data can be determined. Based on the corresponding operating data, the failure conditions of the function can be determined. This can be understood as determining the parameter values of the equipment required to achieve the function under the condition of failure. For example, the requirement defines the failure of the battery function. The failure conditions can be determined by the third device, such as the failure of a battery function below 7V.
[0085] S240. The initial fault strategy is determined by the fourth device based on the diagnostic feasibility analysis results data.
[0086] Specifically, the fault diagnosis code definition rules can be used as the standard. The fourth device can define fault codes based on the fault types in the diagnostic feasibility analysis results data, determine the fault specifications based on the fault information in the diagnostic feasibility analysis results data, and obtain the initial fault strategy.
[0087] S250: Transmit the diagnostic feasibility analysis results to the domain controller software test model via a third device for fault analysis and determine the domain controller fault strategy; perform fault verification based on the domain controller fault strategy and the initial fault strategy to determine the target fault strategy.
[0088] Specifically, by using the diagnostic feasibility analysis results as input to the domain controller software test model, a test methodology is introduced to analyze the functions and hardware links within the domain controller. Fault analysis is performed on each domain controller, and hardware failures can be defined based on system reliability analysis techniques to obtain domain controller fault policies. For example, the definition of hardware failures requires defining internal short-circuit / open-circuit faults, watchdog faults, and time module fault lights, etc. Then, the domain controller fault policies and initial fault policies are matched with pre-set functional achievable theoretical data to determine the failure conditions of each function and verify the accuracy of the fault policy settings for each function.
[0089] The technical solution of this embodiment acquires vehicle equipment data and software function data through a first device, determines vehicle functional scenario data based on the vehicle equipment data and software function data, performs functional feasibility analysis based on functional requirement data through a third device to obtain diagnostic feasibility analysis requirement data for vehicle functions, and determines diagnostic feasibility analysis result data based on diagnostic feasibility analysis requirement data and actual vehicle operation data; determines an initial fault strategy based on diagnostic feasibility analysis result data through a fourth device; and determines a target fault strategy based on diagnostic feasibility analysis result data and initial fault strategy through the third device. By adopting a forward process fault determination method, the function of designing vehicle fault strategies is realized. Fault causes can be quickly identified for different functional scenarios, solving the problem of high difficulty and low efficiency in vehicle fault diagnosis caused by increasingly complex vehicle functions, and improving the efficiency of vehicle fault diagnosis.
Claims
1. A vehicle fault diagnosis strategy design system, characterized in that, include: The first device is used to acquire vehicle equipment data and software function data, and determine the vehicle's functional scenario data based on the vehicle equipment data and the software function data; wherein, the functional scenario data includes vehicle function definitions and vehicle function implementation processes; The second device is used to determine functional requirement data based on the functional scenario data; The third device is used to perform a functional feasibility analysis based on the functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and to determine diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and actual vehicle operation data. The fourth device is used to determine the initial fault strategy based on the diagnostic feasibility analysis results data; The third device is also used to transmit the diagnostic feasibility analysis result data to the domain controller software test model for fault analysis and to determine the domain controller fault strategy; and to perform fault verification based on the domain controller fault strategy and the initial fault strategy to determine the target fault strategy.
2. The system according to claim 1, characterized in that, The vehicle equipment data includes vehicle equipment and functional information of the vehicle equipment, wherein the vehicle equipment includes a domain controller; The first device is specifically used for: The software function data corresponding to each vehicle device is determined by matching the functional information of each device with the software function data.
3. The system according to claim 2, characterized in that, The second device is specifically used for: Obtain the control policy of the domain controller; The functional requirement data is determined based on the control strategy of the domain controller and the functional scenario data.
4. The system according to claim 1, characterized in that, The third device is specifically used for: Based on the functional requirement data, a feasibility analysis is performed on each of the functions according to diagnostic dimensions to obtain diagnostic feasibility analysis requirement data for each function. The diagnostic dimensions include inability to start, inability to stop, inability to execute, output exceeding limits, and uncontrollable task behavior.
5. The system according to claim 1, characterized in that, The third device is specifically used for: Obtain the actual operating data of the vehicle; Based on the diagnostic feasibility analysis requirements data and the actual vehicle operating data, the fault name and its failure information are determined, and the diagnostic feasibility analysis result data is obtained.
6. The system according to claim 1, characterized in that, The third device is also used for: Before determining the target fault strategy, a test coverage assessment is performed on the domain controller fault coverage of the domain controller fault strategy to determine the domain controller fault strategy that meets the test requirements; fault points in the domain controller fault strategy that meets the test requirements are embedded to identify and capture fault problems during the operation of the vehicle function.
7. The system according to claim 1, characterized in that, The fourth device is also used to determine controller software data based on the target fault strategy; The system also includes: a fifth device; The fifth device is used to determine test report data based on the diagnostic feasibility analysis results data, the target fault strategy, and the controller software data.
8. The system according to claim 1, characterized in that, The second device is used to acquire electrical equipment data of the vehicle, the electrical equipment data including system association block diagram, wiring harness schematic diagram, and electrical attribute table; The third device is used to construct a fault failure model based on the target fault strategy and the electrical equipment data, wherein the fault failure model is a model representing the relationship between hardware, software, and functions; combine the fault failure model with a data analysis engine to determine vehicle fault problems; send the fault problems to an after-sales diagnostic instrument, which is used to display the fault problems and feed them back to the fault failure model to update the fault failure model.
9. A method for determining vehicle fault diagnosis strategy, characterized in that, include: The vehicle equipment data and software function data are acquired through a first device, and the vehicle's functional scenario data is determined based on the vehicle equipment data and the software function data; wherein, the functional scenario data includes vehicle function definitions and vehicle function implementation processes; The second device determines the functional requirement data based on the functional scenario data. A third device performs a functional feasibility analysis based on the functional requirement data to obtain diagnostic feasibility analysis requirement data for vehicle functions; and determines diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and actual vehicle operation data. The initial fault strategy is determined by the fourth device based on the diagnostic feasibility analysis results data. The diagnostic feasibility analysis results are transmitted to the domain controller software test model via the third device for fault analysis to determine the domain controller fault strategy; based on the domain controller fault strategy and the initial fault strategy, fault verification is performed to determine the target fault strategy.
10. The method according to claim 9, characterized in that, The process of determining the diagnostic feasibility analysis result data based on the diagnostic feasibility analysis requirement data and the actual vehicle operation data includes: Obtain the actual operating data of the vehicle; Based on the diagnostic feasibility analysis requirements data and the actual vehicle operating data, the fault name and its failure information are determined, and the diagnostic feasibility analysis result data is obtained.