Domain control architecture-based vehicle control fault diagnosis method, device and product

Abstract

The application provides a vehicle control fault diagnosis method, device and product under a domain control architecture. The method comprises the following steps: receiving a terminal device to send a vehicle identifier, a fault description and a fault time; according to the vehicle identifier, obtaining message data and log data of a time period in which the fault time is located from a fault vehicle; according to the fault description, obtaining target standard link information corresponding to a target function which occurs a fault from a pre-constructed function specification knowledge base; the function specification knowledge base is a knowledge base including standard link information of each function and is constructed based on various function specification documents of a vehicle; according to the message data and the log data and the target standard link information, performing fault diagnosis to obtain a fault diagnosis result; and returning the fault diagnosis result to the terminal device. The method is used to improve the accuracy of fault root cause positioning and the diagnosis efficiency under the domain control architecture, and reduce the artificial troubleshooting cost.

Description

Technical Field

[0001] This application relates to the field of vehicle fault diagnosis, and in particular to a method, device and product for diagnosing vehicle control faults under a domain control architecture. Background Technology

[0002] As automotive electronic and electrical architecture evolves from distributed electronic control units (ECUs) to a domain-centralized approach, the vehicle domain controller has become the core of vehicle control. Under this domain-controlled architecture, multiple subsystems, such as the powertrain, chassis, and cockpit domains, need to work collaboratively, significantly increasing system integration and complexity. This places higher demands on the fault diagnosis and localization capabilities of vehicle control systems, making intelligent fault analysis technology a growing research hotspot in the industry.

[0003] In the existing technology, the fault analysis method of vehicle domain controller mainly adopts the following approach: obtaining vehicle domain controller information, obtaining control interaction system information based on the functional analysis of vehicle domain controller, and then comparing and matching the control interaction system operation information and control command information with preset fault rules and diagnostic fault codes to determine whether the vehicle domain controller has a fault and the type of fault.

[0004] However, the above-mentioned rule-based and diagnostic code-based comparison and matching method is difficult to quickly and accurately locate the root cause of the fault. Summary of the Invention

[0005] This application provides a method, device, and product for diagnosing vehicle control faults under a domain control architecture, in order to output diagnostic results for vehicle control faults and improve the fault root cause localization effect in multi-controller collaborative scenarios.

[0006] In a first aspect, embodiments of this application provide a method for diagnosing vehicle control faults under a domain control architecture, including:

[0007] Receive fault information sent by the terminal device, which includes vehicle identification, fault description and fault time;

[0008] Based on the vehicle identification, retrieve message data and log data for the time period of the fault from the faulty vehicle;

[0009] Based on the fault description, the target standard link information corresponding to the target function that caused the fault is obtained from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple vehicle functional specification documents, including standard link information for each function;

[0010] Based on the message data, log data, and target standard link information, fault diagnosis is performed to obtain the fault diagnosis results;

[0011] The fault diagnosis results are returned to the terminal device.

[0012] In one possible implementation, based on the fault description, the target standard link information corresponding to the target function that has failed is obtained from a pre-built functional specification knowledge base, including:

[0013] By using a pre-trained fault handling model, the target function that is faulty in the fault description is identified, and the function is matched in the functional specification knowledge base according to the target function to obtain the target standard link information.

[0014] Among them, the fault handling model is a fault analysis model trained based on a large language model, historical fault data of various vehicles, historical operation and maintenance data, and R&D test data.

[0015] In one possible implementation, fault diagnosis is performed based on message data, log data, and target standard link information to obtain fault diagnosis results, including:

[0016] Based on the message data, obtain the actual codes of multiple signals of the faulty vehicle during the time period of the fault.

[0017] Based on the log data, obtain the records of the actions performed by the faulty vehicle during the time period in which the fault occurred;

[0018] Based on the actual encoding of multiple signals, the execution action record, and the target standard link information, fault diagnosis is performed to obtain the fault diagnosis results.

[0019] In one possible implementation, the target standard link information includes: the standard control link corresponding to the target function, the standard encoding of each node signal in the standard control link, and the signal interaction process.

[0020] Based on the actual encoding of multiple signals, action records, and target standard link information, fault diagnosis is performed to obtain fault diagnosis results, including:

[0021] Based on the actual encoding of multiple signals, the action record is executed, the standard encoding of each node signal in the standard control link and the signal interaction process are standardized, and the link-level signal comparison analysis is performed to obtain the fault diagnosis result.

[0022] In one possible implementation, the fault diagnosis results include at least one of the following information:

[0023] Faulty node, control link where the faulty node is located, fault diagnosis basis, and fault handling method.

[0024] In one possible implementation, based on the message data, the actual encoding of multiple signals of the faulty vehicle during the time period of the fault is obtained, including:

[0025] Obtain the CAN database file (Database CAN, abbreviated as DBC) corresponding to the faulty vehicle;

[0026] The message data is decoded based on the DBC decoding file to obtain the actual encoding of multiple signals of the faulty vehicle during the time period of the fault.

[0027] In one possible implementation, based on the vehicle identifier, message data and log data for the time period of the fault are obtained from the faulty vehicle, including:

[0028] Based on the vehicle identification, a data acquisition request is sent to the vehicle's onboard telematics box (T-Box), and the data acquisition request includes the time of the malfunction.

[0029] Receive message data and log data from the faulty vehicle indicating the time period of the fault.

[0030] Secondly, embodiments of this application provide a diagnostic device for vehicle control faults under a domain control architecture, comprising:

[0031] The receiving module is used to receive fault information sent by the terminal device. The fault information includes vehicle identification, fault description and fault time.

[0032] The acquisition module is used to obtain message data and log data for the time period of the fault from the faulty vehicle based on the vehicle identifier;

[0033] Processing module, used for:

[0034] Based on the fault description, the target standard link information corresponding to the target function that caused the fault is obtained from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple vehicle functional specification documents, including standard link information for each function;

[0035] Based on the message data, log data, and target standard link information, fault diagnosis is performed to obtain the fault diagnosis results;

[0036] The sending module is used to return the fault diagnosis results to the terminal device.

[0037] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and an interaction interface;

[0038] The memory stores computer-executed instructions;

[0039] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0041] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0042] The vehicle control fault diagnosis method, device, and product provided in this application embodiment under a domain control architecture receive fault information sent by a terminal device, including vehicle identification, fault description, and fault time. Based on the vehicle identification, the method obtains message data and log data of the faulty vehicle during the time period of the fault. Simultaneously, based on the fault description, the method obtains the target standard link information corresponding to the target function of the fault from a pre-built functional specification knowledge base. This enables the effective association of fault phenomena, fault timing range, vehicle operation data, and functional standard links. Fault diagnosis is then performed based on message data, log data, and target standard link information, thereby improving the efficiency and accuracy of fault root cause location in multi-controller collaborative scenarios under a domain control architecture. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0044] Figure 1 A schematic diagram illustrating a data acquisition scenario under the domain controller architecture provided in this application;

[0045] Figure 2 A flowchart illustrating the first embodiment of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 1 ;

[0046] Figure 3 A flowchart illustrating Embodiment 2 of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 2 ;

[0047] Figure 4 A flowchart illustrating Embodiment 3 of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 3 ;

[0048] Figure 5 A flowchart illustrating Embodiment 4 of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 4 ;

[0049] Figure 6 A flowchart illustrating Embodiment 5 of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 5 ;

[0050] Figure 7 A flowchart illustrating Embodiment Six of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 6 ;

[0051] Figure 8 A flowchart illustrating Embodiment Seven of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 7 ;

[0052] Figure 9 This is a schematic diagram of the vehicle control fault diagnosis device under the domain control architecture provided in this application.

[0053] Figure 10 A schematic diagram of the structure of an example electronic device provided in this application.

[0054] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0056] First, let me explain the terms used in this application:

[0057] Domain control architecture: refers to the vehicle's electronic and electrical architecture that integrates the functions of traditional ECUs, divides them according to vehicle functional domains (such as power domain, chassis domain, cockpit domain, autonomous driving domain, etc.), and centrally manages and controls them by the corresponding domain controllers.

[0058] Vehicle domain controller: refers to a controller installed on a vehicle for centralized control, data interaction and decision processing of one or more ECUs within its functional domain.

[0059] Functional specification documents: Functional specification documents include, but are not limited to, one or more of the following: system requirements specification, functional design document, interface specification document, and domain controller function allocation document.

[0060] T-Box: refers to a remote communication terminal installed in a vehicle, used to enable data transmission and reception between the vehicle and a cloud server.

[0061] ECU: refers to the electronic control unit in a vehicle used to implement specific control functions (such as engine control, brake control, window control, etc.).

[0062] Fault handling model: refers to a fault analysis model trained based on a large language model, historical fault data of various vehicles, historical operation and maintenance data, and R&D test data.

[0063] Vehicle identification refers to information used to uniquely identify a vehicle, including but not limited to one or more of the following: Vehicle Identification Number (VIN), license plate number, and device serial number.

[0064] DBC: refers to a standard file used to describe the message and signal definitions in the Controller Area Network (CAN) communication protocol, used to parse raw message data into engineering values ​​with physical meaning.

[0065] Link information refers to the relevant information of each node in the complete control link through which the vehicle function goes from signal input to control output. The nodes include at least one of sensors, controllers, and actuators. The link information includes at least the identifier of each node, the order of signal interaction between nodes, and the signal encoding rules.

[0066] Standard coding refers to the predefined standard coding values ​​for signals at each node in the control link in the functional specification document, which are used to characterize the expected values ​​of the signals under normal operating conditions.

[0067] Actual encoding: refers to the actual encoded values ​​of each node signal obtained by parsing the message data uploaded by the vehicle through the DBC file, which is used to characterize the actual value of the signal during actual operation.

[0068] A knowledge management platform refers to a collaborative knowledge management platform used to centrally manage information such as documents, technical specifications, and design materials, supporting version tracking and access control. In this application, functional specification documents can be stored on this platform for centralized management, retrieval, and version maintenance.

[0069] Figure 1 This is a schematic diagram illustrating a data acquisition scenario under the domain controller architecture provided in this application, such as... Figure 1As shown, this application involves multiple functional domains of the vehicle, including the powertrain domain, chassis domain, and cockpit domain. Each functional domain is controlled collaboratively by its corresponding domain controller or area controller. During vehicle operation, data acquisition software deployed on each area controller (Z-ECU) continuously collects raw message data from subordinate ECUs and log data generated during its own operation, adding a timestamp to each data entry. Each area controller aggregates the collected data to the vehicle-side T-Box via Ethernet or other means, and the data is stored locally on the vehicle. When fault diagnosis is required, the terminal initiates a data retrieval request to the T-Box as needed. The T-Box responds to the request and uploads the corresponding data to the cloud platform for use by technical personnel for fault diagnosis.

[0070] Based on the above scenarios, it is evident that existing technologies, which compare and analyze collected communication messages, operational status information, and diagnostic fault codes using a pre-defined rule base and determine the fault type based on the fault codes or abnormal signals, suffer from the following technical problems: Existing fault diagnosis methods rely on static rule bases and fault code matching methods. In a domain control architecture, the implementation of a complete function often involves chain interactions between multiple controllers. Static rules are difficult to fully reflect the control links corresponding to the target function. In cross-controller collaborative scenarios, it is easy to only identify superficial anomalies and fail to determine the actual fault node. At the same time, existing solutions fail to utilize functional specification documents to assist in fault location, making it difficult to effectively associate fault phenomena described in natural language with functional links. The diagnosis process is time-consuming, affecting both the efficiency and accuracy of fault diagnosis and further increasing processing costs.

[0071] This application provides a method for diagnosing vehicle control faults under a domain control architecture. This method involves receiving fault information including vehicle identification, fault description, and fault time; obtaining message data and log data for the time period of the fault based on the vehicle identification; retrieving target standard link information corresponding to the target function from a pre-built functional specification knowledge base based on the fault description; and combining the message data, log data, and target standard link information to perform fault diagnosis, obtaining the fault diagnosis result, and returning it to the terminal device. This method effectively associates fault descriptions, vehicle operating data, and functional standard links, solving the technical problems of low efficiency and poor accuracy in fault diagnosis caused by the inability of static rule bases to cover dynamic collaborative links across controllers, low utilization of functional specification document content, and difficulty in automatically associating fault descriptions with functional links in existing technologies.

[0072] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0073] Figure 2 A flowchart illustrating the first embodiment of the vehicle control fault diagnosis method under the domain control architecture provided in this application. Figure 1 ,like Figure 2 As shown, the method includes:

[0074] S201. Receive fault information sent by the terminal device, which includes vehicle identification, fault description and fault time.

[0075] In this application, the domain control architecture is used to define the vehicle's electronic and electrical system environment where the fault diagnosis object is located. Within this environment, the powertrain domain, chassis domain, cockpit domain, and other vehicle control-related functional domains form a collaborative control relationship through domain controllers, execution control units, and communication networks. Subsequent message data and log data all originate from the operational process within this architecture. The terminal device, as the data interaction party in the fault diagnosis process, is used both to initiate fault information reporting and to receive feedback on diagnostic results. Fault information is the initial input to the diagnostic process and includes at least the vehicle identifier, fault description, and fault time. The vehicle identifier is used to uniquely identify the faulty vehicle; this identifier can be a VIN or other unique identifier. The fault description is natural language text entered by technicians to express the abnormal phenomena occurring in the vehicle. The fault time is used to define the time point or time period when the fault occurred or was perceived by the user, serving as a benchmark for subsequently extracting operational data for the target time period.

[0076] In practical implementation, this solution can be executed via a private cloud server and / or domain controller diagnostic platform, or diagnostic equipment. The terminal device sends fault information to the diagnostic platform or diagnostic equipment via an application programming interface (API), message queue, web form, or dedicated diagnostic client. During the receiving process, the diagnostic platform or diagnostic equipment performs structured parsing of the uploaded data, mapping the vehicle identifier to an internal vehicle index, converting the fault time to a unified time format, and retaining the original fault description to support subsequent processing. In one possible embodiment, the fault time is the specific time directly input by the terminal device.

[0077] Based on the above analysis, this step ensures that the fault phenomenon, target vehicle, and time constraints are uniformly expressed before entering the diagnostic process, thereby guaranteeing that subsequent data extraction and standard link matching have a consistent input benchmark.

[0078] S202. Based on the vehicle identification, obtain the message data and log data for the time period in which the fault occurred from the faulty vehicle.

[0079] In this application, the diagnostic platform or diagnostic equipment locates the faulty vehicle based on the vehicle identifier and requests data from the faulty vehicle. This data request should specify the time period for the required data. The time period in which the fault occurred can be set with an analysis window based on the function type, covering the complete process of triggering, execution, and feedback. Specifically, the fault time can be used as the center, with preset durations taken both forward and backward as the data acquisition window, i.e., the time period in which the fault occurred. In another possible embodiment, the fault time is a time interval, and this interval is directly used as the data acquisition range, i.e., the aforementioned time period.

[0080] The diagnostic platform or equipment receives message data and log data from the faulty vehicle, covering the time period in which the fault occurred. The message data characterizes the communication content, link interaction sequence, and signal transmission relationships between multiple controllers during the fault period. The log data records the controller software's state transitions, control decisions, execution feedback, and anomaly information during operation. Together, they form the data foundation for subsequent fault diagnosis.

[0081] In practice, the diagnostic platform or diagnostic equipment sends a data acquisition request to the T-BOX of the faulty vehicle based on the vehicle identifier. The faulty vehicle then extracts the message data and log data for the corresponding time period from the vehicle's storage based on the fault time carried in the request and returns them.

[0082] S203. Based on the fault description, obtain the target standard link information corresponding to the target function that caused the fault from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple functional specification documents of the vehicle, including standard link information for each function.

[0083] In this application, the functional specification knowledge base is used to store the standard control link information that each vehicle function should meet under normal design conditions. Various vehicle functional specification documents serve as the source for constructing this knowledge base. These documents include, but are not limited to, system requirements specifications, functional design documents, interface specification documents, and domain controller function allocation documents. By structuring these documents, this application can extract the triggering conditions, participating controllers, input signals, output signals, message interaction sequence, state transition relationships, execution actions, and feedback conditions corresponding to each function, thereby forming standard control link information. The target function represents the specific vehicle control function indicated by the fault description, and the target standard link information is the standard control link information corresponding to that target function in the knowledge base, which can serve as a reference for subsequent fault diagnosis.

[0084] In practical implementation, the functional specification knowledge base can be pre-established as a graphical or structured data model. Taking a graphical model as an example, functional nodes, controller nodes, signal nodes, message nodes, action execution nodes, and status nodes are connected through associations to form a complete standard control link. Taking a structured model as an example, the above information can be stored using function tables, link tables, node tables, and signal mapping tables. In this step, the diagnostic platform or diagnostic equipment identifies the function based on the fault description and retrieves the corresponding target function from the functional specification knowledge base. After obtaining the target function, it further extracts the target standard link information associated with that function from the functional specification knowledge base. After extraction, the standard link information includes the sequence of controller nodes involved in the function and the signal transmission relationships between nodes. Based on the above analysis, this step will call the knowledge base to obtain the standard link according to the fault description, allowing fault localization to revolve around the standard control link of the target function in multi-controller collaboration.

[0085] S204. Based on the message data, log data, and target standard link information, perform fault diagnosis and obtain the fault diagnosis results.

[0086] In this application, fault diagnosis is an analytical process that compares and correlates actual operational data with standard control links. The standard control link in the target standard link information characterizes the control path of the target function under normal conditions. Message data reflects the actual transmission of each signal and message in this control path, and log data reflects the actual operation of participating nodes. The fault diagnosis result is the final diagnostic conclusion. The core of this step lies in using the target function as the main thread, correlating message data and log data with the standard control link, and identifying abnormal links that deviate from the standard control link.

[0087] In practice, the diagnostic platform or equipment correlates the message and log data obtained in S202 with the standard link information obtained in S203, and diagnoses the message and log data within the target time period based on the target standard link information to determine the abnormal location in the faulty link and obtain the fault diagnosis result. Based on the above analysis, it can be seen that by comparing actual operating data with the standard control link of the target function, fault-related abnormal links can be identified under the domain control architecture, enabling vehicle control fault diagnosis and obtaining the fault diagnosis result.

[0088] S205. Return the fault diagnosis results to the terminal device.

[0089] In this application, the fault diagnosis result is returned as the final output information to the terminal device that initiated the request, enabling the terminal device to complete display, storage, work order association, or subsequent maintenance processing. In this step, in addition to displaying the result, the terminal device can also trigger the next processing action on the business side based on the returned content. The fault diagnosis result includes at least one of the following information: the faulty node, the control link where the faulty node is located, the basis for fault diagnosis, and the fault handling method.

[0090] In practice, after generating a fault diagnosis result, the diagnostic platform or device encapsulates the result into a response message and returns it to the terminal device. If the terminal device calls the diagnostic service via an interface, the response message is returned as an interface response message; if the terminal device accesses the service via message subscription, the result is written to the message channel and retrieved or pushed to the terminal device; if the terminal device is a graphical diagnostic client, the display information corresponding to the diagnostic result can be returned synchronously. After the result is returned, the system can also associate and archive the fault diagnosis result with the original fault request and the original data to form a traceable diagnostic record. Based on the above analysis, this step enables the diagnostic conclusion to be transmitted back to the actual business scenario and used, forming a closed-loop processing flow from fault reporting, data extraction, fault diagnosis to result feedback.

[0091] This application provides a method for diagnosing vehicle control faults under a domain control architecture. It first receives the vehicle identifier, fault description, and fault time reported by process personnel or vehicle owners. Then, it retrieves the vehicle's stored operation records and error logs for the corresponding time period using the vehicle identifier. Simultaneously, it matches the corresponding target function from a pre-built functional specification knowledge base based on the fault description and finds the standard control steps that should be executed when the function is working normally. The obtained actual operation records are then compared with these standard steps one by one to automatically determine the specific step where the anomaly occurred. Finally, the diagnostic conclusion is returned to the front-end technical personnel. This method eliminates the need for technical personnel to manually consult manuals or check logs for each controller. The system automatically associates the fault phenomenon, operation data, and standard procedures, directly providing the fault location and cause, saving time and preventing missed faults.

[0092] Figure 3 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the embodiments, the process of obtaining target standard link information from the functional specification knowledge base according to the fault description is described in detail. The method includes:

[0093] S301. Identify the target function that is malfunctioning in the fault description using a pre-trained fault handling model.

[0094] In this step, after obtaining the fault description, the model first extracts features such as the function name, abnormal phenomenon, and controlled object from the description, and determines the function category to which the target function belongs based on the feature vector. The fault handling model is a fault analysis model trained using a large language model, historical fault data from various vehicles, historical maintenance data, and R&D test data.

[0095] In practice, the dataset construction and model training for the fault handling model are completed in advance: historical vehicle control system fault cases, test problem reports, and on-site operation and maintenance problem records of various vehicles are collected, including fault analysis experience during the development process and HIL bench test data. Simulation messages of various components generated during the R&D and testing phases are also included as the raw data for model training. The above multi-source data is preprocessed, including cleaning and format normalization, and then the model is trained to obtain a usable fault handling model. When actually performing fault identification, after obtaining the fault description text, the model first completes text preprocessing and semantic parsing, accurately extracting key features such as function names, abnormal behaviors, and controlled objects. The extracted multi-dimensional features are converted into a unified feature vector, and then feature matching is completed based on the classification knowledge and correlation learned during training to accurately identify the target function corresponding to the current fault and its functional category.

[0096] S302. Based on the target function, perform function matching in the functional specification knowledge base to obtain the target standard link information.

[0097] In this step, after determining the functional category of the target function, the corresponding functional entries are retrieved from the functional specification knowledge base. Functional matching is completed and target standard link information is output. The matching process directly establishes the correspondence between fault description and functional specification. Subsequently, joint diagnosis can be performed based on the target standard link information, message data, and log data.

[0098] In practice, the functional specification knowledge base is built in advance. By connecting to the knowledge management platform, specifically by calling the open data interface of the knowledge management platform, the corresponding graphic and textual specification page data of the vehicle control domain control system is loaded in batches. This includes system requirements specification, functional design documents, interface specification documents, domain controller function allocation documents, and other materials. At the same time, the system block diagram and functional link diagram accompanying the documents are extracted.

[0099] By performing structured parsing of the original documents, key information such as functional nodes, functional relationships, hardware and software input / output interfaces, and performance constraints is accurately extracted. Combined with a fault handling model, this information is used to learn document semantics, contextual relationships, and functional links in diagrams. Dedicated keyword index tags are configured for each vehicle function, control signal, and transmission link, forming a structured and rapidly searchable functional specification knowledge base. During fault diagnosis, the fault handling model uses this knowledge base to quickly retrieve corresponding functional entries based on the identified target functional category. Accurate matching is achieved through tag index matching and functional link logic verification, outputting target standard link information and establishing a mapping relationship between fault phenomena and official functional specifications. This solution automatically completes fault semantic parsing and target function identification through a pre-trained model, replacing the traditional process of manual disassembly and retrieval, significantly improving the efficiency of early fault location and lowering the threshold for manual diagnosis. The fault training model can cover a wide range of fault descriptions and scenarios, with high accuracy in function identification and strong scenario adaptability, providing a precise and reliable standard benchmark for subsequent fault diagnosis based on vehicle messages and operation logs.

[0100] Figure 4 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 3 ,like Figure 4 As shown, in this embodiment... Figure 2 Based on the embodiments, the process of fault diagnosis based on message data, log data, and target standard link information is described in detail. This method includes:

[0101] S401. Based on the message data, obtain the actual codes of multiple signals of the faulty vehicle during the time period of the fault.

[0102] In this step, the message data is obtained through the data acquisition software program on the regional controller, and it carries a timestamp. According to the instructions of the cloud platform, the data is divided into time periods according to the time of the fault, the messages related to the target function are extracted and parsed, the actual codes of multiple signals are parsed out, and they are associated and stored according to the signal identifier and sampling time stamp.

[0103] In practice, the DBC file predefines the vehicle signal and its functional meaning corresponding to each bit segment in the original message, and there is a one-to-one mapping relationship between the encoded value and the functional status. The fault handling model decodes the original message according to the mapping rules between bits and signals / functions in the DBC file, and presents the parsing results in the form of key-value pairs of "signal name - actual code". Then, using the signal names contained in the target standard link information in the functional specification knowledge base as indexes, the actual codes of the corresponding signals are extracted one by one from the decoding results, completing the conversion of message data to actual codes.

[0104] S402. Based on the log data, obtain the records of the actions performed by the faulty vehicle during the time period in which the fault occurred.

[0105] In this step, log data and message data are different types of data sources. Log data records the operational events and status changes generated by each controller in the vehicle during the execution of control commands. The log data is retrieved according to the time period of the fault. Based on the controller log fields, event timestamps, and function identifiers, the execution action records related to the target function are extracted. The execution action records include at least the action name, triggering condition, execution result, and exception flag.

[0106] In practice, log data and message data are acquired synchronously through the same data acquisition link, using data acquisition software on the regional controller. This is primarily used to assist in verifying the actual execution of the target function within the time period of the fault. After extracting the execution action records, they are arranged according to time sequence and associated with each control node in the target standard link information for quick retrieval during subsequent diagnostics.

[0107] S403. Based on the actual encoding of multiple signals, execution action records, and target standard link information, perform fault diagnosis to obtain fault diagnosis results.

[0108] In this step, the actual codes of multiple signals acquired in S401 and the execution action records acquired in S402 are jointly analyzed with the standard control link, the standard codes of signals of each node, and the signal interaction process in the target standard link information. By comparing the actual signal status with the expected status of each node in the standard link one by one, and combining the control command execution status reflected in the execution action records, it is determined whether the actual operating status of the target function during the time period of the fault is consistent with the expectation. Finally, a diagnostic result containing the fault node and fault type is output.

[0109] In practical implementation, based on the standard control link defined by the target standard link information, the standard encoding of each node's signal, and the signal interaction process, the actual encoding of multiple signals is compared node-by-node with the expected encoding of each node in the standard link. Simultaneously, the triggering order, timing constraints, and feedback relationships of each control node are verified against the specification definitions based on the execution action records. If the actual encoding of a node deviates from the expected encoding, or if there are missing, disordered, or abnormal markings in the execution actions, the node is determined to be abnormal. The process is then traced upstream or downstream along the signal interaction path until the faulty node is located, and a diagnostic result containing the faulty node, deviation type, and abnormal characteristics is output. Furthermore, when no obvious abnormalities are found in the encoding consistency comparison, but abnormal markings exist in the log data for the corresponding time period, the abnormal information recorded in the log can be used to assist in locating the cause of the fault, achieving cross-validation of the diagnostic conclusions of the message data, and further improving the reliability of the diagnostic results. For example, if the initial diagnosis points to an abnormality in a signal link, but there are no relevant execution action records in the log data for that time period, it can further corroborate that the function was not executed normally or the control command did not reach the execution end, thereby helping to narrow down the fault location range.

[0110] By combining the above-mentioned link-level signal comparison with cross-verification of execution action records, fault judgment is no longer limited to a single message anomaly or a single log anomaly, but completes a comprehensive analysis around the standard control link of the target function, thereby forming a comprehensive judgment on the fault node and fault type, and improving the fault location accuracy in cross-controller collaborative scenarios.

[0111] Figure 5 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 4 ,like Figure 5 As shown, in this embodiment... Figure 4 Based on the embodiments, the process of link-by-link signal comparison and analysis in S403 is described in detail. The method includes:

[0112] S501, retrieve target standard link information.

[0113] In this step, the target standard link information includes: the standard control link corresponding to the target function, the standard encoding of each node signal in the standard control link, and the signal interaction process. The standard control link represents the complete signal transmission path of the target function from signal input to execution end in the form of a node sequence; the standard encoding of each node signal is the expected signal value that the corresponding node should output when the function is working normally; the signal interaction process defines the timing relationship of signal transmission between adjacent nodes and the execution action information that each node should feed back after receiving a signal. Retrieving the target standard link information provides a reference for subsequent signal encoding comparison and execution action verification.

[0114] In practice, the fault handling model initiates a link information retrieval request to the functional specification knowledge base based on the identified target function. The knowledge base matches the corresponding standard control link and standard code of each node according to the target function, and returns the matching result to the fault handling model. The fault handling model uses the returned data as the benchmark for subsequent node-by-node comparison.

[0115] S502. Based on the actual encoding of multiple signals obtained after parsing the message data, compare them step by step with the standard encoding of each node in the target standard link information. At the same time, check whether the reception, forwarding and feedback of signals between each node are continuous and consistent according to the signal interaction process, and locate the node with encoding deviation.

[0116] In this step, based on the standard control link and standard codes of each node defined by the target standard link information retrieved in S501, the actual codes of each node signal parsed in S401 are compared for consistency along the link direction level by level to verify whether the actual signal state of each node is consistent with the expected state, and the deviation nodes that do not conform to the standard codes and their deviation information are recorded for subsequent comprehensive judgment.

[0117] In practice, the fault handling model uses the target standard link information as the diagnostic benchmark, and performs a step-by-step verification of the actual encoding of multiple signals obtained after parsing the message data. Starting from the first node of the standard control link, it determines whether the actual encoding of the current node's signal conforms to the standard encoding corresponding to that node; simultaneously, it checks whether the current node has received the signal sent by the previous node normally, whether it has forwarded the signal to the next node as expected, and whether it has returned execution feedback, based on the signal interaction process, identifying the specific nodes and their corresponding links in the standard control link where deviations have occurred step by step. If the actual encoding of the current node deviates from the standard encoding and exceeds the preset fault tolerance threshold, or if there is a reception failure, forwarding interruption, or feedback anomaly in the signal interaction process, the traversal is terminated, the node is located as a fault node, and its location and abnormal characteristics are recorded. When the first node is abnormal, the fault is located at the signal input end; if all nodes in the standard control link are consistent and the signal interaction process is complete, the target function signal link is determined to be normal.

[0118] S503. Obtain auxiliary verification information based on the execution action records in the log data.

[0119] In this step, the action records can come from action events, state transition records, or execution feedback records in the log data, reflecting the actual execution status of the target function within the time period of the failure. Based on the signal interaction flow in the target standard link information, the forwarding order and action response requirements that each node should follow during normal operation are determined.

[0120] In practice, the fault handling model retrieves the execution action records corresponding to each node from the log data according to the arrangement order of each node in the target standard link information. The extracted action events are arranged according to time sequence and associated with the triggering order and action response requirements defined in the signal interaction process to form auxiliary verification information. This auxiliary verification information includes whether the action events of each node occur in the prescribed order, whether the action response is completed within the prescribed time window, and whether there are any abnormal markers in the execution results. It is structured and stored according to node identifiers and time sequence for use as auxiliary criteria in subsequent comprehensive judgment.

[0121] S504. Generate fault diagnosis results based on the coding deviation nodes and auxiliary verification information.

[0122] In this step, the location and type of the fault are comprehensively determined based on the coding deviation node located by S502 and the auxiliary verification information obtained by S503.

[0123] In practice, when a coding deviation node exists, that node is taken as the location of the fault. When a coding deviation node does not exist, but timing or response anomalies are present in the auxiliary verification information, the node corresponding to the abnormal action is taken as the location of the fault. When neither exists, the target function is deemed to be operating normally, and the final fault diagnosis result is output. The fault type is determined based on the actual coding deviation direction or the specific manifestation of the abnormal action. The fault type differs from the fault description reported by the terminal device. The fault description is based on the fault phenomenon observed by the user, while the fault type is the root cause category of the fault determined by the system based on link comparison, used to characterize the signal anomaly mode of a specific node in the standard control link.

[0124] Figure 6 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 5 ,like Figure 6 As shown, in this embodiment... Figure 5 Based on the embodiments, the process of generating fault diagnosis results in S504 is described in detail. The method includes:

[0125] S601. Determine the faulty node based on the coding deviation node and auxiliary verification information.

[0126] In this step, the faulty node is determined based on the coded deviation node located in S502 and the auxiliary verification information obtained in S503. The faulty node is the location of the root cause of the fault determined by the system based on link comparison, and is used to characterize the abnormal location information of a specific node in the standard control link.

[0127] In specific implementation, if S502 locates a coding deviation node, that node is directly identified as a faulty node. Simultaneously, the execution action record corresponding to that node in the auxiliary verification information obtained in S503 is used as corroborating evidence to confirm the rationality of the fault inference. If S502 does not locate a coding deviation node, but the auxiliary verification information in S503 shows a node with no action record or an action response timeout, the node with the abnormal action is identified as a faulty node, with the fault type being missing execution action or response timeout. If S502 locates a coding deviation node, and the execution action record of that node in S503 does not match the expected action requirements of the signal interaction process, the location and deviation characteristics of the coding deviation node are used as the primary judgment basis, with auxiliary verification information used for cross-confirmation to improve the reliability of the fault determination result. If no abnormalities are found in either method, the target function is determined to have operated normally during the time period of the fault.

[0128] S602. Determine the control link where the faulty node is located.

[0129] In this step, the faulty node identified in S601 is used as a reference to extract the complete link information of the node along the standard control link.

[0130] In practice, taking the faulty node as a benchmark, the upstream and downstream nodes of the faulty node are traced back along the standard control link. The link name, link direction and relationship of adjacent nodes containing the faulty node are written into the fault diagnosis result to form the control link information where the faulty node is located.

[0131] S603. Generate fault diagnosis basis based on the signal comparison results and auxiliary verification information corresponding to the coding deviation node.

[0132] In this step, the signal comparison results of the coded deviation nodes are summarized with the auxiliary verification information to generate a basis for fault diagnosis.

[0133] In practice, the abnormal records generated during the item-by-item matching of the actual code and the standard code, as well as the abnormal markers in the auxiliary verification information, are summarized. This summary may include information such as the location of the abnormal node, the deviation characteristics between the actual code value and the standard code value, timeout records, status bit deviations, and action non-response records. This diagnostic basis is stored in conjunction with the fault node and serves as explanatory material for technicians to verify the source of the fault.

[0134] S604. Generate the corresponding fault handling method based on the fault node, control link, and fault diagnosis basis.

[0135] In this step, the corresponding fault handling method is automatically generated based on the type of faulty node and the type of link anomaly.

[0136] In specific implementation, when the fault node is due to an anomaly on the signal acquisition side, the system outputs suggestions for checking the corresponding sensors and input lines; when the fault node is due to an anomaly in the message transmission stage, the system outputs suggestions for link reconnection or re-acquisition; when the fault node is due to an anomaly in the control processing stage, the system outputs suggestions for resetting the controller or upgrading the software; and when the fault node is due to an anomaly on the execution side, the system outputs suggestions for checking the actuator and its connectors. The above fault handling methods are generated jointly by preset rules and diagnostic conclusions. In practical applications, other types of fault handling methods can also be selected, and this application does not limit this selection.

[0137] S605. Integrate at least one of the information obtained above, including the fault node, the control link where the fault node is located, the fault diagnosis basis, and the fault handling method, to generate the final fault diagnosis result and output it.

[0138] In this step, at least one piece of information obtained from S601 to S604 is associated and integrated according to a preset format to generate and output the final fault diagnosis result.

[0139] In practice, at least one piece of information from the generated fault node, control link, fault diagnosis basis, and fault handling method is associated and integrated, encapsulated according to a preset data structure, and the final fault diagnosis result is formed. This diagnosis result is then returned to the requesting terminal device. The fault diagnosis result can cover location results, link tracing, fault explanation, and resolution methods, forming a diagnostic report that can be directly used for troubleshooting, thus improving the completeness and accuracy of fault location and handling under the domain control architecture.

[0140] Figure 7 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 6 ,like Figure 7 As shown, in this embodiment... Figure 4 Based on the embodiments, the actual encoding process of obtaining multiple signals according to message data in S401 is described in detail. The method includes:

[0141] S701. Obtain the DBC decoding file that matches the vehicle platform to which the current vehicle belongs.

[0142] In this step, the fault handling model automatically obtains the DBC file in the R&D storage space that matches the vehicle platform version of the current vehicle through the document management application programming interface (API).

[0143] In practice, after receiving the message data corresponding to the faulty vehicle, the system first retrieves the matching DBC decoding file from the vehicle platform based on the vehicle identifier. The same vehicle platform can adapt to multiple vehicle models. The DBC file predefines the vehicle signal and its functional meaning corresponding to each bit segment in the original message. A group of signals can occupy several bits, and different bit combinations correspond to different vehicle functional states; that is, there is a one-to-one mapping relationship between the encoded value and the functional state. The fault handling model determines the vehicle platform version to which the current vehicle belongs based on its vehicle identifier and calls the corresponding DBC decoding file from the development storage space through the document management API interface for subsequent message decoding.

[0144] S702. Decode the extracted message data according to the DBC decoding file to obtain the actual codes of multiple signals.

[0145] In this step, based on the mapping rules between bits and signals / functions in the DBC file, the original message related to the target function extracted from S401 is decoded to extract the actual codes of multiple signals.

[0146] In practice, the fault handling model decodes the selected original messages based on the mapping rules between bits and signals / functions within the DBC file. This converts the original byte stream into corresponding physical or logical quantity codes, parsing out the actual signal codes and functional states fed back by the vehicle. The parsing results are presented as key-value pairs of "signal name—actual code," and stored in association according to the signal identifier and sampling time stamp, completing the conversion of message data into actual codes. The decoded signal codes correspond one-to-one with the time period of the fault, allowing comparison with the standard node signal codes in the target standard link information, thus supporting the subsequent identification of faulty nodes and abnormal links.

[0147] Figure 8 A flowchart illustrating the diagnostic method for vehicle control faults under the domain control architecture provided in this application. Figure 7 ,like Figure 8 As shown, in this embodiment... Figure 2 Based on the embodiments, the process of obtaining message data and log data from the faulty vehicle according to the vehicle identifier in S202 is described in detail. The method includes:

[0148] S801. Based on the vehicle identifier, send a data acquisition request to the T-BOX of the faulty vehicle, wherein the data acquisition request includes the fault time.

[0149] In this step, the diagnostic platform or diagnostic equipment identifies the target faulty vehicle based on the vehicle identifier and sends a data acquisition request to the vehicle's T-BOX via a remote communication link. The request must include at least the fault time.

[0150] In practice, after receiving fault information reported by the terminal device, the diagnostic platform or diagnostic equipment extracts the vehicle identifier and fault time from the fault information. Based on the vehicle identifier, it locates the corresponding faulty vehicle in the enterprise cloud platform and sends a data acquisition request to the T-BOX of the faulty vehicle through a pre-established remote communication link between the cloud platform and the T-BOX. The data acquisition request is a structured instruction message, containing at least the unique identifier of the faulty vehicle and the fault time field. Upon receiving the request, the T-BOX determines a preset time window based on the fault time carried in the request. This time window extends forward and backward by a preset duration centered on the fault time to limit the time range for data acquisition. Within this time window, the onboard data acquisition system configures different acquisition frequencies according to the importance of the data, using a higher acquisition frequency for critical signals and a lower acquisition frequency for secondary signals to ensure the integrity and validity of critical data under limited storage resources. The T-BOX retrieves data within the corresponding time range from the in-vehicle message storage unit and log storage unit according to the preset time window, and packages and returns the filtered message data and log data in a unified data encapsulation format.

[0151] In practical applications, the T-BOX can also adapt the data encapsulation length according to the vehicle's storage resources, communication bandwidth, and remote connection status; this application does not impose any limitations on this. If the diagnostic platform or diagnostic device does not receive a response within the preset timeout period, it will resend the request or determine that the vehicle-side communication is abnormal and output the corresponding error message; if a response is successfully received, it will proceed to S802.

[0152] S802: Receive message data and log data returned by the faulty vehicle within a preset time window.

[0153] In this step, the diagnostic platform or diagnostic equipment receives a data packet returned by the faulty vehicle via the T-BOX. The data packet contains message data and log data within the preset time window determined in S801.

[0154] In practice, after receiving the response data packet from the T-BOX, the diagnostic platform or equipment unpacks and parses the data packet according to a preset communication protocol and data encapsulation format, extracting the message data and log data. The message data characterizes the communication content, link interaction sequence, and signal transmission relationships between multiple controllers during the fault period, specifically including controller area network messages, local area network messages, IP-based scalable service-oriented middleware protocol communication records, and Ethernet communication records. The log data records information such as state transitions, control decisions, execution feedback, and abnormal events of each controller in the vehicle during operation. The extracted message data and log data undergo integrity verification. If the verification passes, the data is structured and stored according to data type, timestamp, and data source. If data packet parsing fails or integrity verification fails, the corresponding abnormal state is recorded, and a data retransmission request is triggered or a data acquisition failure message is generated according to the strategy.

[0155] This application provides a vehicle control fault diagnosis method under a domain control architecture. After receiving fault information, the method obtains message data and log data within the corresponding time window, matches target standard link information from the functional specification knowledge base according to the fault description, obtains the actual code through DBC decoding, and compares it level by level with the standard code of each node in the link. Combined with log-assisted verification, the method locates the fault node and finally generates a diagnostic result containing at least one of the following: fault node, control link, diagnostic basis, and processing method, which is returned to the terminal device. This method reduces the manual step-by-step troubleshooting process and improves the efficiency and accuracy of fault location.

[0156] Figure 9 A schematic diagram of a diagnostic device for vehicle control faults under a domain control architecture provided in this application is shown below. Figure 9 As shown, the vehicle control fault diagnosis device 900 provided in this embodiment includes:

[0157] The receiving module 901 is used to receive fault information sent by the terminal device. The fault information includes vehicle identification, fault description and fault time.

[0158] The acquisition module 902 is used to obtain message data and log data for the time period of the fault from the faulty vehicle based on the vehicle identifier;

[0159] Processing module 903 is used for:

[0160] Based on the fault description, the target standard link information corresponding to the target function that caused the fault is obtained from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple vehicle functional specification documents, including standard link information for each function;

[0161] Based on message data, log data, and target standard link information, fault diagnosis is performed to obtain fault diagnosis results;

[0162] The sending module 904 is used to return the fault diagnosis results to the terminal device.

[0163] In one possible implementation, the receiving module receives the vehicle identifier, fault description, and fault time, establishing a correspondence between the fault phenomenon and the specific vehicle and time period. The acquisition module further retrieves message and log data within that time period, ensuring the diagnostic basis covers control interaction information and operational records. The processing module then extracts standard link information of the target function from the functional specification knowledge base based on the fault description and performs joint comparison and analysis with the actual messages and logs. This enables link-level diagnosis of cross-controller collaborative functions within a domain control architecture. This effectively associates natural language fault phenomena with standard functional links, making it easier to identify the specific links and fault nodes where anomalies occur. Therefore, it improves the efficiency and accuracy of fault root cause localization and reduces manual troubleshooting costs.

[0164] Based on the above embodiments, the processing module 903 is specifically used for:

[0165] By using a pre-trained fault handling model, the target function that is faulty in the fault description is identified, and the function is matched in the functional specification knowledge base according to the target function to obtain the target standard link information.

[0166] Among them, the fault handling model is a fault analysis model trained based on a large language model, historical fault data of various vehicles, historical operation and maintenance data, and R&D test data.

[0167] In one specific embodiment, the processing module 903 is further configured to:

[0168] Based on the message data, obtain the actual codes of multiple signals of the faulty vehicle during the time period of the fault.

[0169] Based on the log data, obtain the records of the actions performed by the faulty vehicle during the time period in which the fault occurred;

[0170] Based on the actual encoding of multiple signals, the execution action record, and the target standard link information, fault diagnosis is performed to obtain the fault diagnosis results.

[0171] In one specific implementation, the target standard link information includes: the standard control link corresponding to the target function, the standard encoding of each node signal in the standard control link, and the signal interaction process;

[0172] Processing module 903 is also specifically used for:

[0173] Based on the actual encoding of multiple signals, the action record is executed. The standard encoding of each node signal in the standard control link and the signal interaction process are used to perform a step-by-step signal comparison analysis of the link to obtain the fault diagnosis result.

[0174] In one specific implementation, the fault diagnosis result includes at least one of the following information:

[0175] Faulty node, control link where the faulty node is located, fault diagnosis basis, and fault handling method.

[0176] In one specific embodiment, the processing module 903 is further configured to:

[0177] Obtain the DBC decoding file corresponding to the faulty vehicle;

[0178] The message data is decoded based on the DBC decoding file to obtain the actual encoding of multiple signals of the faulty vehicle during the time period of the fault.

[0179] In one specific embodiment, the acquisition module 902 is specifically used for:

[0180] Based on the vehicle identification, a data acquisition request is sent to the T-BOX of the faulty vehicle. The data acquisition request includes the time of the fault.

[0181] The system receives message data and log data from the faulty vehicle indicating the time period of the fault. The diagnostic device for vehicle control faults under any domain control architecture provided in this embodiment can execute the methods provided in the above-described method embodiments, and their implementation principles and technical effects are similar; therefore, they will not be elaborated upon here.

[0182] Figure 10 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 10 As shown, the electronic device 1000 provided in this embodiment includes: a memory 1001, a processor 1002, and an interaction interface 1003.

[0183] Memory 1001 stores computer-executed instructions;

[0184] The processor 1002 executes computer execution instructions stored in the memory, causing the processor to perform the method provided in any of the above embodiments.

[0185] The interactive interface 1003 is used to receive fault information sent by the terminal device and to return fault diagnosis results to the terminal device.

[0186] This electronic device can be deployed in a cloud-based diagnostic platform, server, or vehicle-side computing node. Its memory stores program instructions for receiving fault information, retrieving data, matching links, and performing diagnostic analysis. After the processor invokes these instructions, it can receive vehicle identification, fault description, and fault time submitted by the terminal through an interactive interface, and obtain message and log data for the corresponding time period. The processor can also perform link-level analysis of the multi-controller collaborative process based on target standard link information in the functional specification knowledge base associated with the fault description. This allows for the mapping of natural language fault phenomena to vehicle operating data and functional control relationships, enabling more accurate identification of abnormal links in cross-domain control scenarios. This improves the efficiency and accuracy of fault root cause localization, thus reducing the workload and processing costs of manual troubleshooting.

[0187] In a specific implementation, at least one processor 1002 executes computer execution instructions stored in memory 1001, causing at least one processor 1002 to perform the above-described method.

[0188] The specific implementation process of processor 1002 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0189] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0190] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0191] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0192] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0193] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0194] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0195] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0196] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for diagnosing vehicle control faults under a domain control architecture, characterized in that, include: Receive fault information sent by the terminal device, the fault information including vehicle identification, fault description and fault time; Based on the vehicle identifier, obtain message data and log data for the time period in which the fault occurred from the faulty vehicle; Based on the fault description, the target standard link information corresponding to the target function that caused the fault is obtained from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple vehicle functional specification documents and includes standard link information for each function; Based on the message data, the log data, and the target standard link information, fault diagnosis is performed to obtain fault diagnosis results; The fault diagnosis results are returned to the terminal device.

2. The method according to claim 1, characterized in that, The step of retrieving the target standard link information corresponding to the target function that has failed from a pre-built functional specification knowledge base based on the fault description includes: By using a pre-trained fault handling model, the target function that has failed in the fault description is identified, and the target function is matched in the functional specification knowledge base to obtain the target standard link information. The fault handling model is a fault analysis model trained based on a large language model, historical fault data of various vehicles, historical operation and maintenance data, and R&D test data.

3. The method according to claim 1 or 2, characterized in that, The step of performing fault diagnosis based on the message data, the log data, and the target standard link information to obtain fault diagnosis results includes: Based on the message data, obtain the actual codes of multiple signals of the faulty vehicle during the time period in which the fault occurred; Based on the log data, obtain the records of the actions performed by the faulty vehicle during the time period in which the fault occurred; Based on the actual encoding of the multiple signals, the execution action record, and the target standard link information, fault diagnosis is performed to obtain the fault diagnosis result.

4. The method according to claim 3, characterized in that, The target standard link information includes: the standard control link corresponding to the target function, the standard encoding of each node signal in the standard control link, and the signal interaction process; The step of performing fault diagnosis based on the actual encoding of the multiple signals, the execution action record, and the target standard link information to obtain the fault diagnosis result includes: Based on the actual encoding of the multiple signals, the execution action record, the standard encoding of each node signal in the standard control link, and the signal interaction process, a link-by-link signal comparison analysis is performed to obtain the fault diagnosis result.

5. The method according to claim 4, characterized in that, The fault diagnosis results include at least one of the following information: Faulty node, control link where the faulty node is located, fault diagnosis basis, and fault handling method.

6. The method according to claim 3, characterized in that, The step of obtaining the actual encoding of multiple signals of the faulty vehicle during the time period of the fault, based on the message data, includes: Obtain the DBC decoding file corresponding to the faulty vehicle; The message data is decoded according to the DBC decoding file to obtain the actual encoding of multiple signals of the faulty vehicle during the time period of the fault.

7. The method according to claim 1 or 2, characterized in that, The step of obtaining message data and log data for the time period of the fault from the faulty vehicle based on the vehicle identifier includes: Based on the vehicle identifier, a data acquisition request is sent to the T-BOX of the faulty vehicle, and the data acquisition request includes the fault time. Receive message data and log data from the faulty vehicle indicating the time period in which the fault occurred.

8. A diagnostic device for vehicle control faults under a domain control architecture, characterized in that, include: The receiving module is used to receive fault information sent by the terminal device, the fault information including vehicle identification, fault description and fault time; The acquisition module is used to acquire message data and log data of the time period in which the fault occurred from the faulty vehicle based on the vehicle identifier; Processing module, used for: Based on the fault description, the target standard link information corresponding to the target function that caused the fault is obtained from the pre-built functional specification knowledge base; wherein, the functional specification knowledge base is a knowledge base built based on multiple vehicle functional specification documents and includes standard link information for each function; Based on the message data, the log data, and the target standard link information, fault diagnosis is performed to obtain fault diagnosis results; The sending module is used to return the fault diagnosis results to the terminal device.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images