Fault uploading system and method of domain controller, electronic equipment and medium

Abstract

The invention discloses a fault uploading system and method for a domain controller in the technical field of automobiles, electronic equipment and a medium. The system comprises a diagnostic event management module, a diagnostic event monitoring module and a communication module, the diagnosis event management module is used for acquiring a real-time fault list; the diagnosis event monitoring module is used for acquiring diagnosis fault codes in the fault list according to a set period, and storing the diagnosis fault codes into corresponding data sending cache regions respectively according to the codes of the sub-control units; and the communication module is used for calling a CANFD communication channel bound with the sub-control unit code, and sending the diagnosis fault code to a CANFD bus based on the set data structure body in the data sending cache region. By adopting the method, the delay and complex operation caused by the traditional method of obtaining the fault information by depending on external diagnosis equipment can be avoided, and the fault information of the plurality of sub-control units can be uploaded independently, sectionally and parallelly.

Description

Technical Field

[0001] The present invention relates to the field of automobile technology, and in particular to a fault uploading system, method, electronic equipment and medium for a domain controller. Background Art

[0002] As automotive electrical and electronic architectures evolve toward centralization and integration, vehicle control systems are gradually evolving from traditional distributed control architectures to functional domain architectures centered around domain controllers. In this architecture, a single domain controller typically integrates multiple electronic control units (ECUs), each responsible for executing specific functional modules, such as the chassis domain, body domain, and powertrain domain. The centralized design of domain controllers helps improve vehicle functional integration, reduce wiring complexity and overall vehicle cost, and facilitates unified management and version control of software platforms.

[0003] However, as system complexity increases, the multiple sub-control units integrated in the domain controller may generate a large number of diagnostic trouble codes (DTCs) during operation. Since the traditional passive pull method that relies on diagnostic equipment is inefficient and cumbersome to operate, how to actively, in real time, and accurately upload fault information during system operation has become a key direction of current technical research and engineering implementation.

[0004] In related technologies, existing solutions achieve a certain degree of active upload functionality by encoding fault events into fixed-format diagnostic frame messages and sending them to the Controller Area Network (CAN) or Controller Area Network Flexible Data-Rate (CAN FD) bus. Although this method improves the efficiency of uploading fault information, in domain controllers with multiple subsystems, there is still the problem of being unable to effectively distinguish the content reported by different sub-control units, which can easily lead to diagnostic data overlap, diagnostic frame loss, cache conflicts, and other phenomena, thereby affecting the accuracy of fault location and system maintenance efficiency. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems in the related art to a certain extent. To this end, the purpose of the present invention is to propose a fault uploading system, method, electronic device and medium for a domain controller to achieve efficient, real-time and distinguishable uploading of fault information of multiple sub-control units to the CANFD bus.

[0006] In order to achieve the above-mentioned object, a first embodiment of the present invention proposes a fault uploading system for a domain controller, comprising: a diagnostic event management module, a diagnostic event monitoring module and a communication module;

[0007] The diagnostic event management module is used to obtain a real-time fault list; the fault list records at least the diagnostic trouble code of the fault and the sub-control unit code that generated the diagnostic trouble code; wherein, at least two sub-control units are integrated in the domain controller;

[0008] The diagnostic event monitoring module is used to obtain diagnostic trouble codes in the fault list at a set period and store the diagnostic trouble codes in corresponding data transmission buffers according to the sub-control unit codes; the data transmission buffer includes a set of set data structures, and the set data structures are used to manage the information field of the diagnostic trouble code transmission status;

[0009] The communication module is used to call the CANFD communication channel bound to the sub-control unit code, and send the diagnostic fault code to the CANFD bus based on the set data structure in the data sending buffer area.

[0010] In addition, the fault uploading system for the domain controller in the above embodiment of the present invention may also have the following additional technical features:

[0011] According to an embodiment of the present invention, the communication module is configured to operate when a fault detection process is completed or the data transmission buffer is full.

[0012] According to an embodiment of the present invention, the diagnostic event monitoring module is configured to lock the data sending buffer area when a fault detection process is completed or the data sending buffer area is full.

[0013] According to one embodiment of the present invention, the diagnostic event monitoring module is further configured to clear the field content of the set data structure in the data sending buffer and set the data sending buffer to an unlocked state when the diagnostic fault code cached in the data sending buffer is sent.

[0014] According to one embodiment of the present invention, the setting data structure includes a diagnostic trouble code field, a storage lock status field, a fault quantity field, a total number of sent frames field, a sent frame number field, and a diagnostic trouble code quantity field contained in the last data frame.

[0015] According to an embodiment of the present invention, the fault list further includes a reporting code of the diagnostic fault code.

[0016] According to an embodiment of the present invention, the diagnostic event monitoring module is configured to discard the exceeding diagnostic trouble codes when the number of diagnostic trouble codes stored in the data transmission buffer exceeds a preset upper limit.

[0017] To achieve the above objectives, a second embodiment of the present invention provides a method for uploading faults of a domain controller, which is applied to a domain controller having at least two sub-control units integrated therein. The method includes:

[0018] Obtaining a fault list of all real-time faults of the sub-control units; the fault list is used to include at least a diagnostic trouble code and a sub-control unit code that generates the diagnostic trouble code;

[0019] The diagnostic trouble codes in the fault list are stored in corresponding data transmission buffers according to the sub-control unit codes; the data transmission buffers include a set of setting data structures, and the setting data structures are used to manage information fields of the diagnostic trouble code transmission status;

[0020] The CANFD communication channel bound to the sub-control unit code is called, and the diagnostic fault code is sent to the CANFD bus based on the set data structure in the data sending buffer area.

[0021] To achieve the above-mentioned purpose, an embodiment of the third aspect of the present invention proposes an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of the above-mentioned domain controller fault uploading method are implemented.

[0022] To achieve the above-mentioned purpose, a fourth embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed, the steps of the above-mentioned domain controller fault uploading method are implemented.

[0023] The fault uploading system, method, electronic device, and medium for the domain controller of the embodiments of the present invention obtain a real-time fault list including diagnostic fault codes and their corresponding sub-control unit codes through the diagnostic event management module, avoiding the delays and complex operations caused by the traditional reliance on external diagnostic equipment to obtain fault information. The diagnostic event monitoring module partitions and classifies the diagnostic fault codes according to the sub-control units and stores them in the corresponding data transmission buffer area. In each buffer area, the transmission status of each type of diagnostic fault code is orderly managed through the structure field. The communication module further uploads the corresponding fault information to the bus in a channel-by-channel manner based on the binding relationship between the sub-control unit and the CANFD communication channel, thereby achieving independent, partitioned, and parallel upload of fault information from multiple sub-control units, greatly improving the efficiency of fault information transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A schematic diagram of a domain controller integrated into a multifunctional system;

[0025] Figure 2 This is a schematic diagram of the structure of a fault uploading system for a domain controller in one embodiment;

[0026] Figure 3 The software architecture and operation process of the fault upload system in one embodiment;

[0027] Figure 4 The figure is a flowchart of a fault uploading method in one embodiment. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0029] The following describes in detail the implementation details of the technical solutions of the embodiments of the present application.

[0030] like Figure 1 The figure shows a schematic diagram of a domain controller with multi-functional system integration. The domain controller is usually the functional core of the vehicle's electronic and electrical architecture, and it integrates four sub-control units, such as independent processing units for functional modules such as body control, gateway management, energy management, and cockpit entertainment. Each sub-control unit is relatively independent in terms of software and hardware, and has an independent task scheduling mechanism, resource allocation and diagnostic configuration, and can generate corresponding diagnostic fault codes based on its own operating status. However, as the functions of the vehicle's electronic system become increasingly complex, the number of sub-control units integrated in the domain controller continues to increase, and the fault information generated by each unit is of various types and large in quantity. If it is uploaded through traditional serial polling, it will not only be inefficient, but may also cause delayed upload or even loss of key fault information.

[0031] To this end, in one embodiment, Figure 2 The figure shows a schematic diagram of the structure of a fault upload system for a domain controller, which uploads diagnostic fault codes via a directional transmission interface of the CANFD bus. The fault upload system may include a diagnostic event management module, a diagnostic event monitoring module, and a communication module.

[0032] The following is a detailed description of each functional module in the fault upload system.

[0033] The diagnostic event management module is used to collect fault information within the entire domain controller and to uniformly manage and record the diagnostic events reported by each ECU. In actual applications, each ECU registers its fault monitoring events with diagnostic capabilities to the diagnostic event management module during system initialization in accordance with the unified interface specification. These monitoring events generally include but are not limited to software and hardware operation anomalies such as sensor signal interruption, voltage overrun, communication anomalies, and hardware function failure. When a sub-control unit detects that any diagnostic event meets the set fault judgment conditions (such as meeting a certain time threshold, continuous abnormal level, etc.), the event will be converted into the corresponding DTC. The diagnostic event management module receives the DTC generated by the sub-control unit in real time and automatically organizes it into a fault list. The fault list supports data updates in a timestamp manner to ensure that all current faults of each ECU can be reflected within a certain time window.

[0034] The fault list contains at least two key fields: a diagnostic fault code, which uniquely identifies a specific fault event; and a sub-control unit code, which identifies the sub-control unit to which the fault originated, facilitating subsequent partition upload and fault tracing. In practice, the sub-control unit code can be a fixed-length integer number, address information, or a bit field with a prefix identifier to ensure uniqueness and parsability in a multi-module operating environment.

[0035] In one embodiment, to enhance the identifiability of diagnostic fault information and facilitate parsing by higher-level systems, the diagnostic event management module, when generating a fault list, not only records the diagnostic fault code and sub-control unit code, but also appends the corresponding reporting code information for each fault. The reporting code describes the standardized encoding format used for internal system faults during external communication or vehicle platform identification. Typically, it uses a 3-byte hexadecimal encoding format, consistent with the fault code encoding format, to facilitate unified parsing and processing by the vehicle development platform.

[0036] In practical applications, fault lists typically use static configuration data of const type, containing the following key fields: fault code, reporting code (high byte / mid byte / low byte), and the identifier of the sub-control unit to which it belongs (e.g., ECU1-ECU4). Each row in the fault list is a fault record. When a diagnostic event is triggered, the diagnostic event management module maps the event to the corresponding entry in the fault list and stores it as the current fault. As shown in Table 1, Table 1 shows the data structure of a fault list provided in this embodiment. The following configuration data represents a portion of typical fault entries in the system.

[0037] Table 1

[0038]

[0039]

[0040] In this way, the diagnostic event management module can completely retain the three core fields of diagnostic fault code, sub-control unit code and reporting code in each fault entry, forming the complete structure of the fault list, thereby providing basic data support for subsequent fault classification, frame encapsulation and CANFD message sending.

[0041] In order to avoid information confusion and disordered order when the domain controller reports faults in a centralized manner, the fault upload system sets up a diagnostic event monitoring module. This module serves as the fault information processing core and is configured to perform periodic tasks when the domain controller is running. Its core task is to periodically read the fault list provided by the diagnostic event management module and classify each fault record into the corresponding sending buffer for subsequent fault reporting.

[0042] The Diagnostic Event Monitoring Module schedules execution at fixed intervals (e.g., every 10ms) by setting up a scheduled task. During each scheduling cycle, the Diagnostic Event Monitoring Module retrieves the currently active fault list by calling the Dem_eventStatusBuffer() interface function provided by the Diagnostic Event Management Module. The fault list is returned in a structured format, including multiple fault entries. Each entry contains at least two core fields: a diagnostic trouble code and a sub-control unit code, which identify the source module of the fault information.

[0043] In the process of calling the interface to obtain the fault list, the diagnostic event monitoring module can index the diagnostic trouble codes to be uploaded and the sub-control unit codes to which they belong based on the fault list (as shown in Table 1). After obtaining these fault entries, the diagnostic event monitoring module classifies and organizes the fault entries according to the sub-control unit codes and stores the corresponding diagnostic trouble codes in the data transmission buffer area independently allocated by the system for each sub-control unit. Each sub-control unit corresponds to an independent data transmission buffer area, which is composed of a set of set data structures and is used to uniformly manage the transmission status and related management information of the diagnostic trouble codes to be uploaded in the current data transmission buffer area.

[0044] In one embodiment, to prevent data transmission buffer overflows from causing write confusion or system anomalies, a capacity upper limit control mechanism is provided in the data transmission buffer corresponding to each sub-control unit. When the number of diagnostic fault codes stored in a sub-control unit's buffer reaches a preset upper limit (e.g., 255 items), the diagnostic event monitoring module will no longer write to the subsequently parsed diagnostic fault codes, but will discard them to ensure the stability of the cached information and the controllability of system resources. In actual applications, the discard operation is a silent process that does not interrupt the module scheduling process, and the fault information can be re-detected and collected in subsequent diagnostic cycles.

[0045] In specific implementation, a field for recording the number of currently cached diagnostic fault codes can be set in the setting data structure. The writing status of the data sending cache area can be uniformly managed by setting the data structure, and a circular cache array of diagnostic fault codes can be maintained with a fixed capacity (for example, a maximum of 255 items).

[0046] In one embodiment, the diagnostic event monitoring module also implements a buffer state control mechanism during the process of completing fault collection and classification storage to ensure the integrity of fault information and the order of upload. Specifically, in each fault detection cycle, after the diagnostic event monitoring module completes the fault collection, classification, and writing of the current cycle, the system will determine whether to perform a lock operation on the corresponding data transmission buffer based on any of the following conditions:

[0047] (1) When a complete fault detection process has been completed and all fault information has been classified and written;

[0048] (2) Or, when the number of fault codes in the data transmission buffer corresponding to a sub-control unit reaches the storage upper limit set by the system, the buffer space can no longer continue to write new fault information.

[0049] Once any of the above conditions is met, the diagnostic event monitoring module will lock the data sending buffer area of the sub-control unit and prohibit further write operations, thereby preventing data from being overwritten or new data from being mixed with the data to be uploaded, ensuring that the fault information can be uploaded completely.

[0050] In one embodiment, the diagnostic event monitoring module also includes an unlocking and cache clearing mechanism to restore the cache to a usable state after fault information is successfully transmitted, thereby providing continuous cache resource support for subsequent fault collection and upload processes. Specifically, after the communication module completes the task of transmitting diagnostic fault codes to the corresponding sub-control unit, it notifies the diagnostic event monitoring module that all fault codes in the data transmission cache have been successfully uploaded.

[0051] After receiving the upload completion notification, the diagnostic event monitoring module clears the data transmission buffer corresponding to the sub-control unit. This includes clearing the fault codes and related management information recorded in the data structure set in the buffer to free up buffer resources. It also sets the data transmission buffer to an unlocked state, enabling it to receive diagnostic fault information for the next cycle.

[0052] In one embodiment, a data structure is set to support unified management and process control of the fault upload status of each sub-control unit. The data structure is set to include multiple fields for managing diagnostic fault information and cache status, specifically, a diagnostic fault code field, a storage lock status field, a fault number field, a total number of frames sent field, a number of frames sent field, and a diagnostic fault code number field contained in the last data frame.

[0053] Among them, the diagnostic fault code field is used to cache all fault information to be uploaded by the current sub-control unit. The diagnostic event monitoring module writes the corresponding diagnostic fault code into this field after the fault is collected until the fault information is uploaded or the cache area enters a locked state.

[0054] To ensure data consistency and controllability during the upload process, the structure also includes a storage lock status field, which indicates whether new data can be written to the current data send buffer. When the fault collection process is complete, or the number of diagnostic trouble codes in the buffer reaches the set upper limit, this field will be set to the locked state, prohibiting the writing of new fault information to prevent data overwriting or out-of-order uploads. Once all diagnostic trouble codes in the current data send buffer have been uploaded, the field will be set to the unlocked state to allow the writing of new diagnostic trouble codes to be uploaded.

[0055] The fault quantity field set in the structure is used to automatically count the total number of diagnostic trouble codes in the current cache.

[0056] The diagnostic event monitoring module can dynamically calculate the total number of sent frames based on the number of faults and the carrying capacity of a single-frame CANFD message (for example, each frame can transmit up to 20 fault codes), and record it in the total number of sent frames field.

[0057] The structure also contains a sent frame number field, which is used to record the number of message frames that have been successfully uploaded, so as to achieve continued control of the upload progress during system scheduling or interrupt recovery.

[0058] To further clarify the upload boundary, the structure also has a field for the number of diagnostic fault codes contained in the last frame of data, which indicates the number of fault codes actually carried by the last frame in the total number of frames, providing an accurate data demarcation basis when constructing the last frame message.

[0059] The communication module is responsible for data interaction with the CANFD bus. In this system, each sub-control unit is bound to a unique CANFD communication channel during the software design phase, that is, a fixed CANFD frame ID is assigned for sending its exclusive fault information. CANFD is an automotive communication protocol that supports higher transmission rates and larger data loads. It is an upgraded version of the traditional CAN protocol. The CANFD frame supports up to 64 bytes of valid data area and allows the data phase to be transmitted at a higher baud rate, thereby greatly improving communication efficiency. In the CANFD network, the frame ID of each communication channel is the unique identifier of its message. It not only determines its priority in the bus arbitration process, but can also be used by the receiving end to identify the function or source module of the message. Therefore, the fixed CANFD ID is bound to the sub-control unit one by one in this system, which can not only ensure orderly bus communication, but also improve the efficiency of fault information identification and distribution.

[0060] In actual applications, the binding relationship is set through a static configuration table to ensure consistency at runtime. For example, refer to Figure 1 As shown in the figure, the domain controller integrates four sub-control units, each of which uploads fault information based on the CANFD ID (0x501-0x504). Among them, sub-control unit 1 (EcuId=1) is bound to CANFDID 0x501, sub-control unit 2 (EcuId=2) is bound to CANFDID 0x502, and so on.

[0061] After receiving a send request from the diagnostic event monitoring module, the communication module reads the pending fault codes from the data transmission buffer according to the send status recorded in the pre-set data structure, assembles them into a CANFD frame message, and writes it to the transmission channel corresponding to the corresponding ID. The CANFD frame format is encapsulated according to the preset protocol specifications. Each frame supports multiple diagnostic fault codes. For example, a single frame can send 20 diagnostic fault codes, and multiple frames can be sent continuously to cover all the diagnostic fault codes to be uploaded.

[0062] During the transmission process, the fault codes in the structure are extracted frame by frame, encapsulated into CANFD messages, and sent to the bus until all cached diagnostic fault codes have been transmitted. The CANFD ID of each sub-control unit remains unchanged throughout the communication process, so the receiving end can directly determine the source of the fault based on the ID, achieving the purpose of decoding by subsystem partition.

[0063] In one embodiment, the communication module is configured to start working only when specific conditions are met to ensure that the timing of fault uploading is reasonable and the data source is complete. Among them, two start-up trigger conditions for fault uploading are set. In the first condition, when a complete fault detection process has been executed and the diagnostic event monitoring module has completed the collection, classification and writing of all fault information in the current cycle into the corresponding data sending buffer, the communication module enters the working state; in the second condition, when the number of fault codes in the data sending buffer of a certain sub-control unit reaches the set upper limit, that is, the buffer space is full and new fault information cannot be written, the communication module enters the working state and sends the fault information in the buffer by uploading data to make available space.

[0064] Once the communication module enters operation, it sequentially reads the diagnostic fault codes to be uploaded from the data transmission buffer corresponding to each sub-control unit, encapsulates the messages, and transmits them according to the preset CANFD frame protocol. Because the communication module's activation is controlled by the fault information's readiness, it effectively improves system efficiency and CANFD bus resource utilization, while ensuring the accuracy and completeness of uploaded content.

[0065] In practical applications, Figure 3 The software architecture and operation process of the fault upload system are shown below. Figure 3 The workflow of the fault upload system is described in detail.

[0066] When the fault upload system is running, the diagnostic event monitoring module first proactively retrieves the current diagnostic event status information for each sub-control unit from the diagnostic event management module, calling the Dem_eventStatusBuffer interface to read the fault event buffer. This buffer stores real-time fault information reported by multiple sub-control units, including diagnostic fault codes and their corresponding sub-control unit codes. After obtaining this information, the diagnostic event monitoring module enters a local processing flow, categorizing the fault codes according to their assigned sub-control unit codes and writing them to the data transmission buffer associated with each sub-control unit.

[0067] In the above caching process, each cache area is managed using a preset data structure Dcm_DTCNumUpData[EcuId]. The data structure contains fields for describing the current sending status of the diagnostic trouble code, such as whether it is ready or whether it has been uploaded successfully.

[0068] When it is detected that the fault data of a sub-control unit is ready to be uploaded, the diagnostic event monitoring module triggers the fault upload operation, calls the CANFD communication channel bound to the sub-control unit code through the interface Dcm_DTCNumTransmit, and hands the target diagnostic fault code to the communication module for processing. After receiving the transmission request, the communication module selects the CANFD communication channel bound to the sub-control unit code and calls the underlying interface Com_SendSignal <xx>, the fault code data is encapsulated and sent to the CANFD bus according to the preset communication protocol, thereby realizing the effective reporting of the fault information of the sub-control unit.

[0069] In summary, the fault upload system's workflow embodies a multi-module collaborative mechanism: the diagnostic event management module is responsible for standardized management of fault information, the diagnostic event monitoring module implements centralized processing and cache scheduling of fault information, and the communication module is responsible for final data transmission. The clear division of responsibilities between modules and the orderly interface calls effectively support fault information attribution identification and rapid upload in a multi-control unit environment, improving diagnostic data collection efficiency and system maintainability.

[0070] In the above-mentioned embodiment, the domain controller's fault upload system, by providing a diagnostic event management module, a diagnostic event monitoring module, a communication module, and a data transmission buffer, achieves unified management, classified storage, and active upload of diagnostic fault information from multiple sub-control units. The diagnostic event management module can collect diagnostic trouble codes generated by all sub-control units without relying on external diagnostic equipment. By binding each sub-control unit to a unique CANFD communication channel, the uploaded data has a clear source identifier, avoiding the diagnostic data overlap and upload conflicts caused by information mixing in traditional technologies. The diagnostic event monitoring module periodically collects fault information from each sub-control unit and manages it through classified writes. In conjunction with the buffer's state control mechanism, this effectively ensures the integrity and sequentiality of data uploads. The communication module is activated based on preset trigger conditions and transmits diagnostic trouble codes in frame encapsulation, improving upload efficiency and bus resource utilization. The overall solution offers excellent module decoupling and system scalability, making it particularly suitable for automotive domain control systems with centralized architectures, significantly improving the manageability of fault diagnostic data and system maintenance efficiency.

[0071] In one embodiment, Figure 4 A fault upload method applied to a domain controller is shown. The domain controller integrates at least two sub-control units. The internal structure of the domain controller can be referred to Figure 1 The method for uploading fault information of a domain controller may include the following steps:

[0072] Step S101: Obtain a fault list of all sub-control unit real-time faults.

[0073] Obtain real-time fault information for all sub-control units. Each sub-control unit can perform internal fault diagnosis and output the currently detected diagnostic trouble code and its corresponding sub-control unit code. The sub-control unit code can be used to identify the source of the trouble code, facilitating subsequent classification, storage, and transmission management.

[0074] After the fault information from each sub-control unit is aggregated, a fault list is constructed. The fault list includes at least a number of diagnostic trouble codes and the sub-control unit code associated with each diagnostic trouble code.

[0075] In practical applications, to enhance the identifiability of diagnostic fault information and facilitate analysis by higher-level systems, the fault list can also include the reporting code information corresponding to each fault. The reporting code describes the standardized encoding format that should be used for external communication or vehicle platform identification of internal system faults, facilitating unified analysis and processing by the vehicle development platform.

[0076] Step S102: The diagnostic trouble codes in the fault list are stored in the corresponding data transmission buffer areas according to the sub-control unit codes.

[0077] Each diagnostic trouble code in the fault list is stored in the corresponding data transmission buffer according to its corresponding sub-control unit code. Each sub-control unit can correspond to an independent data transmission buffer to manage the storage and transmission of the fault information it generates. Each data transmission buffer contains a data structure in a unified format for storing the diagnostic trouble code code information and its associated transmission status field. The data structure can specifically include a diagnostic trouble code field, a storage lock status field, a fault number field, a total number of transmitted frames field, a number of transmitted frames field, and a number of diagnostic trouble codes contained in the last data frame field. Specifically, the diagnostic trouble code field is used to cache all fault information to be uploaded by the current sub-control unit. The storage lock status field is used to indicate whether the current data transmission buffer allows further writing of new data. The fault number field is used to automatically count the total number of diagnostic trouble codes currently in the buffer. The total number of transmitted frames field is used to transmit the number of frames required to transmit the diagnostic trouble codes to be uploaded in the data transmission buffer. The number of transmitted frames field is used to record the number of message frames successfully uploaded. The number of diagnostic trouble codes contained in the last data frame field indicates the number of trouble codes actually carried in the last frame of the total number of frames.

[0078] In actual applications, to prevent data transmission buffer overflows from causing write confusion or system anomalies, a capacity limit control mechanism is set in the data transmission buffer corresponding to each sub-control unit. When the number of diagnostic trouble codes stored in a sub-control unit's buffer reaches a preset limit (for example, 255 items), the excess diagnostic trouble codes will be discarded to ensure the stability of the cached information and the controllability of system resources. Among them, the fault number field in the data structure can be set to determine whether the capacity limit has been reached.

[0079] Step S103: calling the CANFD communication channel bound to the sub-control unit code, and sending the diagnostic fault code to the CANFD bus based on the set data structure in the data sending buffer area.

[0080] Based on the classified and stored fault information, the CANFD communication channel bound to the sub-control unit code is invoked. Specifically, the corresponding CANFD channel is determined based on each sub-control unit's communication configuration. Based on that channel's transmission strategy, unuploaded diagnostic fault codes are extracted from the corresponding data transmission buffer. These pending fault codes are packaged and processed according to the contents of the predefined data structure to generate a CANFD message. Once packaged, the constructed message is sent to the CANFD bus via the CANFD communication channel, enabling the effective reporting of fault information from each sub-control unit.

[0081] For example, refer to Figure 1 As shown in the figure, the domain controller integrates four sub-control units, each of which uploads fault information based on the CANFD ID (0x501-0x504). Among them, sub-control unit 1 (EcuId=1) is bound to CANFDID 0x501, sub-control unit 2 (EcuId=2) is bound to CANFDID 0x502, and so on. If the diagnostic fault code generated by sub-control unit 1 needs to be uploaded, it is uploaded by calling the communication channel with CANFD ID 0x501, so that the recipient can clearly identify the fault information through the communication channel for uploading data.

[0082] In actual applications, there are two triggering scenarios for uploading fault information. In the first triggering scenario, when a complete fault detection process has been executed and all fault information in the current cycle has been collected, classified, and written to the corresponding data transmission buffer, then fault information can be uploaded. In the second triggering scenario, when the number of fault codes in the data transmission buffer of a sub-control unit reaches the set upper limit, that is, the buffer space is full and new fault information cannot be written, then fault information can be uploaded.

[0083] It should be noted that to ensure data consistency and controllability of the upload process, when the upload of fault information is triggered, that is, when a complete fault detection process has been completed, or when the number of fault codes in the data transmission buffer of a sub-control unit reaches the set upper limit, the current data transmission buffer is locked to prevent data from being overwritten or new data from being mixed with the data to be uploaded, ensuring that the fault information can be uploaded completely. After the fault information is successfully sent, the data transmission buffer is cleared and set to an unlocked state, so that the data transmission buffer is capable of receiving the next cycle of diagnostic fault information.

[0084] In the above embodiment, the sub-control unit code is used to identify the attribution of fault information, so that the reported fault information has a clear source attribution and good distinguishability, which is convenient for subsequent fault collection, classification statistics and correlation analysis; the fault upload status is marked and tracked through the set data structure, avoiding the risk of repeated upload or missed upload, and enhancing the accuracy and reliability of fault information transmission; in addition, the CANFD communication channel bound to the sub-control unit is used to send messages, combined with the high-speed transmission capability of the CANFD bus, to ensure the real-time reporting capability of fault information in complex scenarios.

[0085] In one embodiment, an electronic device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements a method for uploading fault information of a domain controller when executing the computer program.

[0086] In one embodiment, a computer storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, a method for uploading a fault of a domain controller is implemented.

[0087] It should be noted that the logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0088] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0089] Throughout this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0090] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature identified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0091] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.< / xx>

Claims

1. A fault upload system for a domain controller, characterized in that: include: Diagnostic event management module, diagnostic event monitoring module and communication module; The diagnostic event management module is used to obtain a real-time fault list; The fault list records at least the diagnostic trouble code of the fault and the sub-control unit code that generates the diagnostic trouble code; wherein, at least two sub-control units are integrated in the domain controller; The diagnostic event monitoring module is used to obtain diagnostic trouble codes in the fault list at a set period and store the diagnostic trouble codes in corresponding data transmission buffers according to the sub-control unit codes; the data transmission buffer includes a set of set data structures, and the set data structures are used to manage the information field of the diagnostic trouble code transmission status; The communication module is used to call the CANFD communication channel bound to the sub-control unit code, and send the diagnostic fault code to the CANFD bus based on the set data structure in the data sending buffer area.

2. The domain controller fault upload system according to claim 1, characterized in that: The communication module is configured to operate when a fault detection process is completed or the data transmission buffer is full.

3. The domain controller fault upload system according to claim 1, characterized in that: The diagnostic event monitoring module is configured to lock the data sending buffer area when a fault detection process is completed or the data sending buffer area is full.

4. The domain controller fault upload system according to claim 3, characterized in that: The diagnostic event monitoring module is further configured to clear the field content of the set data structure in the data sending buffer and set the data sending buffer to an unlocked state when the diagnostic fault code cached in the data sending buffer is completely sent.

5. The domain controller fault upload system according to claim 1, characterized in that: The set data structure includes a diagnostic trouble code field, a storage lock status field, a fault quantity field, a total number of sent frames field, a sent frame number field, and a diagnostic trouble code quantity field contained in the last data frame.

6. The domain controller fault upload system according to claim 1, characterized in that: The fault list also includes the reporting code of the diagnostic fault code.

7. The domain controller fault upload system according to claim 1, characterized in that: The diagnostic event monitoring module is configured to discard the exceeding diagnostic trouble codes when the number of diagnostic trouble codes stored in the data transmission buffer exceeds a preset upper limit.

8. A method for uploading fault information of a domain controller, characterized in that: Applied to a domain controller, wherein at least two sub-control units are integrated in the domain controller, the method includes: Obtaining a fault list of all real-time faults of the sub-control units; the fault list is used to include at least a diagnostic trouble code and a sub-control unit code that generates the diagnostic trouble code; The diagnostic trouble codes in the fault list are stored in corresponding data transmission buffers according to the sub-control unit codes; the data transmission buffers include a set of setting data structures, and the setting data structures are used to manage information fields of the diagnostic trouble code transmission status; The CANFD communication channel bound to the sub-control unit code is called, and the diagnostic fault code is sent to the CANFD bus based on the set data structure in the data sending buffer area.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the fault uploading method of the domain controller according to claim 8 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the fault uploading method of the domain controller according to claim 8 is implemented.

Images