Diagnostic specification management system and method based on intelligent verification

Abstract

The invention provides a diagnostic specification management system and method based on intelligent verification, and belongs to the technical field of automobile diagnosis, and the system comprises a template management module which is used for storing and managing at least one first-edition diagnostic questionnaire template and is respectively adaptive to different types of electronic control units; the controller management module is used for creating a new controller project and associating a first-edition diagnosis questionnaire template for the new controller project; the resource distribution module is used for distributing diagnosis fault codes and data identifiers according to the vehicle type information on the basis of the primary diagnosis questionnaire template so as to generate an exclusive diagnosis questionnaire; the data verification module is used for automatically verifying the filled exclusive diagnosis questionnaire; and the knowledge base module is used for constructing a fault tree based on the filled exclusive diagnosis questionnaire. According to the method, the problems of low diagnostic specification design efficiency, error proneness and disordered resource allocation are solved, and standardized design, intelligent verification and knowledge-based application of the diagnostic specification are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile diagnosis, and in particular to a diagnosis specification management system and method based on intelligent verification. BACKGROUND

[0002] The development of automobile diagnosis specification is closely related to the trend of automobile electronicization and intelligentization. In the early stage, the mechanical structure of automobile is simple, and the fault mainly depends on manual experience judgment. With the popularity of electronic control unit (ECU), the complexity of vehicle-mounted electronic system has increased dramatically, and standardized diagnosis means are urgently needed. In order to quickly and accurately judge the fault and fault reason of vehicle or certain controller, and provide reliable basis for maintenance, diagnosis service is often used for session control, secure access, routine control, data identifier (DID) and diagnosis trouble code (DTC) reading, ECU software flashing (software download) between tester (client) and ECU (server).

[0003] According to ISO 14229 UDS automobile diagnosis standard protocol, different host manufacturers design different diagnosis specifications. Some host manufacturers use ISO 15031 OBD automobile diagnosis standard protocol. The existing technology has the following disadvantages: no unified diagnosis specification template is formed, and each time a new controller diagnosis questionnaire is added, the content of other controllers needs to be designed or modified from scratch, which is low in efficiency. And there is no record of historical faults, and for similar faults, it is difficult to quickly find the corresponding solution, and the maintenance personnel need to repeatedly explore, which prolongs the maintenance time.

[0004] Therefore, a system capable of intelligently designing and verifying diagnosis specification is needed to solve the above problems and improve the design efficiency and quality of diagnosis specification and provide reliable basis for maintenance. SUMMARY

[0005] The present application aims to solve at least one of the technical problems in the prior art, and provides a diagnosis specification management system and method based on intelligent verification. To solve the technical problems of low efficiency, easy to make mistakes, chaotic resource allocation and knowledge cannot be deposited in the prior art.

[0006] In a first aspect, an embodiment of the present application provides a diagnosis specification management system based on intelligent verification, comprising:

[0007] A template management module is configured to store and manage at least one initial diagnosis questionnaire template, which is adapted to different types of electronic control units respectively.

[0008] A controller management module is configured to create a new controller project and associate an initial diagnosis questionnaire template with the new controller project.

[0009] The resource allocation module allocates diagnostic fault codes and data identifiers according to vehicle model information based on the initial version of the diagnostic survey form template to generate a unique diagnostic survey form.

[0010] The data validation module is used to automatically validate the completed personalized diagnostic questionnaire.

[0011] The knowledge base module constructs a fault tree based on the completed personalized diagnostic questionnaire.

[0012] Preferably, when allocating diagnostic fault codes, the resource allocation module divides the controller into a power controller, chassis controller, body controller, and network controller, and assigns independent diagnostic fault code ranges to different controllers and different vehicle models.

[0013] Preferably, when allocating diagnostic fault codes, the resource allocation module allocates consecutive diagnostic fault code segments for the power controller, chassis controller, and body controller, and records the last diagnostic fault code allocated under each controller.

[0014] For network controllers, diagnostic fault codes are assigned according to vehicle model and message loss type, and a mapping relationship between message ID and diagnostic fault code is established.

[0015] Preferably, the data verification module is used to identify at least one of the following errors in the dedicated diagnostic survey form: Chinese colons, cell merging errors, formula compliance, empty content, numerical range errors, and missing English comments.

[0016] Preferably, the fault tree in the knowledge base module supports reverse querying based on fault phenomena to locate the specific controller, diagnostic fault code, fault cause, and solution.

[0017] Preferably, the resource allocation module generates a reminder message when it detects that the allocation range of a diagnostic fault code or data identifier has been exhausted or an allocation conflict has occurred.

[0018] Preferably, the initial version of the diagnostic questionnaire template is divided into a fixed part and a non-fixed part; the fixed part contains a general description of diagnostic services, and the non-fixed part is filled in by the user according to the specific controller.

[0019] Secondly, embodiments of the present invention provide a diagnostic specification management method based on intelligent verification, including:

[0020] Obtain the instruction to add a new controller, and allocate the corresponding initial version of the diagnostic survey form template from the template library according to the controller type;

[0021] Based on controller type and vehicle model information, assign diagnostic fault codes and data identifiers to generate a unique diagnostic questionnaire;

[0022] Automated verification based on the data from the completed personalized diagnostic questionnaire;

[0023] A fault tree is constructed based on the completed personalized diagnostic questionnaire.

[0024] Thirdly, embodiments of the present invention provide an electronic device, including:

[0025] One or more processors;

[0026] Memory, used to store one or more programs;

[0027] When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method.

[0028] Fourthly, embodiments of the present invention provide a computer-readable medium storing a computer program, which, when executed by a processor, implements the steps in the method.

[0029] This invention provides a diagnostic specification management system and method based on intelligent verification. Through initial templates and association mechanisms, it standardizes diagnostic design, significantly reducing repetitive work when adding new controllers. An automated resource allocation strategy categorized by vehicle model and system, combined with AI-powered intelligent verification, effectively avoids allocation conflicts and human error, improving design quality and efficiency. By constructing fault trees and recording historical cases, it transforms maintenance experience into structured knowledge, providing maintenance personnel with powerful intelligent diagnostic support and enabling rapid fault location. Attached Figure Description

[0030] Figure 1 A schematic diagram of the architecture module of a diagnostic specification management system based on intelligent verification provided in an embodiment of the present invention;

[0031] Figure 2 This is a schematic diagram of the diagnostic survey form template association mechanism provided in an embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of the DTC allocation method provided in an embodiment of the present invention;

[0033] Figure 4 A flowchart illustrating the diagnostic specification management method based on intelligent verification provided in an embodiment of the present invention;

[0034] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0036] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0037] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0038] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0039] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0040] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0041] There are many pain points in the existing technologies:

[0042] 1. Lack of a unified template: The absence of a standardized diagnostic template leads to inconsistent diagnostic design formats for different controllers and vehicle models, making management and maintenance difficult.

[0043] 2. High human error rate: The completion of the diagnostic questionnaire relies on manual completion, and problems such as formatting errors and typos are difficult to be effectively checked, affecting the quality of subsequent database generation.

[0044] 3. Resource allocation conflicts: When allocating resources such as Diagnostic Trouble Codes (DTCs) and Data Identifiers (DIDs), the lack of a global view and automated management can easily lead to duplicate allocation or wasted scope.

[0045] 4. Difficulty in exporting data: Well-designed diagnostic guidelines are difficult to export directly into a standard format diagnostic database, requiring additional manual conversion work, which is inefficient.

[0046] 5. Insufficient knowledge accumulation: Historical fault phenomena, causes, and solutions have not been systematically recorded and linked, failing to provide effective intelligent support for subsequent maintenance and diagnosis.

[0047] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a diagnostic specification management system based on intelligent verification, with reference to... Figures 1 to 3 As shown, it specifically includes: template management module, controller management module, resource allocation module, data validation module, and knowledge base module.

[0048] Specifically, the template management module stores and manages at least one initial diagnostic checklist template, adapted to different types of electronic control units (ECUs). The system pre-installs initial diagnostic checklist templates for different types, such as "ECUs with operating systems" and "embedded ECUs." These templates include fixed components common to all controllers, such as the diagnostic service framework, secure access procedures, and basic flashing procedures. When a professional engineer needs to design diagnostic specifications for a new body control unit, they simply select the "embedded ECU" template, and the system automatically generates a custom checklist. The engineer then only needs to fill in the non-fixed components specific to that controller, such as DTCs and DIDs.

[0049] When an engineer needs to design diagnostic specifications for a new gateway ECU (belonging to a network system, embedded type), he only needs to select the "Embedded ECU" template in the system. The system will automatically generate a questionnaire framework that includes common services (fixed parts) such as UDS session control, secure access, and DTC reading. The engineer only needs to fill in the details for the specific functions of the gateway (non-fixed parts), such as the DID definition of specific routing messages.

[0050] Creating a new diagnostic checklist for each controller by modifying the content of other controllers can be cumbersome. A better approach is to differentiate diagnostic checklist templates based on whether the controller has an operating system or is an embedded ECU. When designing a new diagnostic checklist for a new controller, an initial version template can be directly assigned according to these types. This initial version template is compatible with all corresponding controller types and is linked to them. Whenever a common section of a diagnostic checklist of the same type needs modification, only the initial version template needs to be modified.

[0051] The initial diagnostic questionnaire is a common part of all controllers, divided into fixed and non-fixed parts. It mainly includes diagnostic ID, diagnostic service, corresponding description of fault codes, reading and writing DID, flashing DID, and flashing process. The non-fixed parts, such as specific services and fault codes, need to be investigated according to the specific diagnostic and flashing needs of the controller.

[0052] The flashing process is categorized into CAN, LIN, and Ethernet. The flashing process is linked to the controller's diagnostic checklist; updating the flashing process synchronously updates the flashing process in the controller's diagnostic checklist. The flashing process mainly includes a series of steps: checking programming preconditions, disabling communication, disabling DTC settings, secure access, writing data, downloading drivers, erasing memory, downloading data again, checking programming integrity, checking programming dependencies, and finally resetting the ECU and clearing diagnostic information.

[0053] The controller management module is used to create new controller projects and associate an initial version of the diagnostic questionnaire template with the new controller project to generate a unique diagnostic questionnaire for the new controller.

[0054] The system allows users to fill in diagnostic questionnaire data for the controller to create a customized diagnostic questionnaire, identifying fixed and non-fixed parts. If an error is made, the system will automatically alert the user to the reason for the error, allowing for timely correction. Furthermore, the system's database export tool can be used to export the data into a diagnostic database for the controller.

[0055] The resource allocation module, based on the initial diagnostic survey template, allocates diagnostic fault codes and data identifiers according to vehicle model information to generate a customized diagnostic survey form. The core of this module is resource management based on two dimensions: vehicle model and controller. For example, for the "Body Controller" of "Vehicle Model A," the system allocates a DTC range of B1000-B10FF. After allocating B1005, the system automatically records B1005 as the last allocated code. The next time a DTC is allocated for this controller of the same vehicle model, the system will automatically recommend codes starting from B1006, requiring only confirmation from the engineer. For network packet loss DTCs, the system first records them by vehicle model and then allocates them within the vehicle model by packet ID, effectively avoiding DTC conflicts between different controllers.

[0056] Taking DTC allocation as an example, the specific steps include:

[0057] Step S201: The system receives a request to assign a DTC to a certain body controller.

[0058] Step S202: The resource allocation module determines that the controller belongs to the "body system".

[0059] Step S203: The system locks the DTC code range (e.g., C1000-C1FFF) assigned to the "Body System" of the vehicle model to which the controller belongs (e.g., "Type A vehicle").

[0060] Step S204: The DTC allocation unit queries the database for the last DTC code (e.g., C1105) allocated under this controller.

[0061] Step S205: The system automatically suggests the next available DTC code (C1106) to the engineer.

[0062] Step S206: After engineer confirmation, the system associates C1106 with a specific fault of the controller (such as "left front window motor overcurrent") and updates the "last DTC code" record to C1106.

[0063] If C1FFF is found to be in use during allocation, the system will execute step S207, reminding the engineer that "the allocation range will be exhausted, please expand the DTC allocation range of this controller".

[0064] When assigning DTC codes, the controllers are first divided into three system controllers: powertrain system, chassis system, and body system. Then, for DTCs belonging to the network system, the message loss type of the controller is assigned according to two main categories: message sending timeout or message receiving timeout.

[0065] DTC codes for controllers belonging to the powertrain, chassis, and body systems are assigned according to vehicle model. Different models share the same assigned range, thus resolving the issue of wasted DTC codes when assigning codes to different models. For the same controller, the assigned DTC ranges for different models are recorded. After each assignment, the system automatically records and displays the last assigned DTC code, allowing subsequent assignments to continue from this last code, reducing the time spent searching for the last DTC. When adding a new controller, or when a controller's range has been exhausted, the range can be reassigned, typically from 00 to FF. It's crucial that this range doesn't include ranges already used in the standard; if duplicates occur, the system will automatically alert the user. When a professional reports the need to add a controller, the system automatically assigns a fault code based on the last recorded assigned fault code and the controller's assigned range. The professional only needs to determine the fault subtype based on the fault description. If there are insufficient assigned codes, the system automatically alerts the user to expand the controller's assigned range.

[0066] Network systems typically assign Data Transmission Control (DTC) codes to the controller that lost a packet based on its ID. However, this assignment process often results in duplicate assignments, meaning a single packet ID may correspond to different DTCs. Because the range of DTCs assigned to a single controller for a single packet loss is relatively small, it frequently encroaches on the range of DTCs for other controllers with different packet loss types. Furthermore, due to differences in vehicle models, the assignments can appear chaotic. Therefore, for a controller's packet loss type, it should first be recorded by vehicle model, with each model containing the lost packet ID and its corresponding DTC code. Secondly, if all DTC codes have been assigned, a new controller with the same packet loss type can be added, clearly marked, and DTC codes reassigned. This avoids encroaching on the DTC range of other packet loss types.

[0067] In addition to standard DIDs, the system allows for custom DID allocation ranges for each controller, assigning and recording DID codes assigned to each vehicle model. After each allocation, the system automatically records and displays the last assigned DID code, allowing subsequent allocations to continue from this last code, thus reducing the time spent searching for the last DID code.

[0068] The data validation module is used to automatically validate the completed personalized diagnostic questionnaire, identify format errors, typos, logical contradictions and compliance issues, and generate error reports.

[0069] The process begins after the engineer completes the questionnaire. The verification unit uses built-in AI models (e.g., trained natural language processing models and rule engines) to scan the form content. For example, it will identify a typo, such as "safety access" instead of "safety door," and report errors like "DID data length field is empty" and "English annotation for the DID speed signal is missing." After the engineer corrects the errors based on the reports, the export unit can export all the data to standard diagnostic database files such as CDD (CANdelaDiagnostic Description) or ODX (Open Diagnostic data eXchange) with a single click.

[0070] The system's validation algorithm, combined with AI tools, can identify formatting errors and typos, generating an error document. The algorithm can also detect Chinese colons in tables, whether cells need to be merged, whether conversion formulas are compliant, whether cells are empty, whether they are within the specified range, and whether English comments are missing, among other things.

[0071] This module integrates a text validation algorithm and rule engine based on a large model. As engineers fill out the survey form, the system checks in real time:

[0072] Formatting compliance: such as whether cells should be merged, whether English comments are missing, and whether formulas are correct.

[0073] Content accuracy: Utilize large models to identify issues such as typos and semantic incoherence.

[0074] Logical consistency: Checks whether the DTC description matches the category, and whether the DID read / write permissions are reasonable. The system will highlight all errors and generate detailed error reports, which engineers can correct with one click.

[0075] The knowledge base module constructs a fault tree based on the completed personalized diagnostic questionnaire.

[0076] The knowledge base stores historical fault phenomena, corresponding causes, solutions, and associated controllers and diagnostic fault codes, and constructs fault trees. Based on professional feedback and diagnostic surveys, fault trees for common controller faults are designed. By examining the corresponding fault trees under each controller, the specific fault causes and their weights can be identified. Furthermore, for frequently occurring faults in different vehicle models, the specific controller, cause, and solution can be located, and a corresponding fault tree can be designed based on this information. If the same fault phenomenon recurs, historical faults and solutions can be retrieved from the system, allowing repair personnel to quickly pinpoint the source of the fault.

[0077] When a "Type B vehicle" exhibits a "fail to start" malfunction, the repair technician can input this symptom into the system's fault tree interface. The system retrieves a preset fault tree, with the root node being the symptom "fail to start." Sub-nodes list possible causes, such as "insufficient battery power" (weight 20%), "starter motor failure" (weight 35%), and "engine ECU no communication" (weight 45%). The weights represent the likelihood of the cause leading to the malfunction. Clicking the "engine ECU no communication" node further displays its sub-causes, such as "ECU power supply fuse blown" and "CAN bus communication timeout." Simultaneously, the interface displays historical cases, recording a past "fail to start" malfunction caused by "CAN bus communication timeout," whose solution was "check and repair the open circuit in the CAN harness from the gateway to the engine ECU." This greatly assists the repair technician in fault location and decision-making.

[0078] This module constructs a dynamic fault tree knowledge base. When a vehicle model frequently experiences the "window cannot be raised or lowered" fault, the system records the associated controller (window control module), DTC (such as B1234), possible causes (motor failure, short circuit, etc.), and solutions. The next time the same phenomenon occurs, repair personnel can search for "window cannot be raised or lowered" in the system, and the system will directly push the relevant fault tree and solutions, greatly shortening the diagnosis time.

[0079] In another implementation, the management system also includes a database export module for exporting validated, proprietary diagnostic questionnaires into a standardized diagnostic specification database. After the questionnaire design, validation, and review are complete, engineers can use this module to export the data with a single click into a diagnostic database file conforming to standards such as ODX (Open Diagnostic Data Exchange), which can then be directly used for diagnostic instrument development or ECU code generation, achieving a seamless transition from design to application.

[0080] It should be noted that the specific vehicle models, DTC codes, DIDs, etc. mentioned in this embodiment are merely examples, and actual applications can be adjusted according to the specifications of different OEMs. This invention, through the synergy of the above modules and methods, constructs a closed-loop, intelligent diagnostic specification lifecycle management solution.

[0081] The management system provided by this invention can solve the problem of repeatedly modifying the diagnostic survey form by setting an initial version template. The initial version template is compatible with all controllers. If a diagnostic survey form for a new controller is needed, the diagnostic ID of the controller can be directly assigned based on the initial version. Subsequently, the fault codes, DID, RID and other contents of the controller diagnostic survey form are updated based on professional feedback.

[0082] When assigning DTCs, the system allocates controller ranges according to different vehicle models. It automatically records the numbers after each assignment. The next time a new DTC is assigned, the system continues from the last assigned DTC number, improving allocation efficiency. Custom DIDs are assigned similarly, based on different vehicle models, and the system automatically records the last DID code after each assignment.

[0083] In addition, the management system is equipped with a verification algorithm that can promptly remind users of professional errors, thereby reducing development errors and improving filling efficiency. Furthermore, the management system's database export module can directly export the filled forms into a diagnostic specification database, further improving efficiency.

[0084] The fault tree in the management system records historical fault phenomena, including the corresponding controller, the corresponding solution, and common faults associated with that controller. Based on the fault tree, the cause of the fault can be easily identified. If similar fault phenomena occur later, the corresponding faulty controller and solution can be found by searching within the management system.

[0085] See Figure 4 Based on the same inventive concept, embodiments of the present invention also provide a diagnostic specification management method based on intelligent verification, for implementing the above-mentioned management system, including:

[0086] S1. Obtain the instruction to add a new controller, and allocate the corresponding initial version of the diagnostic survey form template from the template library according to the controller type.

[0087] The initial version of the diagnostic questionnaire template is pre-stored in the template library. The template library is the template management module in the management system. Generally, there are multiple initial version diagnostic questionnaire templates. You can select the corresponding initial version diagnostic questionnaire template according to the type of new controller.

[0088] S2. Assign diagnostic fault codes and data identifiers according to controller type and vehicle model information to generate a unique diagnostic questionnaire.

[0089] Based on the initial diagnostic questionnaire template, the fault codes, DIDs, RIDs, and other information in the controller diagnostic specifications are updated to generate a custom diagnostic questionnaire corresponding to the controller. Furthermore, when assigning DTCs, the controller range is allocated according to different vehicle models, and the numbers after each assignment are automatically recorded. In the next assignment, new fault codes are assigned using the DTC numbers from the previous assignment, improving allocation efficiency. Custom DIDs are assigned similarly, allowing allocation according to different vehicle models, and the last DID code is automatically recorded after allocation.

[0090] S3. Automated validation based on the data from the completed personalized diagnostic questionnaire.

[0091] For the dedicated diagnostic questionnaire, the diagnostic questionnaire data of the controller can be filled in directly, and an AI model can be used to scan the content of the form to identify formatting errors, typos and errors and generate an error document.

[0092] For the verified data from the dedicated diagnostic questionnaire, a unified template can be used to export the data into a diagnostic specification database for the controller.

[0093] S4. Construct a fault tree based on the completed personalized diagnostic questionnaire.

[0094] Based on engineer feedback and diagnostic surveys, a fault tree for common controller malfunctions was designed. This fault tree allows identification of the corresponding fault causes and their weights. Furthermore, for frequently occurring faults across different vehicle models, the specific controller, cause, and solution can be identified, and a corresponding fault tree can be designed based on this information. If the same fault recurs, historical faults and solutions can be retrieved from the system, enabling engineers to quickly pinpoint the source of the problem.

[0095] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement a diagnostic specification management method based on intelligent verification as described in the above embodiment; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0096] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0097] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0098] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0099] This invention also provides a computer-readable medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the steps of a diagnostic specification management method based on intelligent verification.

[0100] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0101] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0103] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A diagnostic specification management system based on intelligent verification, characterized in that, include: The template management module is used to store and manage at least one initial version of the diagnostic questionnaire template, which is adapted to different types of electronic control units. The controller management module is used to create new controller projects and associate an initial version of the diagnostic questionnaire template with the new controller project. The resource allocation module allocates diagnostic fault codes and data identifiers according to vehicle model information based on the initial version of the diagnostic survey form template to generate a unique diagnostic survey form. The data validation module is used to automatically validate the completed personalized diagnostic questionnaire. The knowledge base module constructs a fault tree based on the completed personalized diagnostic questionnaire.

2. The system according to claim 1, characterized in that, When allocating diagnostic fault codes, the resource allocation module divides the controller into power controller, chassis controller, body controller and network controller, and assigns independent diagnostic fault code ranges to different controllers and different vehicle models.

3. The system according to claim 2, characterized in that, When allocating diagnostic fault codes, the resource allocation module allocates consecutive diagnostic fault code segments for the power controller, chassis controller, and body controller, and records the last diagnostic fault code allocated under each controller. For network controllers, diagnostic fault codes are assigned according to vehicle model and message loss type, and a mapping relationship between message ID and diagnostic fault code is established.

4. The system according to claim 1, characterized in that, The data verification module is used to identify at least one of the following errors in the dedicated diagnostic survey form: Chinese colons, cell merging errors, formula compliance, empty content, numerical range errors, and missing English comments.

5. The system according to claim 1, characterized in that, The fault tree in the knowledge base module supports reverse lookup based on fault symptoms to locate the specific controller, diagnostic fault code, fault cause, and solution.

6. The system according to claim 1, characterized in that, The resource allocation module generates a reminder message when it detects a diagnostic fault code or that the allocation range of a data identifier has been exhausted or an allocation conflict has occurred.

7. The system according to claim 1, characterized in that, The initial version of the diagnostic questionnaire template is divided into fixed and non-fixed parts; the fixed part contains a general description of the diagnostic services, while the non-fixed part is for users to fill in according to the specific controller.

8. A diagnostic specification management method based on intelligent verification, characterized in that, include: Obtain the instruction to add a new controller, and allocate the corresponding initial version of the diagnostic survey form template from the template library according to the controller type; Based on controller type and vehicle model information, assign diagnostic fault codes and data identifiers to generate a unique diagnostic questionnaire; Automated verification based on the data from the completed personalized diagnostic questionnaire; A fault tree is constructed based on the completed personalized diagnostic questionnaire.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the steps of the method as described in claim 8.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method as described in claim 8.

Images