Controller fault information transmission method, electronic equipment and vehicle

Abstract

The invention discloses a controller fault information transmission method, electronic equipment and a vehicle, and relates to the technical field of vehicle fault detection. The method comprises the steps that when controller software is integrated, a bottom layer of the controller software dynamically loads a preset fault information identification list, and the fault information identification list is stored in a corresponding controller; when controller software runs, a bottom layer detects to-be-sent fault diagnosis codes with faults in real time and judges trigger state types of the to-be-sent fault diagnosis codes according to state bit values of the to-be-sent fault diagnosis codes; and sending the to-be-sent fault diagnosis code to the cloud through a corresponding CAN signal according to the trigger state category. According to the method, the fault code list is dynamically managed through the bottom software, modification of an application layer is not needed, and the fault diagnosis code status bit is automatically detected.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a controller fault information transmission method, electronic equipment, and a vehicle. Background Art

[0002] In the fault information transmission technology of vehicle controllers, the traditional method relies on application layer software to manage fault status. The specific implementation method is: set an independent flag bit or state variable for each fault code in the application layer code. When the fault is triggered, the corresponding value is sent to the cloud through a fixed signal channel. If a fault code needs to be added or deleted, the code logic related to fault status judgment and value mapping in the application layer must be modified, and then the entire control model must be recompiled and verified. This implementation method leads to deep coupling of software and hardware functions. The development process must be repeated for each fault code adjustment, which seriously restricts development efficiency.

[0003] In existing solutions, the fault information transmission mechanism typically uses a simple sequential processing model. The system sends fault values ​​one by one in a fixed, preset order, lacking flexible scheduling capabilities. When multiple faults are triggered simultaneously, the transmission channel may be occupied by non-critical faults, resulting in the delay of reporting important fault information. Furthermore, because the fault code list and transmission logic are fixed in the application layer code, any change in fault type requires modification of the data structure and processing flow at the application layer. This not only increases the complexity of code maintenance but also may cause version compatibility issues due to human error.

[0004] Therefore, how to implement a fault information transmission method that is decoupled from the application layer, automatically identify the fault status and complete data transmission through the underlying mechanism, and avoid application layer software modifications caused by fault code changes has become a technical problem that technical personnel in this field urgently need to solve. Summary of the Invention

[0005] In view of the above problems, the present disclosure provides a controller fault information transmission method, electronic device, and vehicle that overcome the above problems or at least partially solve the above problems. The technical solutions are as follows:

[0006] A controller fault information transmission method, the method comprising:

[0007] When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller;

[0008] When the controller software is running, the bottom layer detects in real time each fault diagnostic code to be sent, and determines the triggering state category of the fault diagnostic code to be sent according to the state bit value of the fault diagnostic code to be sent;

[0009] According to the trigger status category, the to-be-sent fault diagnostic code is sent to the cloud.

[0010] This disclosure provides a controller fault information transmission method that decouples fault information management from the application layer by dynamically loading a preset list of fault information identifiers at the bottom layer and detecting fault status in real time. Specifically, a fault code list is pre-set during the software integration phase and directly called by the bottom layer, eliminating the cumbersome process of modifying application layer code every time a fault code is added or removed, as in traditional solutions. During runtime, status detection and transmission control are independently completed at the bottom layer, significantly reducing application layer resource usage and improving controller development efficiency and software maintainability.

[0011] Preferably, the trigger status categories include: currently activated fault status, historically stored fault status, and fault indicator light trigger status;

[0012] According to the trigger status category, the to-be-sent fault diagnostic code is sent to the cloud, specifically including:

[0013] Sending the pending fault diagnostic code of the currently activated fault state to the cloud via the first CAN signal channel;

[0014] Sending the to-be-sent fault diagnostic code of the historically stored fault state to the cloud via the second CAN signal channel;

[0015] The to-be-sent fault diagnostic code of the fault indicator light triggering state is sent to the cloud through the third CAN signal channel.

[0016] This embodiment implements categorized fault information transmission by assigning independent CAN signal channels to different trigger status categories (currently active, historically stored, and fault indicator light triggered). This design physically isolates critical faults (such as MIL light triggering failures) from common faults, ensuring that high-priority faults are not interfered with by lower-priority data. This improves the cloud's efficiency in identifying critical faults and avoids parsing errors caused by the mixing of fault states in a traditional single channel.

[0017] Preferably, the status bits of the fault diagnostic code include: testFailed bit, confirmedDTC bit, WarningIndicator bit;

[0018] Determining the triggering state category of the to-be-sent fault diagnostic code according to the state bit value of the to-be-sent fault diagnostic code specifically includes:

[0019] If the activation status bit testFailed of the fault diagnostic code to be sent is 1, it is determined to be the current activation fault state; if the storage status bit confirmedDTC of the fault diagnostic code to be sent is 1, it is determined to be the historical storage fault state; if the indicator light trigger status bit WarningIndicator of the fault diagnostic code to be sent is 1, it is determined to be the fault indicator light trigger state.

[0020] This embodiment uses status bits (activation status bit, storage status bit, and indicator light trigger status bit) to determine fault status, ensuring standardization and traceability of classification logic. By rigidly binding status bit values ​​to fault categories, the risk of misjudgment introduced by custom application-layer judgment rules is avoided. A unified status identification basis is provided for cloud-based analysis, enhancing the consistency of diagnostic results.

[0021] Preferably, the method further comprises:

[0022] Constructing the fault information identification list specifically includes:

[0023] Determining fault diagnostic codes to be preset based on the fault detection requirements of the controller, and numbering the fault diagnostic codes to be preset;

[0024] Performing fault level evaluation on the controller faults corresponding to the fault diagnostic codes to be preset, and determining the working condition processing priority of each controller fault;

[0025] The controller identification, fault number, fault diagnostic code, fault level, and operating condition priority of the controller are written into the fault information identification list.

[0026] This embodiment pre-sets fault levels and operating condition priorities in the fault information identification list, providing a basis for dynamic scheduling decisions. By binding and storing priority parameters with fault codes, the underlying layer can directly call the list data for transmission and sorting, eliminating the need for real-time calculations at the application layer. This ensures real-time scheduling while avoiding the scalability limitations of traditional solutions that hard-code priority rules.

[0027] Preferably, the method further comprises:

[0028] When sending a pending diagnostic fault code to the cloud via the CAN signal channel, determining whether there are other diagnostic fault codes queued for transmission;

[0029] If so, query the fault information identification list to determine the sending order of the fault diagnostic codes to be sent according to the priority information corresponding to the fault diagnostic codes to be sent; wherein the priority information includes: operating condition priority, fault level and fault number.

[0030] Preferably, determining the sending order of the to-be-sent fault diagnostic codes according to the priority information corresponding to the to-be-sent fault diagnostic codes specifically includes:

[0031] Comparing the priority information of the to-be-sent fault diagnostic code with the priority information of other fault diagnostic codes queued for sending in order of queuing, and comparing the priority information in order of working condition priority, fault level and fault number;

[0032] During the sequential comparison, if there is another fault diagnostic code whose priority information is lower than the priority information of the fault diagnostic code to be sent, the fault diagnostic code to be sent is placed in front of the other fault diagnostic code in the queuing sequence.

[0033] This embodiment uses a multi-level priority comparison mechanism (operating condition > fault level > fault number) to implement dynamic queue scheduling. When a high-priority fault is triggered, the transmission order is automatically adjusted through this level-by-level comparison mechanism, ensuring that critical faults take priority in the transmission channel. This solves the queuing delay problem of high-priority faults in traditional fixed polling mechanisms and avoids the waste of computing resources caused by global reordering.

[0034] Preferably, the method further comprises:

[0035] According to the abnormal operating condition sending requirement preset by the controller, the abnormal operating condition code of the non-fault diagnostic code type and the corresponding abnormal operating condition information are added to the fault information identification list;

[0036] When abnormal state identification information to be sent indicating an abnormal working condition is detected by the bottom layer, the abnormal state identification information is sent to the cloud via a CAN signal.

[0037] This embodiment integrates non-fault abnormal condition codes into the fault information identification list, expanding the scope of low-level status monitoring. By uniformly managing fault codes and abnormal condition codes, existing status detection and transmission mechanisms can be reused, eliminating the need to develop separate processing modules for newly added abnormality types. This significantly reduces the development cost of functional expansion while improving the completeness of abnormal information reporting.

[0038] Preferably, the method further comprises:

[0039] When the controller includes several sub-controllers, an independent CAN signal channel group is allocated to each sub-controller;

[0040] When constructing the fault information identification list, based on the fault detection requirements of each sub-controller, the fault diagnostic codes to be preset are determined, and after the fault diagnostic codes to be preset are numbered, each fault number is bound to the sub-controller identification of each sub-controller;

[0041] When the bottom layer detects that the controller has failed and needs to send the corresponding fault diagnostic code to be sent to the cloud, the fault number corresponding to the fault diagnostic code to be sent is queried to determine the CAN signal channel group to be sent based on the sub-controller identifier bound to the fault number.

[0042] This embodiment integrates non-fault abnormal condition codes into the fault information identification list, expanding the scope of low-level status monitoring. By uniformly managing fault codes and abnormal condition codes, existing status detection and transmission mechanisms can be reused, eliminating the need to develop separate processing modules for newly added abnormality types. This significantly reduces the development cost of functional expansion while improving the completeness of abnormal information reporting.

[0043] An electronic device, comprising:

[0044] at least one processor;

[0045] and, a memory communicatively coupled to the at least one processor;

[0046] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the controller fault transmission and sending methods described above.

[0047] A vehicle, comprising:

[0048] a memory for storing executable program code;

[0049] A processor is used to call and run the executable program code from the memory, so that the vehicle executes any one of the controller fault transmission and sending methods described above.

[0050] The above description is only an overview of the technical solution of the present disclosure. In order to more clearly understand the technical means of the present disclosure, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present disclosure more obvious and easy to understand, the specific implementation methods of the present disclosure are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0052] Figure 1 A flow chart of a controller fault information transmission method provided in an embodiment of the present application;

[0053] Figure 2A schematic diagram of a controller fault information transmission process provided in an embodiment of the present application;

[0054] Figure 3 A schematic diagram of the internal structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0056] With the increasing complexity of onboard controller fault diagnosis requirements, achieving efficient management and reliable transmission of fault information has become a key bottleneck restricting the efficiency of automotive electronic system development. Traditional solutions embed fault code storage, status determination, and transmission logic within the application-layer software, resulting in three core system flaws: First, the addition, deletion, and modification of fault codes require simultaneous adjustments to the application-layer code, causing the development cycle to increase linearly with iteration frequency; second, fault transmission utilizes a fixed-sequence processing mechanism, making it impossible to dynamically adjust transmission strategies based on real-time needs. This can lead to critical fault information being missed due to queuing delays; third, the fault information list is deeply coupled with the application layer, requiring any changes to recompile and verify the entire software model, significantly increasing the complexity of version maintenance.

[0057] Specifically, the existing technology has the following technical shortcomings:

[0058] 1. Tight coupling at the application layer: Fault code storage and status management are completely dependent on application-layer code. Adding or deleting fault codes requires manual modification of the application-layer fault flag logic, value mapping, and transmission control flow. This design not only leads to rigid software architecture but also introduces version compatibility risks due to frequent code modifications. For example, when the same controller is adapted for different vehicle models, separate application-layer fault handling modules must be maintained for each vehicle.

[0059] 2. Rigid fault reporting mechanism: Traditional solutions use a first-come, first-served sequential reporting strategy, which fails to identify the severity of faults. When high-level faults (such as powertrain failure) and common faults (such as sensor offset) are triggered simultaneously, the system still processes them sequentially according to a fixed order. This prevents the critical fault from preempting the transmission channel, potentially missing the regulatory reporting window.

[0060] 3. High list maintenance costs: Fault information lists (including fault numbers, diagnostic codes, etc.) are hard-coded in the application-layer software. Any adjustments to the list structure require modifications to the data structure definition, status monitoring logic, and communication protocol configuration at the application layer. This highly coupled implementation limits list scalability. For example, adding a new fault type requires searching and modifying the list-related code in the application layer line by line, which can easily lead to logical errors due to human oversight.

[0061] To solve the above problems, this application provides a controller fault information transmission method, such as Figure 1 As shown, Figure 1 A flow chart of a controller fault information transmission method provided in an embodiment of the present application specifically includes the following steps:

[0062] Step 101: When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller.

[0063] In this embodiment, the controller software integration stage needs to complete the presetting and loading of the fault information identification list.

[0064] In one embodiment of the present application, before the controller software is integrated, it is also necessary to construct a fault information identification list of the controller, specifically including: determining the fault diagnostic code to be preset based on the fault detection requirements of the controller, and numbering the fault diagnostic code to be preset; performing a fault level evaluation on the controller fault corresponding to the fault diagnostic code to be preset, and determining the working condition processing priority of each controller fault; writing the controller identification, fault number, fault diagnostic code, fault level, and working condition priority of the controller into the fault information identification list.

[0065] It is understandable that the fault information identification list described in this embodiment is the core configuration file that drives the fault management logic, and its essence is a structured data table. The list includes controller identification (used to distinguish different controller nodes, such as BMS, TCU), fault number (unique identifier, such as DTC_55), fault diagnostic code (coding that complies with the OBD-II standard, such as P0A01), fault level (such as high / medium / low), working condition priority (such as charging scenario priority 1) and sub-controller binding identification (for multi-controller architecture). It is understandable that the field design of the list is not a fixed template, but is dynamically expanded according to the functional requirements of the vehicle model or controller. For example, custom parameters such as "fault recovery threshold time" or "number of signal retransmissions" can be added.

[0066] In this embodiment, the fields of the fault information identification list are defined as shown in Table 1 below:

[0067]

[0068] Table 1

[0069] It should be noted that the implementation logic of the "dynamic loading" depends on the initialization process of the underlying software. Specifically, in the controller software integration stage (i.e., code compilation and burning), the underlying layer extracts the contents of the fault information identification list from an external storage device (such as a USB flash drive or OTA upgrade package) by calling a preset configuration file parsing interface (such as an XML parser or a database reading module), and converts it into an in-memory data structure (such as a hash table or a linked list), and finally stores it in the controller's non-volatile memory (such as Flash). This process decouples the fault management logic from the main body of the controller software. For example, when a new fault code is added, it is only necessary to update the external configuration file and reload it without modifying the underlying or application layer code.

[0070] It is understandable that the key advantages of the dynamic loading mechanism lie in scalability and adaptability. Specifically, when the vehicle model is upgraded or the controller function is changed, the developer only needs to modify the field content in the configuration file (such as adding DTC_56 corresponding to "motor overheating fault"), and the underlying software will automatically load the updated list during the next integration without the need to rewrite or verify the code logic. This feature is particularly suitable for smart connected vehicles that require rapid iteration. For example, in response to differences in emission regulations in different regions, localized adaptation can be achieved by adjusting the fault level or operating condition priority field.

[0071] It's important to emphasize that the storage location of the fault information identification list (non-volatile memory) ensures that configuration data is not lost after a system power outage. At the same time, the underlying system can quickly access the list contents through memory mapping during runtime, avoiding the performance loss caused by frequent reading and writing to the storage medium. Furthermore, this list provides a unified data source for subsequent steps (such as status detection, priority determination, and multi-controller routing), ensuring the coherence and consistency of the entire fault management process.

[0072] Step 102: When the controller software is running, the bottom layer detects each pending fault diagnostic code in real time, and determines the triggering state category of the pending fault diagnostic code according to the state bit value of the pending fault diagnostic code.

[0073] In one embodiment of the present application, the trigger status categories include: currently activated fault status, historically stored fault status, and fault indicator light trigger status.

[0074] In one embodiment of the present application, the status bits of the fault diagnostic code include: a testFailed bit, a confirmedDTC bit, and a WarningIndicator bit; based on the status bit value of the fault diagnostic code to be sent, the trigger status category of the fault diagnostic code to be sent is determined, specifically including: if the testFailed bit of the fault diagnostic code to be sent is 1, it is determined to be a currently activated fault state; if the confirmedDTC bit of the fault diagnostic code to be sent is 1, it is determined to be a historically stored fault state; if the WarningIndicator bit of the fault diagnostic code to be sent is 1, it is determined to be a fault indicator light trigger state.

[0075] In this embodiment, during controller operation, the underlying software continuously monitors for faults. When a fault occurs, the underlying software detects each pending diagnostic trouble code (DTC) associated with the fault to determine the status bit value of each DTC and classifies the fault trigger status according to predefined determination rules.

[0076] In this embodiment, the status bit is a core flag bit in the controller register that represents the life cycle status of a diagnostic trouble code (DTC).

[0077] For example, taking the fault entry of the "MCU_001" controller in Table 1 as an example, its status bit parsing logic is as follows:

[0078] TestFailed bit (bit 0): This bit is automatically set to 1 by the underlying layer when a fault condition is detected in real time. For example, when the motor temperature sensor returns a value exceeding a threshold (such as 100°C), the testFailed bit of the "Motor Overtemperature" fault (fault number 1001) is set to 1, indicating that the fault is active.

[0079] ConfirmedDTC bit (bit 3): If the testFailed bit remains set to 1 for a period exceeding a preset time (e.g., 3 seconds), this bit is set to 1 and triggers fault storage. For example, for a "CAN communication timeout" fault (fault number 1002), if communication is interrupted for 3 seconds, the confirmedDTC bit is set to 1 by the bottom layer, indicating that the fault has been confirmed and recorded in the history record.

[0080] WarningIndicator bit (bit 7): When the fault triggers the vehicle warning device (such as the MIL light), this bit is set to 1. For example, if the fault level of the "Insufficient Coolant Flow" fault (fault number 1003) is configured to trigger an alarm, the bottom layer will set the WarningIndicator bit when the testFailed bit is set to 1.

[0081] It should be noted that the determination of the status bit is closely related to the fields in the fault information identification list. Specifically, after detecting that the testFailed bit of a DTC is 1, the bottom layer first queries the "applicable working conditions" field of the DTC in the list to verify whether the current vehicle status matches. For example, for the "CAN communication timeout" fault (fault number 1002), if the current vehicle is in the "charging" working condition (the applicable working condition field is "charging"), the confirmedDTC position 1 logic takes effect; if the vehicle is in other working conditions, it is only marked as a temporary fault and does not trigger the confirmedDTC bit update.

[0082] It is understandable that the determination of the trigger status category requires a comprehensive consideration of the status bit combination and the configuration rules in the list:

[0083] Current active fault status: When the testFailed bit is 1 and the confirmedDTC bit is 0, the fault is considered current regardless of the operating conditions. For example, when the motor overtemperature fault (1001) detects a temperature exceeding the limit for the first time, the testFailed bit is set to 1 and the fault is immediately marked as current active.

[0084] Historical storage fault status: When the confirmedDTC bit is 1 and the WarningIndicator bit is 0, it is considered a historical fault. For example, after the CAN communication timeout fault (1002) is restored, the testFailed bit is reset to 0, but the confirmedDTC bit remains 1. In this case, it is only uploaded as a historical record.

[0085] Fault indicator trigger status: When the WarningIndicator bit is 1, an alarm is triggered regardless of the status of other bits. For example, if the testFailed bit and the WarningIndicator bit of the Coolant Flow Insufficient fault (1003) are both set to 1, the Fault Indicator trigger status takes precedence.

[0086] Step 103: Send the fault diagnostic code to be sent to the cloud according to the trigger status category.

[0087] In one embodiment of the present application, according to the trigger state category, the to-be-sent fault diagnostic code is sent to the cloud, specifically including: sending the to-be-sent fault diagnostic code of the currently activated fault state to the cloud via the first CAN signal channel; sending the to-be-sent fault diagnostic code of the historically stored fault state to the cloud via the second CAN signal channel; sending the to-be-sent fault diagnostic code of the fault indicator light trigger state to the cloud via the third CAN signal channel.

[0088] In this embodiment, the allocation logic of the CAN signal channel is strictly bound to the fault status category to ensure the transmission isolation and priority protection of different types of faults. For example, combined with the fault entry of the MCU_001 controller in the table, its sending rules are as follows:

[0089] The first CAN signal channel is dedicated to transmitting the DTC corresponding to the currently active fault state. For example, when the testFailed bit of the "Motor Overtemperature" fault (fault number 1001) is 1 and the confirmedDTC bit is 0, the bottom layer automatically selects the first channel to transmit the fault code, ensuring that real-time fault information is uploaded to the cloud first for immediate diagnosis and decision-making.

[0090] The second CAN signal channel is used to transmit DTCs corresponding to historically stored fault states. For example, if the "CAN communication timeout" fault (fault number 1002) is set to 1 and the current operating condition is "Charging," the underlying layer sends it through the second channel for the cloud to trace historical fault records.

[0091] The third CAN signal channel is dedicated to transmitting the DTC corresponding to the fault indicator light triggering status. For example, when the WarningIndicator bit of the "Insufficient Coolant Flow" fault (fault number 1003) is 1, the underlying layer sends it through the third channel, synchronously triggering the illumination of the MIL light on the vehicle's instrument panel, meeting the regulatory requirement for independent reporting of safety-related faults.

[0092] It should be noted that the channel selection logic is linked to the "Applicable Operating Conditions" and "Operating Condition Priority" fields in the fault information identification list. Specifically, the bottom layer will verify whether the current vehicle operating condition matches the "Applicable Operating Conditions" configured in the list before sending. For example, if the applicable operating condition for the "CAN communication timeout" fault (fault number 1002) is "charging", but the current vehicle is in driving state, then even if the confirmedDTC bit is 1, the bottom layer will not send the fault code through the second channel to avoid invalid data interfering with cloud diagnosis.

[0093] It's understandable that the same DTC may trigger multiple status categories simultaneously. In this case, the underlying layer coordinates the sending order according to pre-set conflict rules. For example, if the testFailed bit and WarningIndicator bit of the "Insufficient Coolant Flow" fault (fault number 1003) are both 1 (i.e., currently active and requiring the MIL to be triggered), the underlying layer will prioritize sending the MIL trigger signal via the third channel, and then supplement the current active status information via the first channel, ensuring that critical warning actions are not delayed.

[0094] In one embodiment of the present application, when the fault diagnostic code to be sent is sent to the cloud through the CAN signal channel, it is determined whether there are other fault diagnostic codes queued for sending; if so, the fault information identification list is queried to determine the sending order of the fault diagnostic codes to be sent based on the priority information corresponding to the fault diagnostic codes to be sent; wherein, the priority information includes: operating condition priority, fault level and fault number.

[0095] In one embodiment of the present application, the sending order of the fault diagnostic code to be sent is determined based on the priority information corresponding to the fault diagnostic code to be sent, specifically including: comparing the priority information of the fault diagnostic code to be sent with other fault diagnostic codes in the queue in order, and when comparing the priority information, comparing them in sequence according to the operating condition priority, fault level and fault number; when comparing in sequence, if there is another fault diagnostic code whose priority information is lower than the priority information of the fault diagnostic code to be sent, then the fault diagnostic code to be sent is placed in front of the other fault diagnostic code in the queue sequence.

[0096] In this embodiment, the dynamic priority adjustment mechanism is the core strategy to ensure timely upload of critical faults. Its essence is an adaptive sorting algorithm based on multi-dimensional rules. For example, taking the fault entry of the MCU_001 controller in Table 1 as an example, when multiple faults are triggered at the same time, the bottom layer is sorted according to the following rules:

[0097] Working condition priority: Prioritizes faults that match the current vehicle scenario and have a lower working condition priority value. For example, if the vehicle is in the "Charging" working condition, "CAN communication timeout" (fault number 1002, working condition priority 1) takes precedence over "Motor overtemperature" (fault number 1001, working condition priority 2), even if the latter fault level is higher;

[0098] Fault level: If multiple faults have the same priority, the fault with the higher fault level will be sent first. For example, in the "driving" condition, if "motor overtemperature" (level 3) and "insufficient coolant flow" (level 2) are triggered at the same time, the former will be sent first.

[0099] Fault Number: If the operating condition priority and fault level are the same, the fault with the higher fault number will be sent first. For example, if two faults of the same level (such as "Insufficient Coolant Flow" and another fictitious fault number 1004) are triggered under "All Operating Conditions", fault number 1004 will be sent first.

[0100] It should be noted that the dynamic sorting process is deeply bound to the real-time vehicle status. Specifically, the bottom layer will re-acquire the current working condition before each transmission (such as reading the vehicle mode signal through the CAN bus) and refresh the priority calculation result. For example, when the vehicle switches from "charging" to "driving", the "CAN communication timeout" fault (working condition priority 1) that was originally sent first may be suspended due to its applicability mismatch under the new working condition, and the "motor overtemperature" fault (working condition priority 2) will be prioritized.

[0101] It's understandable that the queue insertion strategy is a key implementation of dynamic adjustments. When a new fault is triggered, the underlying layer will traverse the existing faults in the sending queue, comparing the operating condition priority, fault level, and fault number in turn, and inserting the new fault into the appropriate position according to the rules. For example, if "Insufficient Coolant Flow" (operating condition priority 3) already exists in the queue, and a new "CAN Communication Timeout" (operating condition priority 1) is triggered, the latter will be directly inserted into the head of the queue; if there are faults with the same operating condition priority in the queue, they will be further sorted by fault level and number.

[0102] In one embodiment of the present application, the method further includes: adding abnormal operating condition codes that are not fault diagnostic codes and corresponding abnormal operating condition information to the fault information identification list according to the abnormal operating condition sending requirements preset by the controller; when the abnormal status identification information to be sent of the abnormal operating condition is detected by the bottom layer, the abnormal status identification information is sent to the cloud via a CAN signal.

[0103] In this embodiment, the non-fault abnormal operating condition code refers to an abnormal state that does not reach the DTC trigger threshold but requires monitoring. Its expansion mechanism breaks through the boundaries of traditional fault code management. For example, for the MCU_001 controller, the following non-fault entry can be added to the fault information identification list: Controller Identifier: MCU_001, Fault Number: 2001 (Extended Number Range), Name: Motor Temperature Pre-alarm, Abnormal Operating Condition Code: EX_01, Trigger Condition: Motor Temperature ≥ 90°C and < 100°C (Does not reach the fault threshold of 100°C).

[0104] It should be noted that the integrated logic for non-fault anomalies coexists with traditional DTC but is managed independently. Specifically, when the bottom layer detects an abnormal operating condition (such as a motor temperature reaching 95°C), it marks EX_01 as a "non-fault" type, but still reuses the fault code transmission channel and priority scheduling rules. For example, when EX_01 is triggered, the bottom layer sends data via the first CAN channel (originally used for the currently active fault), but adds a "non-fault" flag in the message for the cloud to distinguish and process.

[0105] It's understandable that the configuration rules for abnormal operating condition codes are highly compatible with DTCs. For example, EX_01 can be bound to the "Monitoring Level" fault level and the applicable operating condition "Driving," and participate in dynamic prioritization. When MCU_001 simultaneously reports "Motor Overtemperature" (fault number 1001, Level 3) and "Motor Temperature Pre-alarm" (EX_01, Monitoring Level), the underlying system prioritizes 1001 according to the rules, but inserts EX_01 between these two signals to ensure that the warning information isn't completely blocked.

[0106] In one embodiment of the present application, the method also includes: when the controller includes several sub-controllers, allocating an independent CAN signal channel group to each sub-controller; when constructing the fault information identification list, based on the fault detection requirements of each sub-controller, determining the fault diagnostic code to be preset, and after numbering the fault diagnostic code to be preset, binding each fault number with the sub-controller identification of each sub-controller; when the bottom layer detects that the controller has a fault and the corresponding fault diagnostic code to be sent needs to be sent to the cloud, querying the fault number corresponding to the fault diagnostic code to be sent to determine the CAN signal channel group to be sent according to the sub-controller identification bound to the fault number.

[0107] In this embodiment, the fault management mechanism for the multi-controller scenario achieves cross-controller fault code coordination through channel group isolation and identifier binding. For example, assuming that the controller system includes a motor controller (MCU_001) and a battery management system (BMS_002), its construction and sending logic is as follows:

[0108] 1. Independent CAN channel group assignment: MCU_001 is assigned channel group 1 (including the first, second, and third CAN channels), and BMS_002 is assigned channel group 2 (including the fourth, fifth, and sixth CAN channels). Channel groups can be divided based on the physical CAN bus (for example, channel group 1 uses CAN1, channel group 2 uses CAN2) or logical message ID ranges (for example, channel group 1 uses IDs 0x100-0x1FF, channel group 2 uses IDs 0x200-0x2FF), ensuring physical / logical isolation of signals from different sub-controllers.

[0109] Fault number and subcontroller ID binding: In the fault information ID list, each fault number is associated with its corresponding subcontroller ID. For example, fault number 1001 (motor overtemperature) for MCU_001 and fault number 1001 (battery overvoltage) for BMS_002 are distinguished by the subcontroller ID field (MCU_001 / BMS_002), achieving numerical reuse but logical isolation.

[0110] It should be noted that the dynamic configurability of channel group allocation and binding relationships is the core of supporting system expansion. Specifically, when a new sub-controller is added (such as a new transmission controller TCU_003), it is only necessary to add the fault entry of TCU_003 to the list and assign it an idle channel group (such as channel group 3), without modifying the underlying communication protocol or scheduling algorithm. For example, the fault number 1001 of TCU_003 can be defined as "clutch slip", and the sub-controller identifier TCU_003 can be used to distinguish it from the faults of the same number of MCU_001 and BMS_002.

[0111] It is understandable that the channel group selection during transmission is completely dependent on the subcontroller identifier. When the bottom layer detects a fault triggered by a subcontroller (such as BMS_002), it performs the following operations: query the fault information identifier list to obtain the subcontroller identifier (BMS_002) bound to the fault number; match the preset channel group (channel group 2) based on the identifier; and select the specific channel within the channel group according to the status category (such as currently active or historically stored) (for example, the first channel of channel group 2 is used for the currently active fault).

[0112] For example, when MCU_001 and BMS_002 trigger fault number 1001 at the same time: MCU_001's 1001 (motor overtemperature) is sent through the first CAN channel of channel group 1; BMS_002's 1001 (battery overvoltage) is sent through the first CAN channel of channel group 2; the cloud resolves the fault attribution based on the channel group ID and sub-controller identification field to avoid misjudgment due to duplicate numbers.

[0113] Furthermore, channel group isolation significantly reduces the risk of bus load conflicts. For example, when MCU_001 frequently reports high-priority faults, its communication only uses the resources of channel group 1, while BMS_002's faults are independently transmitted through channel group 2, without blocking each other. This design is particularly suitable for high-concurrency multi-controller scenarios, ensuring timely fault reporting for critical sub-controllers.

[0114] In a possible implementation of the present application, the above-described embodiment of the present application provides a method for sending controller fault information, and its overall process is as follows: Figure 2 As shown, Figure 2 A schematic diagram of a controller fault information sending process provided in an embodiment of the present application.

[0115] The above is an embodiment of the method proposed in this application. Based on the same inventive concept, the embodiment of this application also provides a device, the structure of which is as follows Figure 3 shown.

[0116] Figure 3 This is a schematic diagram of the internal structure of a device provided in an embodiment of the present application. Figure 3As shown, the equipment includes:

[0117] at least one processor 301;

[0118] and, a memory 302 in communication with the at least one processor;

[0119] The memory 302 stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor 301 to enable the at least one processor 301 to:

[0120] When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller;

[0121] When the controller software is running, the bottom layer detects in real time each fault diagnostic code to be sent, and determines the triggering state category of the fault diagnostic code to be sent according to the state bit value of the fault diagnostic code to be sent;

[0122] According to the trigger status category, the fault diagnostic code to be sent is sent to the cloud via the corresponding CAN signal.

[0123] Based on the same inventive concept, an embodiment of the present application further provides a vehicle, comprising:

[0124] a memory for storing executable program code;

[0125] A processor, configured to call and run the executable program code from the memory, so that the vehicle can:

[0126] When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller;

[0127] When the controller software is running, the bottom layer detects in real time each fault diagnostic code to be sent, and determines the triggering state category of the fault diagnostic code to be sent according to the state bit value of the fault diagnostic code to be sent;

[0128] According to the trigger status category, the fault diagnostic code to be sent is sent to the cloud via the corresponding CAN signal.

[0129] Some embodiments of the present application provide corresponding Figure 1 A non-volatile computer storage medium stores computer executable instructions, wherein the computer executable instructions are configured as follows:

[0130] When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller;

[0131] When the controller software is running, the bottom layer detects in real time each fault diagnostic code to be sent, and determines the triggering state category of the fault diagnostic code to be sent according to the state bit value of the fault diagnostic code to be sent;

[0132] According to the trigger status category, the fault diagnostic code to be sent is sent to the cloud via the corresponding CAN signal.

[0133] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from the other embodiments. In particular, the IoT device and media embodiments are generally similar to the method embodiments, so their description is relatively simple. For relevant portions, refer to the description of the method embodiments.

[0134] The system and medium provided in the embodiments of the present application correspond one-to-one to the method. Therefore, the system and medium also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the system and medium will not be repeated here.

[0135] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0136] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0137] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0138] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0139] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0140] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0141] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0142] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0143] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A controller fault information transmission method, characterized in that: The method comprises: When the controller software is integrated, the bottom layer of the controller software dynamically loads a preset fault information identification list and stores the fault information identification list in the corresponding controller; When the controller software is running, the bottom layer detects in real time each fault diagnostic code to be sent, and determines the triggering state category of the fault diagnostic code to be sent according to the state bit value of the fault diagnostic code to be sent; According to the trigger status category, the fault diagnosis to be sent is sent to the cloud.

2. A controller fault information transmission method according to claim 1, characterized in that: The trigger status categories include: currently activated fault status, historically stored fault status, and fault indicator light trigger status; According to the trigger status category, the to-be-sent fault diagnostic code is sent to the cloud, specifically including: Sending the pending fault diagnostic code of the currently activated fault state to the cloud via the first CAN signal channel; Sending the to-be-sent fault diagnostic code of the historically stored fault state to the cloud via the second CAN signal channel; The to-be-sent fault diagnostic code of the fault indicator light triggering state is sent to the cloud through the third CAN signal channel.

3. A controller fault information transmission method according to claim 2, characterized in that: The status bits of the fault diagnostic code include: an activation status bit, a storage status bit, and an indicator light triggering status bit; Determining the triggering state category of the to-be-sent fault diagnostic code according to the state bit value of the to-be-sent fault diagnostic code specifically includes: If the activation status bit of the fault diagnostic code to be sent is 1, it is determined to be the current activation fault state; if the storage status bit of the fault diagnostic code to be sent is 1, it is determined to be the historical storage fault state; if the indicator light trigger status bit of the fault diagnostic code to be sent is 1, it is determined to be the fault indicator light trigger state.

4. A controller fault information transmission method according to claim 1, characterized in that: The method further comprises: Constructing the fault information identification list specifically includes: Determining fault diagnostic codes to be preset based on the fault detection requirements of the controller, and numbering the fault diagnostic codes to be preset; Performing fault level evaluation on the controller faults corresponding to the fault diagnostic codes to be preset, and determining the working condition processing priority of each controller fault; The controller identification, fault number, fault diagnostic code, fault level, and operating condition priority of the controller are written into the fault information identification list.

5. A controller fault information transmission method according to claim 2, characterized in that: The method further comprises: When sending a pending diagnostic fault code to the cloud via the CAN signal channel, determining whether there are other diagnostic fault codes queued for transmission; If so, query the fault information identification list to determine the sending order of the fault diagnostic codes to be sent according to the priority information corresponding to the fault diagnostic codes to be sent; wherein the priority information includes: operating condition priority, fault level and fault number.

6. A controller fault information transmission method according to claim 5, characterized in that: Determining the order in which the diagnostic fault codes to be sent are sent according to the priority information corresponding to the diagnostic fault codes to be sent, specifically including: Comparing the priority information of the to-be-sent fault diagnostic code with the priority information of other fault diagnostic codes queued for sending in order of queuing, and comparing the priority information in order of working condition priority, fault level and fault number; During the sequential comparison, if there is another fault diagnostic code whose priority information is lower than the priority information of the fault diagnostic code to be sent, the fault diagnostic code to be sent is placed in front of the other fault diagnostic code in the queuing sequence.

7. A controller fault information transmission method according to claim 1, characterized in that: The method further comprises: According to the abnormal operating condition sending requirement preset by the controller, the abnormal operating condition code of the non-fault diagnostic code type and the corresponding abnormal operating condition information are added to the fault information identification list; When abnormal state identification information to be sent indicating an abnormal working condition is detected by the bottom layer, the abnormal state identification information is sent to the cloud via a CAN signal.

8. A controller fault information transmission method according to claim 1, characterized in that: The method further comprises: When the controller includes several sub-controllers, an independent CAN signal channel group is allocated to each sub-controller; When constructing the fault information identification list, based on the fault detection requirements of each sub-controller, the fault diagnostic codes to be preset are determined, and after the fault diagnostic codes to be preset are numbered, each fault number is bound to the sub-controller identification of each sub-controller; When the bottom layer detects that the controller has failed and needs to send the corresponding fault diagnostic code to be sent to the cloud, the fault number corresponding to the fault diagnostic code to be sent is queried to determine the CAN signal channel group to be sent based on the sub-controller identifier bound to the fault number.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 8.

10. A vehicle, characterized in that: The vehicle comprises: a memory for storing executable program code; A processor is configured to call and run the executable program code from the memory, so that the vehicle executes the method according to any one of claims 1 to 8.

Images