Automobile fault diagnosis process development method based on design change

Abstract

The invention discloses a design change-based automobile fault diagnosis process development method, which comprises the following steps of: comparing DTC data, functional loop information, a system schematic diagram and BOM information before and after change setting in a development database, and marking a change situation; performing information processing and variable content marking on different variable conditions so as to create a fault diagnosis process variable development task; and according to the created fault diagnosis process setting change development task, completing fault diagnosis process setting change content development. According to the invention, the system automatically compares the change data, identifies the change point and marks the situation, reduces the workload of manual interpretation and comparison, reduces the risk of human errors and omission, can automatically judge whether various changes affect the diagnosis process or not through the preset fault diagnosis change element library, and improves the diagnosis efficiency. And the corresponding development task is accurately generated, so that deviation caused by artificial experience is avoided.

Description

Technical Field

[0001] This invention relates to the field of fault diagnosis in the automotive aftermarket, and more specifically, to a method for developing an automotive fault diagnosis process based on design changes. Background Technology

[0002] With the increasing intelligence and connectivity of vehicles, the electronic and electrical architecture of vehicles is becoming increasingly complex, and design changes have become a routine means of product iteration and problem fixing. Traditional fault diagnosis process development is usually based on fixed fault codes (DTCs) and the logical principles of common physical phenomena. When design changes occur, the existing fault diagnosis process needs to be precisely adjusted to meet the needs of end users. The main technical challenges encountered in this process include: 1. Manual interpretation is inefficient and prone to errors: There are many possible scenarios, and the change data needs to be interpreted and the change points identified manually. The interpretation workload is large, the technical difficulty is high, and omissions / comparison errors are easy to occur. 2. Impact analysis is difficult: The task of generating design change content development tasks based on design change points is difficult, and it is necessary to accurately identify and extract information that affects the development of fault diagnosis process content; 3. Difficulty in tracking and reviewing changes: Manually marking change points is labor-intensive and prone to omissions, making it difficult to accurately review the content of changes. Therefore, a method and system for developing automotive fault diagnosis processes based on design changes are proposed. Summary of the Invention

[0003] This invention provides a method for developing automotive fault diagnosis processes based on design changes, in order to solve the technical problems of high workload, omission of markings, and inaccuracy caused by the high degree of manual reliance in the development of existing traditional fault diagnosis processes.

[0004] According to one aspect of the present invention, a method for developing an automotive fault diagnosis process based on design changes is provided, comprising the following steps: Step 1: Create a development database, compare the DTC data, system schematics, and BOM information before and after the change in the development database, and mark the change situation; according to the change situation, create corresponding fault diagnosis process design change development tasks. Step 2: For cases where DTC data and functional loop information are changed, develop the corresponding fault diagnosis process based on the correspondence between the changed DTC data and the original or changed functional loop, and the differences in the functional loop content elements. For cases where the system schematic diagram is modified, the modified components can be located by associating the controller name with the DTC and the signal source-component information in the DTC standard definition; based on the differences in component names before and after the modification, the corresponding fault diagnosis process can be developed. For BOM design changes, develop fault diagnosis process content based on the differences in electrical components and mechanical parts before and after the design change.

[0005] Based on the above scheme, in step 1, the modified DTC data and functional loop information are compared with the data in the development database, and the changes are marked. This includes the following steps: Step A1: Make a preliminary judgment on the DTC data and pre-label and classify the DTC scenario. Step A2: Based on the pre-marked DTC configuration changes, standardize the DTC data and store the processed DTC standard data in the DTC standard meaning library. Step A3: Based on the DTCs and their status markers that have been standardized in Step A2, create or maintain the correspondence between the DTC data of the transformer and the original functional loop. Step A4: Based on the correspondence in Step A3 and the differences in the content elements of the corresponding functional loops of the corresponding DTC, create the corresponding fault diagnosis process design and development task. Create corresponding functional loop information change development tasks based on the functional loop information change marking conditions.

[0006] Based on the above scheme, the preferred scenario is that the DTC setting changes include DTC cancellation, DTC addition, and DTC meaning change; the functional loop information setting changes include functional loop addition and functional loop element change.

[0007] Based on the above scheme, step A2 specifically includes: For cases pre-marked as "DTC Addition" and "DTC Meaning Change", when the controller name + fault code meaning associated with the changed DTC does not match the DTC information of the target vehicle model before the change, and the controller name + fault code meaning associated with the changed DTC does not match the DTC standard data that has been standardized in the DTC standard meaning library, and the fault code or fault code meaning does not match in the DTC standard meaning library, the corresponding DTC standardization task is generated.

[0008] Based on the above scheme, in step 1, the modified system schematic diagram is compared with the data in the development database, and the changes are marked, including the following steps: Step B1: Extract and compare the wiring harness diagrams before and after the design change from the development database, and mark the differences. Step B2 involves matching the differences in wiring information between the pre- and post-design wiring harness drawings with elements in the fault diagnosis change element preset library, finding relevant design components, and generating corresponding design development tasks.

[0009] Based on the above scheme, in step 1, the modified BOM information is compared with the data in the development database, and the change is marked, including the following steps: Step C1: Extract and compare the BOM list information before and after the design change, and mark the design changes of electrical components and mechanical parts; Step C2: Generate corresponding design change development tasks based on the design change conditions of electrical components and mechanical parts.

[0010] Based on the above scheme, the preferred options are that the changes in the electrical components include component cancellation, component replacement, and component addition; and the changes in the mechanical components include part cancellation, part replacement, and part addition.

[0011] Based on the above scheme, in step C2, according to the design change situation of the electrical components, a corresponding design change development task is generated, including: For cases marked as "component replacement" and "component addition", the component is determined to be a non-controller. The technical parameters of the replaced component before and after the design change are compared with those in the component technical parameter database. If there is a difference, the diagnostic unit corresponding to the component is marked and the corresponding design change development task is generated. In step C2, a corresponding design change development task is generated based on the design change of the mechanical component, including: For cases marked as "part replacement" and "part addition", find the relevant technical parameter information of the design change part, mark the diagnostic unit corresponding to the part, and generate the design change development task of the corresponding part. For cases marked as "new part", identify and determine whether the new part belongs to the actuator in the functional loop, mark the corresponding diagnostic unit for the part, and generate the corresponding part's design change development task.

[0012] Based on the above scheme, in step 2, for cases where DTC data and functional loop information are altered, a corresponding fault diagnosis process is developed based on the correspondence between the altered DTC data and the original or altered functional loop, and the differences in the functional loop content elements. This includes: For cases where the correspondence between DTC data and functional loop information before and after the design change is newly added or canceled, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development database. If the correspondence between DTC data and functional loop information remains unchanged before and after the change, but there are changes in the content elements of the functional loop, the corresponding diagnostic unit is found by matching the DTC data with the functional loop name and the functional loop name with the diagnostic unit code. The connectors and pin information in the diagnostic unit are then replaced to complete the development of the corresponding change content.

[0013] Based on the above scheme, in step 2, for cases with BOM changes, the fault diagnosis process content is developed according to the component changes, including: For design and development tasks output through "component replacement" or "part replacement", the required diagnostic unit codes are retrieved and located by checking the components and combining them with category feature codes. Based on the diagnostic units before the design and transformation, their technical parameters are modified and marked to complete the revision of the content of the fault diagnostic units after the design and transformation. For design change development tasks output through "component addition" and "part addition" scenarios, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development database. The fault diagnosis process content involved in the design change point is developed, and the design change development content is marked.

[0014] Compared with existing technologies, the automotive fault diagnosis process development method based on design changes of the present invention has the following significant advantages: 1. Automation and intelligence: By automatically comparing design change data, identifying change points and marking situations, the system greatly reduces the workload of manual interpretation and comparison, and reduces the risk of human error and omission.

[0015] 2. Precise impact analysis: Through a pre-built fault diagnosis change element library, the system can automatically determine whether various changes (DTC design changes, functional circuit design changes, wiring harness drawing design changes, and component design changes) affect the diagnostic process and accurately generate corresponding development tasks, avoiding the deviations that may be caused by relying on human experience.

[0016] 3. Efficient task management: It realizes full-link automated management from design changes to development tasks. Task generation is clear and traceable, which greatly improves development efficiency and process standardization.

[0017] 4. Knowledge Reuse and Standardization: A DTC standard meaning library was built to promote the accumulation and reuse of diagnostic knowledge across different vehicle models and projects, ensuring the consistency and standardization of the diagnostic process. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the 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. In the drawings: Figure 1 This is a flowchart of the automotive fault diagnosis process development method based on design changes according to the present invention. Figure 2 This is a flowchart illustrating the DTC data and functional loop information processing flow after design change in step 1 of the automotive fault diagnosis process development method based on design change of the present invention. Figure 3 This is a schematic diagram of the system after design change and a data flow diagram of the development database for step 1 of the automotive fault diagnosis process development method based on design change of the present invention. Detailed Implementation

[0019] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of a descriptive feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or sets.

[0021] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, for ease of understanding, in some figures, only one of components with the same structure or function is shown schematically, or only one is labeled. In this document, "one" can mean not only "only one" but also "more than one".

[0022] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] In the embodiments shown in the accompanying drawings, the directional indications (such as up, down, left, right, front, and back) used to explain the structure and movement of the various components of the invention are relative rather than absolute. These descriptions are appropriate when these components are in the positions shown in the drawings. If the positions of these components change, these directional indications also change accordingly.

[0024] Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0026] Please see Figure 1 The present invention provides a method for developing a vehicle fault diagnosis process based on design changes, comprising the following steps: Step 1: Create a development database, compare the DTC data, functional loop information, system schematic diagram, and BOM information before and after the design change with the data in the development database, and mark the changes. This includes creating a development resource repository to store the development materials needed for developing the fault diagnosis manual, and to manage versions (including design change input data).

[0027] According to the brand and project development number, the received design change documents (hereinafter referred to as: design change documents) are pre-classified and standardized in format, and the processed design change documents are uploaded to the development data database for storage.

[0028] The DTC data before and after the change is compared with the functional loop information in the development database, and the change is marked. The detailed steps include: In step 1, step A1 involves pre-judging the DTC data and pre-labeling and classifying the DTC change scenarios. First, a DTC data processing module is built to standardize DTC data.

[0029] Create a DTC standard meaning library to store DTC standard data after DTC meaning standardization processing.

[0030] Then, the DTC data processing module compares the elements (such as fault codes and their meanings) of the DTC development data uploaded to the development data library before and after the change, according to the brand and development code. Based on the comparison results, it automatically pre-marks the change scenarios of DTC cancellation (i.e., the fault code is cancelled), DTC addition (i.e., the fault code is added), and DTC meaning change (i.e., the fault code remains unchanged, or the meaning of the fault code has changed).

[0031] Step A2: Based on the pre-labeled DTC variation scenarios, standardize the DTC data and store the processed DTC standard data in the DTC standard meaning library. The specific processing method is as follows: Based on the pre-marking of DTC design change scenarios in step A1, the following DTC standardization processing rules are created respectively, and the standardized DTC standard data is stored in the DTC standard meaning library. The specific processing rules for different design change scenarios are as follows: DTC Cancellation: For cases marked as "DTC Cancellation", there is no need to perform DTC standardization processing.

[0032] Added DTC: For cases marked "Added DTC", the DTC data processing module prioritizes matching the controller name and fault code meaning associated with the new DTC within the same product system with the DTC information of the target vehicle model before the change. If a complete match is found, the system references the standard DTC meaning; if a complete match is not found, the system matches the controller name and fault code meaning associated with the new DTC with historically standardized DTC standard data in the DTC standard meaning library.

[0033] For cases that match perfectly, the system references the standard meaning of the DTC. For cases that do not match, the system further searches the DTC standard meaning library across different product systems and controllers using fault codes or their meanings. If a match is found, the standard meaning in the matching DTC standard data is used to generate a DTC standardization task, which is then marked as "verify and modify". If a match is not found, the corresponding DTC standardization task is generated and marked as "new".

[0034] Based on the generated DTC standard meaning verification and modification tasks and the new DTC standardization development tasks, basic information such as DTC fault codes, product systems, controller names, controller suppliers, controller version numbers, and fault code meanings extracted from the corresponding DTC design data is used to create or maintain corresponding DTC standard meaning information (including: code factor, signal deviation meaning, signal source information (part, area), code subject, signal deviation level, severity), thereby completing the standardization processing of the corresponding design DTC. The standardization processing method for DTCs is described in detail in the applicant's patent application ZL202411457468.3: A Method for Standardizing Automotive DTC Data, and will not be repeated here.

[0035] DTC Meaning Change: For cases marked "DTC Meaning Change", the basic information such as DTC fault code, product system, controller name, controller supplier, controller version number, and fault code meaning are extracted from the corresponding DTC design data.

[0036] Based on the extracted basic information and referring to the newly added DTC scenarios, the system directly matches the controller name and fault code meaning associated with the transformer DTC with the historically standardized DTC standard data in the DTC standard meaning library, and generates the corresponding DTC standardization task based on the matching results.

[0037] Based on the generated DTC standardization task, complete the corresponding design change DTC standardization process.

[0038] Step A3: Based on the DTCs and their status markers that have been standardized in Step A2, create or maintain the correspondence between the DTC data of the transformer and the original functional loop or the functional loop of the transformer. Step A4: Based on the correspondence in Step A3 and the differences in the content elements of the corresponding functional loops of the corresponding DTC, create the corresponding fault diagnosis process design and development task. For DTCs whose status is set to "DTC canceled" in step A3, there is no need to establish a correspondence between DTCs and functional loops.

[0039] For DTCs marked as "DTC Added" in step A3, if their standard meaning is to reference a DTC from before the target model's design change, the system directly references the corresponding functional loop information of the DTC and creates a relationship between the corresponding functional loop and the design change DTC. If their standard meaning is to reference a historical model's DTC, or to verify modifications or newly developed features, the system manually maintains or creates a functional loop and checks the correspondence between the design change DTC and the functional loop.

[0040] For DTC data with the status mark "DTC meaning change" in step A3, the corresponding functional loop is maintained or created according to the DTC standardized task status mark, and the correspondence between the DTC data and the functional loop is checked.

[0041] For the method of creating the correspondence between DTC data and functional circuits, please refer to the applicant's patent application ZL2024117791899: A method for viewing automotive electrical fault circuits, so it will not be repeated here.

[0042] Based on the design change markers indicating the correspondence between DTC data and functional loop information, create corresponding DTC design change and functional loop information design change development tasks. Functional loop information design change scenarios include adding functional loops and changing functional loop elements.

[0043] Specifically, in this invention, design development tasks for DTC and functional loop information are created according to the design change marking conditions of DTC and functional loop information, including the processing of design change marking conditions for the correspondence between DTC data and functional loop information.

[0044] The steps for generating the DTC design change task are as follows: The system includes a pre-set library of fault diagnosis change elements (i.e., elements that affect the development of fault diagnosis, such as component brand name, connector code, connector pin number, relay code, fuse code, pin definition information, etc.).

[0045] For newly added DTC and functional circuit name correspondences, create corresponding DTC fault diagnosis process development tasks.

[0046] For transformer DTCs and functional loop names that remain unchanged, but whose content elements have changed, the system identifies and marks the differences in the functional loop information corresponding to the DTCs before and after the transformer change. It then matches the transformer elements in the corresponding functional loops with elements in the pre-set library of fault diagnosis change elements to determine if the differences affect the fault diagnosis process development. If they do, the system automatically finds the transformer diagnosis unit code and generates the corresponding transformer development task; if they do not, there is no need to generate the corresponding transformer development task.

[0047] The steps for handling the change in the functional circuit configuration are as follows: The system compares and marks the functional loops created based on the system schematic before and after the design change. For design changes marked as "Functional Loop Added," a correspondence between the design change functional loop and the DTC (Distributed Troubleshooting Control) is created, and a corresponding DTC fault diagnosis process development task is created, referring to the DTC design change task generation and processing method. For design changes marked as "Functional Loop Element Changed," the design change elements in the functional loop are matched with the elements in the fault diagnosis change element pre-set library, referring to the DTC design change task generation and processing method, to determine whether the differences affect the fault diagnosis process development. If they do, the system automatically finds the design change diagnosis unit code and generates the corresponding design change development task; if they do not, there is no need to generate the corresponding design change development task.

[0048] Please see Figure 3 As shown, in step 1 of this invention, the system schematic diagrams before and after the design change in the development database are compared with the data in the development database, and the changes are marked. This includes the following steps: Step B1: Extract the wiring information from the wiring harness drawings before and after the change in the development database, and mark the differences. Step B2 involves matching the differences in wiring information between the pre- and post-design wiring harness drawings with elements in the fault diagnosis change element pre-set library, finding relevant design transformer components, and generating corresponding design transformer development tasks. The detailed processing method is as follows: By matching the differences in wiring information in the wiring harness drawings before and after the change with the elements in the fault diagnosis change element pre-set library, it can be determined whether the differences affect the development of the fault diagnosis process.

[0049] For design change points that do not involve element information in the fault diagnosis change element pre-set library, the design change point has no impact on the development of the original fault diagnosis process, and there is no need to generate a corresponding design change development task.

[0050] For elements in the fault diagnosis change element preset library, the system uses the controller name associated with DTC and the signal source-part information in the DTC standard meaning to find the relevant design and change components, illuminate them, and generate the corresponding design and change development task.

[0051] Please continue reading. Figure 3 As shown, step 1 of this invention involves comparing the BOM information before and after the design change in the development database with the data in the development database, and marking the change situation, including the following steps: Step C1: Extract and compare the BOM list information before and after the design change, and mark the design changes of electrical components and mechanical parts; The changes in the electrical components include component cancellation, component replacement, and component addition; the changes in the mechanical components include part cancellation, part replacement, and part addition.

[0052] Step C2: Based on the design changes of electrical components and mechanical parts, generate corresponding design change development tasks. The specific processing steps are as follows: Specifically, corresponding design change development tasks are generated based on the design changes of electrical components: For components marked as "cancelled", the corresponding fault diagnosis paths and diagnostic units developed before the transformer were designed will be marked as "cancelled" by searching through the correspondence between diagnostic units and component reference names, without the need to generate transformer development tasks. For components marked "component replacement", if the component belongs to the controller, the system outputs the replacement controller and its DTC data requirement list, and processes it according to step 2, the DTC change handling method; if it is not the controller, the system compares the differences in the technical parameters of the replacement component before and after the change in the part technical parameter database.

[0053] If there is no difference, the design change of this component will not affect the development of the original fault diagnosis process, and there is no need to generate a design change development task; if there is a difference, the system will automatically mark the diagnostic unit corresponding to the component and generate the corresponding design change development task.

[0054] For items marked "Added Component", if the component belongs to a controller, the system will output a list of DTC data requirements for the corresponding controller, and process it according to step 2, the DTC change scenario handling method; if it is not a controller, the system will output a list of technical parameter data requirements for the corresponding component. Based on the development data, create a corresponding fault diagnosis process change development task.

[0055] Based on the design changes of the mechanical components, corresponding design change development tasks are generated, including: For parts marked as "cancelled", the system searches by matching part name with diagnostic unit code and marks the found diagnostic path and diagnostic unit as "cancelled" without generating a corresponding design change development task. For cases marked as "part replacement" and "part addition", the relevant technical parameter information of the design change part is found, the corresponding diagnostic unit is marked, and the corresponding design change development task is generated; if the relevant technical parameter information of the design change part is not found, the diagnostic process does not need to be modified and the corresponding design change development task does not need to be generated.

[0056] For cases marked "New Part", the system outputs a list of technical parameter requirements for the corresponding component. Based on the preset correspondence between functional loops and actuators, it prioritizes identifying and determining whether the new part belongs to an actuator within a functional loop. If so, a corresponding design change development task is created for that part; otherwise, no modification to the existing fault diagnosis process is required.

[0057] Furthermore, step 2 of the present invention involves the development and revision of the fault diagnosis process design content. This includes, for changes in DTC data and functional loop information, developing the corresponding fault diagnosis process based on the correspondence between the DTC data design and the original or changed functional loop, and the differences in the functional loop content elements; for changes in the system schematic diagram, synchronizing the component names in the fault diagnosis process corresponding to the DTC data to develop the corresponding fault diagnosis process; and for changes in the BOM, developing the fault diagnosis process content based on the component design changes.

[0058] Specifically, for cases where DTC data and functional loop information are altered, a corresponding fault diagnosis process will be developed based on the correspondence between the altered DTC data and the original or altered functional loop, as well as the differences in the functional loop's content elements. This includes the following aspects: First, the development of the DTC (Digital Troubleshooting) design and fault diagnosis process: For cases where the correspondence between DTCs and functional circuits before and after the design change is newly added or canceled, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development database. For the method of developing the diagnostic path and diagnostic unit, please refer to the applicant's patent application ZL202411779910.4: A Method for Developing a Diagnostic Process for Automotive DTCs, which will not be elaborated here.

[0059] For changes where the correspondence between DTCs and functional loops remains unchanged before and after the change, but the content elements within the functional loops change, the system locates the corresponding diagnostic unit by matching the DTC with the functional loop name and the functional loop name with the diagnostic unit code. The system then replaces the connectors and pin information in the diagnostic unit to complete the corresponding change content development.

[0060] Second, development of functional loop design and fault diagnosis process: For DTCs and functional circuits whose correspondence is newly added or canceled, the diagnostic path and diagnostic unit are developed based on the DTC data, part technical parameter data and other development data in the development database. For the method of developing the diagnostic path and diagnostic unit, please refer to the applicant's patent application ZL202411779910.4: A method for developing automotive DTC fault diagnosis process, which will not be repeated here.

[0061] For cases where the correspondence between DTC and functional loop design changes remains unchanged, but the content elements within the functional loop change, the system locates the corresponding diagnostic unit by matching the DTC with the functional loop name and the functional loop name with the diagnostic unit code. The system then replaces the connectors and pin information within the diagnostic unit to complete the development of the corresponding design change content.

[0062] In step 2, for changes to the system schematic, the component names in the fault diagnosis process corresponding to the synchronized DTC data are used to complete the development of the corresponding fault diagnosis process. The detailed steps are as follows: Based on the component reference names in the design and transformation system schematic diagram, the component names in the fault diagnosis process corresponding to the DTC are adjusted synchronously to complete the development of the corresponding design and transformation content.

[0063] In step 2, for cases with changes in the BOM (Bill of Materials) design, the fault diagnosis process is developed based on the changes in component design, including the following steps: For design and development tasks output through "component replacement" or "part replacement" scenarios, the required diagnostic unit codes are retrieved and located by checking the component and category feature codes. Based on the pre-design diagnostic units, their technical parameters are modified and marked, completing the revision of the post-design fault diagnostic units.

[0064] For design change development tasks output through "component addition" and "part addition" scenarios, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development data library. The fault diagnosis process content involved in the design change point is developed, and the design change development content is marked.

[0065] Compared with existing technologies, the present invention provides a method for developing automotive fault diagnosis processes based on design changes, which has the following significant advantages: Automation and intelligence: By automatically comparing design change data, identifying change points and marking situations through the system, the workload of manual interpretation and comparison is greatly reduced, and the risk of human error and omission is reduced.

[0066] Precise impact analysis: Through a pre-built fault diagnosis change element library, the system can automatically determine whether various changes affect the diagnosis process and accurately generate corresponding development tasks, avoiding the deviations that may be caused by relying on human experience.

[0067] Efficient task management: It realizes full-link automated management from design changes to development tasks, with clear and traceable task generation, which greatly improves development efficiency and process standardization.

[0068] Knowledge reuse and standardization: A DTC standard meaning library was built to promote the accumulation and reuse of diagnostic knowledge across different vehicle models and projects, ensuring the consistency and standardization of the diagnostic process.

[0069] Finally, the method described in this application is merely a preferred embodiment and is not intended to limit the scope of protection of this invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for developing a vehicle fault diagnosis process based on design changes, characterized in that, Includes the following steps: Step 1: Create a development database, compare the DTC data, functional loop information, system schematic diagram, and BOM information before and after the design change in the development database, and mark the change situation. Based on the changes, create corresponding fault diagnosis process design and development tasks. Step 2: For cases where DTC data and functional loop information are changed, develop the corresponding fault diagnosis process based on the correspondence between the changed DTC data and the original or changed functional loop, and the differences in the functional loop content elements. For cases where the system schematic diagram is modified, the modified components can be located by using the DTC associated controller name and the signal source and other component information in the DTC standard definition. Based on the differences in component names before and after the design, complete the development of corresponding fault diagnosis processes; For BOM design changes, develop fault diagnosis process content based on the differences in electrical components and mechanical parts before and after the design change.

2. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 1, characterized in that, In step 1, the DTC data before and after the change in the development database is compared with the functional loop information, and the change is marked. This includes the following steps: Step A1: Make a preliminary judgment on the DTC data and pre-label and classify the DTC scenario. Step A2: Based on the pre-marked DTC configuration changes, standardize the DTC data and store the processed DTC standard data in the DTC standard meaning library. Step A3: Based on the DTCs and their status markers that have been standardized in Step A2, create or maintain the correspondence between the DTC data of the transformer and the original functional loop or the functional loop of the transformer. Step A4: Based on the correspondence in Step A3 and the differences in the content elements of the corresponding functional loops of the corresponding DTC, create the corresponding fault diagnosis process design and development task.

3. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 2, characterized in that, The DTC setting changes include DTC cancellation, DTC addition, and DTC meaning change; the functional loop information setting changes include functional loop addition and functional loop element change.

4. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 3, characterized in that, Step A2 includes the following in detail: Create a DTC standard meaning library. For cases pre-marked as "DTC added" and "DTC meaning changed", when the controller name + fault code meaning associated with the changed DTC does not match the DTC information of the target vehicle before the change, or the controller name + fault code meaning associated with the changed DTC does not match the historically standardized DTC standard data in the DTC standard meaning library, or the fault code or fault code meaning does not match in the DTC standard meaning library, generate the corresponding DTC standardization task.

5. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 1, characterized in that, Step 1 involves comparing the system schematics before and after the changes in the development database and marking the changes, including the following steps: Step B1: Extract and compare the wiring harness diagrams before and after the design change from the development database, and mark the differences. Step B2 involves matching the differences in wiring information between the pre- and post-design wiring harness drawings with elements in the fault diagnosis change element preset library, finding relevant design components, and generating corresponding design development tasks.

6. The method for developing an automotive fault diagnosis process based on design changes as described in claim 1, characterized in that, Step 1 involves comparing the BOM information before and after the design change in the development database and marking the change details, including the following steps: Step C1: Extract and compare the BOM list information before and after the design change, and mark the design changes of electrical components and mechanical parts; Step C2: Generate corresponding design change development tasks based on the design change conditions of electrical components and mechanical parts.

7. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 6, characterized in that, The changes in the design of electrical components include component cancellation, component replacement, and component addition; the changes in the design of mechanical components include part cancellation, part replacement, and part addition.

8. The method for developing a vehicle fault diagnosis process based on design changes as described in claim 7, characterized in that, In step C2, a corresponding design change development task is generated based on the design change situation of the electrical components, including: For cases marked as "component replacement" and "component addition", the component is determined to be a non-controller. The technical parameters of the replaced component before and after the design change are compared with those in the component technical parameter database. If there is a difference, the diagnostic unit corresponding to the component is marked and the corresponding design change development task is generated. In step C2, a corresponding design change development task is generated based on the design change of the mechanical component, including: For cases marked as "part replacement" and "part addition", find the relevant technical parameter information of the design change part, mark the diagnostic unit corresponding to the part, and generate the design change development task of the corresponding part. For cases marked as "new part", identify and determine whether the new part belongs to the actuator in the functional loop, mark the corresponding diagnostic unit for the part, and generate the corresponding part's design change development task.

9. The method for developing an automotive fault diagnosis process based on design changes as described in claim 1, characterized in that, In step 2, for cases where DTC data and functional loop information have changed, based on the correspondence between the changed DTC data and the original or changed functional loop, and the differences in the functional loop content elements, a corresponding fault diagnosis process is developed, including: For cases where the correspondence between DTC data and functional loop information before and after the design change is newly added or canceled, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development database. If the correspondence between DTC data and functional loop information remains unchanged before and after the change, but there are changes in the content elements of the functional loop, the corresponding diagnostic unit is found by matching the DTC data with the functional loop name and the functional loop name with the diagnostic unit code. The connectors and pin information in the diagnostic unit are then replaced to complete the development of the corresponding change content.

10. The method for developing an automotive fault diagnosis process based on design changes as described in claim 1, characterized in that, In step 2, for cases where the BOM design changes, the fault diagnosis process is developed based on the component design changes, including: For design and development tasks output through "component replacement" or "part replacement", the required diagnostic unit codes are retrieved and located by inspecting the components and combining them with category feature codes. Based on the diagnostic units before the design and transformation, the technical parameters of these units are modified and marked to complete the revision of the fault diagnosis units after the design and transformation. For design change development tasks output through "component addition" or "part addition" scenarios, the diagnostic path and diagnostic unit are developed based on the DTC data and part technical parameter data after the design change in the development database. The fault diagnosis process content involved in the design change point is developed, and the design change development content is marked.

Images