Fault code clearing method of OBD system, electronic equipment and vehicle

Abstract

The invention discloses a fault code clearing method of an OBD system, electronic equipment and a vehicle, and relates to the technical field of vehicle fault detection. The method comprises the following steps: after receiving an OBD fault code clearing instruction sent by a diagnostic instrument, a first-stage controller broadcasts the OBD fault code clearing instruction and closes diagnosis enabling of a plurality of second-stage controllers; and in a first preset time window after the diagnosis enable of the plurality of secondary controllers is closed, if the primary controller receives a clearing completion signal of any secondary controller, the diagnosis enable of the corresponding secondary controller is started. The primary controller actively closes the diagnosis enabling of the secondary controller after receiving the diagnostic instrument clearing instruction, and dynamically manages the diagnosis enabling state in the preset time window according to the real-time feedback of the secondary controller, so that the problem of false alarm caused by asynchronous fault clearing of the secondary controller and the primary controller is solved.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle fault detection, and in particular to a method for clearing fault codes of an OBD system, an electronic device, and a vehicle. Background Art

[0002] Against the backdrop of the rapid development of intelligent and connected new energy vehicles, the on-board diagnostics (OBD) system, as a core module for vehicle health monitoring and fault management, faces increasing challenges in overall vehicle safety and maintenance costs due to its responsiveness and operational reliability. This is particularly true for vehicles with a multi-controller distributed architecture, where fault code clearing requires coordinated execution across multiple electronic control units. Traditional solutions present increasingly significant performance bottlenecks.

[0003] The current mainstream fault code clearing method relies on a point-to-point serial communication mechanism between the diagnostic instrument and the controller. The diagnostic instrument needs to send instructions to each controller one by one and wait for a response, resulting in the operation time increasing linearly with the number of controllers. For example, in a vehicle model that includes multiple modules such as battery management, motor control, and on-board charging, the complete clearing process may exceed 10 seconds, which cannot meet the needs of efficient operation and maintenance. Although some improvement schemes attempt to trigger multiple controllers simultaneously through broadcast communication, the periodic signal transmission mechanism they use has inherent defects: in the high-load scenario of the vehicle bus, periodic instructions are easily interrupted by high-priority signals, and there is a lack of a retransmission guarantee mechanism after the signal is lost, causing some controllers to miss the clearing operation and residual fault codes to cause the risk of misjudgment.

[0004] Furthermore, existing methods have serious deficiencies in multi-controller state coordination and operational atomicity. The diagnostic instrument determines the global result based only on the feedback of some controllers and cannot accurately identify the status of unresponsive units, resulting in false positives in the clearing results. In addition, traditional solutions do not synchronously block the controller's fault code writing function. If a new fault is triggered during the clearing process, the fault code may be written to the memory again, forming a "clear-regenerate" cycle. Such problems not only affect diagnostic accuracy, but also accelerate memory aging due to frequent erase and write operations, reducing the life of the controller.

[0005] Therefore, how to achieve efficient synchronous clearing of fault codes in a multi-controller distributed architecture and ensure the reliability of instruction transmission, state coordination consistency and operation atomicity has become a technical problem that technical personnel in this field urgently need to solve. Summary of the Invention

[0006] In view of the above problems, the present disclosure provides a method for clearing fault codes of an OBD system, an electronic device, and a vehicle that overcome the above problems or at least partially solve the above problems. The technical solutions are as follows:

[0007] A method for clearing fault codes of an OBD system is characterized in that it is applied to an OBD system comprising a diagnostic instrument, a primary controller, and a plurality of secondary controllers, and the method comprises:

[0008] After receiving the OBD fault code clearing instruction sent by the diagnostic instrument, the primary controller broadcasts the OBD fault code clearing instruction and turns off the diagnostic enable of the plurality of secondary controllers;

[0009] Within a first preset time window after the diagnosis enable of the plurality of secondary controllers is turned off, if the primary controller receives a clearing completion signal from any secondary controller, the diagnosis enable of the corresponding secondary controller is turned on.

[0010] The present disclosure provides a fault code clearing method for an OBD system. By enabling the primary controller to proactively disable the diagnostic enable of the secondary controller upon receiving a clear command from a diagnostic instrument, and dynamically managing the diagnostic enable status within a preset time window based on real-time feedback from the secondary controller, the method addresses the issue of false alarms caused by the asynchronous clearing of faults between the secondary and primary controllers. Specifically, during the period when the diagnostic enable is disabled, the primary controller preemptively restores its diagnostic function based solely on the clearing completion signal from the secondary controller, rather than relying on a fixed waiting time. This avoids the problem of the primary controller falsely reporting a fault code even though the secondary controller has cleared the fault, while ensuring rapid recovery of the system's diagnostic logic after the fault is cleared.

[0011] Optionally, after the primary controller receives the OBD fault code clearing instruction sent by the diagnostic instrument, the method further includes:

[0012] The first fault code clearing mechanism is triggered to clear the OBD fault code of the primary controller.

[0013] This embodiment eliminates the risk of misjudgment caused by residual fault codes in the primary controller by immediately clearing its own fault codes upon receiving a clear command. This mechanism enables the primary controller to complete its own state initialization before coordinating the clearing process with the secondary controller. This ensures that the subsequent judgment logic for feedback to the secondary controller is not interfered with by the primary controller's own fault state, thereby improving the reliability of overall fault clearing.

[0014] Optionally, broadcasting the OBD fault code clearing instruction specifically includes:

[0015] The primary controller periodically broadcasts the OBD fault code clearing instruction a preset number of times in a pulse sequence via the CAN bus using an event-type signal;

[0016] After completing the broadcast of the OBD fault code clearing instruction, the default signal is periodically broadcast a preset number of times in a pulse sequence via the CAN bus.

[0017] This embodiment uses event-based signals combined with pulse sequences to broadcast clear commands and default signals. By sending and switching signals a preset number of times, this ensures reliable command transmission while avoiding excessive bus load caused by continuous signal occupancy. The periodic broadcasting of the default signal further prevents the secondary controller from mistakenly interpreting historical clear commands as valid, thus avoiding duplicate clearing or logic confusion caused by residual signals.

[0018] Optionally, the method further includes:

[0019] After the secondary controller receives the OBD fault code clearing instruction for the first time, it triggers the second fault code clearing mechanism to clear its own OBD fault code, and triggers the preset repeated clearing instruction non-response mechanism, so that within the second preset time window after the first receipt of the OBD fault code clearing instruction, after receiving the OBD fault code clearing instruction again, the second fault code clearing mechanism will not be triggered.

[0020] This embodiment effectively prevents multiple false triggering due to signal retransmission or bus interference by limiting the secondary controller to trigger fault clearing only upon the first receipt of a clear command and blocking repeated commands within a preset time window. This mechanism ensures that the secondary controller performs only one valid clearing action, avoiding resource waste and logic conflicts caused by repeated operations, and synergizes with the dynamic diagnostic management of the primary controller.

[0021] Optionally, the method further includes:

[0022] After the OBD fault code of the secondary controller is cleared, the secondary controller periodically sends a preset number of clearing completion signals to the primary controller via the CAN bus in a pulse sequence using an event-type signal;

[0023] After the clearing completion signal is sent, a default signal is periodically sent to the primary controller a preset number of times in a pulse sequence via the CAN bus.

[0024] In this embodiment, the secondary controller uses an event-based signal to indicate the purge completion status. By sending a preset number of signals and switching between them and the default signal, the primary controller can accurately identify the purge completion event while avoiding the load caused by the signal continuously occupying the bus. This design balances the timeliness and reliability of the feedback signal, preventing the primary controller from misjudging the purge completion or receiving repeated feedback signals.

[0025] Optionally, the method further includes:

[0026] After receiving the clearing completion signal from any secondary controller, the primary controller maintains the corresponding clearing completion signal in a response state of a third preset time window; wherein the end time of the third preset time window is later than the end time of the first preset time window.

[0027] In this embodiment, the secondary controller uses an event-based signal to indicate the purge completion status. By sending a preset number of signals and switching between them and the default signal, the primary controller can accurately identify the purge completion event while avoiding the load caused by the signal continuously occupying the bus. This design balances the timeliness and reliability of the feedback signal, preventing the primary controller from misjudging the purge completion or receiving repeated feedback signals.

[0028] Optionally, after enabling the diagnosis of the corresponding secondary controller, the method further includes:

[0029] After the first preset time window ends, determining the feedback status of the plurality of secondary controllers according to whether a clearing completion signal for maintaining the response state exists;

[0030] If there is a clearing completion signal that maintains the response state, the corresponding secondary controller is a normal response secondary controller;

[0031] If there is no clearing completion signal maintaining the response state, the corresponding secondary controller is an abnormal secondary controller.

[0032] In this embodiment, after the first preset time window expires, the feedback results of the secondary controllers are determined based on whether they remain responsive. This allows the primary controller to distinguish between normally responsive and abnormally unresponsive secondary controllers. This logic combines dynamic feedback with time window constraints to ensure the accuracy of the clearing results. This is particularly useful in scenarios where some secondary controllers fail to provide timely feedback due to communication failures, preventing the overall clearing results from being incorrectly overwritten by abnormal nodes.

[0033] Optionally, the method further includes:

[0034] After the first preset time window ends, the primary controller turns on the diagnosis enable of the abnormal secondary controller and sends a clear result response to the diagnostic instrument based on the feedback status of the multiple secondary controllers.

[0035] In this embodiment, for abnormal secondary controllers that haven't responded with a clearing completion signal, their diagnostics are forcibly enabled after the first preset time window expires, ensuring that the system resumes monitoring of all secondary controllers after the fault clearing process is complete. This mechanism ensures clearing synchronization while avoiding the risk of long-term diagnostic shutdown due to communication anomalies, ensuring subsequent fault detectability for abnormal secondary controllers.

[0036] An electronic device, comprising:

[0037] at least one processor;

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

[0039] 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 above-mentioned methods for clearing fault codes of an OBD system.

[0040] A vehicle, comprising:

[0041] a memory for storing executable program code;

[0042] A processor is used to call and run the executable program code from the memory, so that the vehicle executes any one of the above-mentioned methods for clearing fault codes of an OBD system.

[0043] 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

[0044] 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:

[0045] Figure 1 A communication relationship diagram of an OBD system provided in an embodiment of the present application;

[0046] Figure 2 A flow chart of a method for clearing fault codes of an OBD system provided in an embodiment of the present application;

[0047] Figure 3 A schematic diagram of a fault code clearing process of an OBD system provided in an embodiment of the present application;

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

[0049] 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.

[0050] With the stringent requirements of the China VI emission regulations on fault diagnosis of the OBD system of hybrid electric vehicles, the coordinated management of fault codes of multi-level controllers in the vehicle control system has become a key technical challenge to ensure emission compliance. In existing technologies, the OBD system usually communicates directly with the diagnostic instrument through the first-level controller, while the second-level controller cannot be directly connected to the diagnostic instrument due to protocol restrictions or hardware resource constraints, resulting in serious synchronization and feedback loss problems in the fault clearing process. The traditional solution relies on the first-level controller to independently execute the fault clearing command, but due to the lack of a handshake mechanism with the second-level controller, it causes the following core contradictions:

[0051] 1. Fragmentation of fault clearing status: The inventors discovered that the current primary controller, after receiving the diagnostic instrument clearing command, only performs its own fault code clearing and assumes that the secondary controller has completed the synchronization operation. However, the secondary controller may lag behind the primary controller due to communication delays or processing time, causing the primary controller to restore the diagnostic function in advance without confirming the actual status of the secondary controller, thereby erroneously reporting the cleared fault code. For example, in a low-temperature startup scenario, the fault clearing operation of the secondary controller may be prolonged due to the low-temperature self-test process, and the primary controller, not sensing the delay, mistakenly determines that the secondary controller fault has not been cleared, triggering an error alarm.

[0052] 2. Unreliable signal interaction mechanism: Traditional solutions use continuous signal transmission to clear instructions, which increases the load rate of the CAN bus and cannot avoid the risk of repeated operations caused by residual signals. For example, when the primary controller broadcasts a clear instruction through a regular message, if the secondary controller fails to receive the signal in time due to bus competition, the clear action may be repeatedly triggered, resulting in wasted controller resources or logical conflicts. In addition, if the feedback signal after the secondary controller completes the clearing is not designed to prevent residual signals, the primary controller may mistakenly regard the historical feedback signal as a valid response, resulting in an incorrect switching of the diagnostic enable state.

[0053] 3. Rigid dynamic diagnostic management: Existing technologies rely on fixed time windows to control the enabling of secondary controller diagnostics and are unable to dynamically adjust based on the actual progress of the purge. For example, if a secondary controller completes the purge ahead of schedule within the preset time window, but other controllers are still processing, the system cannot differentially restore the diagnostic function of the completed controllers, causing some controllers to be prematurely exposed to the risk of false detection. Furthermore, for abnormal controllers that do not report the completion of the purge, the existing solution lacks a forced recovery mechanism. This may cause the diagnostic function to be shut down for a long time due to communication interruptions, affecting the integrity of emission monitoring.

[0054] To solve the above problems, the present application provides a method for clearing fault codes of an OBD system, which is applied to the OBD system. The OBD system includes a diagnostic instrument, a primary controller, and several secondary controllers, wherein the communication relationship is as follows: Figure 1 As shown, Figure 1 A communication relationship diagram of an OBD system provided in an embodiment of the present application.

[0055] This application provides a method for clearing fault codes of an OBD system, such as Figure 2 As shown, Figure 2 The present invention provides a flow chart of a method for clearing fault codes of an OBD system, which specifically includes the following steps:

[0056] Step 201: After receiving the OBD fault code clearing instruction sent by the diagnostic instrument, the primary controller broadcasts the OBD fault code clearing instruction and disables the diagnostic enable of several secondary controllers.

[0057] In this embodiment, when the primary controller receives the OBD fault code clearing instruction sent by the diagnostic instrument through the CAN bus, the instruction forwarding logic is immediately triggered to broadcast the OBD fault code clearing instruction.

[0058] In one embodiment of the present application, broadcasting an OBD fault code clearing instruction specifically includes: utilizing an event-type signal, the primary controller periodically broadcasts the OBD fault code clearing instruction a preset number of times in a pulse sequence via the CAN bus; after completing the broadcasting of the OBD fault code clearing instruction, periodically broadcasting a default signal a preset number of times in a pulse sequence via the CAN bus.

[0059] It is understood that the term "broadcast" refers to the primary controller sending a clear command to all secondary controllers synchronously via the CAN bus in the form of an event-based signal. In this embodiment, the "event-based signal" specifically refers to the pulse sequence used to broadcast the OBD fault code clear command. This signal does not refer to any event-triggered signal, but rather refers specifically to the clear command signal generated by the primary controller after receiving the diagnostic instrument's command, consisting of a specific pulse sequence. In this embodiment, its core purpose is to transmit the clear command using a preset pulse pattern while reducing bus load and preventing signal residue.

[0060] In a possible implementation of the present application, the event-type signal is composed of two pulse sequences: a clear instruction pulse segment and a default signal coverage segment. Exemplarily, the clear instruction pulse segment is composed of 6 consecutive signals with a value of 1, and each signal lasts for 50 milliseconds. Default signal coverage segment: After the clear instruction is sent, a signal with a value of 0 is sent immediately for 6 consecutive times, and each lasts for 50 milliseconds. It can be understood that the "event-type signal" in this example is essentially a physical layer expression of the clear instruction, rather than an abstract event response logic. Its design includes the following technical features: 1. The signal is only used to transmit the OBD fault code clear instruction and does not involve other functions; 2. The number of pulses (6 times), duration (50ms) and value switching order (1→0) are preset rules and have nothing to do with specific working conditions; 3. The sending of the value 0 signal is used to cover the historical state of the value 1 to avoid the secondary controller from mistakenly using residual signals to repeatedly trigger the clearing action.

[0061] For example, when the primary controller receives a command from the diagnostic instrument, it immediately generates an event-type signal: a value of 1 is sent for the first 300 milliseconds (6×50ms) to indicate that the clear command has taken effect; a value of 0 is sent for the next 300 milliseconds (6×50ms) to clearly indicate the end of the command cycle. For example, in a scenario with high bus load, if a value of 1 signal is lost due to a conflict, subsequent repeated signals can still ensure that the secondary controller receives the command; and the value of 0 signal overrides the secondary controller to prevent it from mistakenly believing that there are still pending commands after the command cycle ends.

[0062] It's understandable that the parameter design for event-type signals (6 times x 50ms) takes into account redundancy and load balancing: Six repeated transmissions improve reliability while keeping the total duration (600ms) within a reasonable range to avoid long-term bus occupancy. Furthermore, timing compatibility is considered: the 50ms single-shot duration matches the CAN bus frame transmission period, ensuring complete signal parsing.

[0063] Furthermore, the primary controller immediately disables the diagnostic enable function of all secondary controllers while broadcasting the event signal. It should be noted that "disabling diagnostic enable" means that the primary controller suspends the fault detection and reporting logic of the secondary controllers.

[0064] In one possible implementation of this application, disabling diagnostic enable may include two steps: setting a status flag and isolating fault code reporting. Setting the status flag switches the internally stored secondary controller diagnostic enable flag from "enabled" to "disabled." Isolating fault code reporting: In the disabled state, the primary controller no longer receives fault status data from the secondary controller and does not incorporate it into the global fault code reporting logic.

[0065] For example, when a secondary controller (such as an emission-related nitrogen oxide sensor controller) needs to restart the communication module due to a clearing operation, if the diagnostic enable is not turned off, the primary controller may mistakenly judge that it is offline due to communication interruption and report a fault code; after turning off the diagnostic enable, such false alarms are completely avoided. It can be understood that the turning off of the diagnostic enable and the broadcasting of the event-type signal are atomic operations. The synchronous execution of the two ensures that the secondary controller is in an isolated state during the clearing process, providing it with an interference-free operating environment. For example, in a low-temperature cold start scenario, a secondary controller (such as a fuel injection controller) takes 5 seconds to complete the clearing operation due to the low-temperature self-test process: if the diagnostic enable is not turned off, the primary controller may detect that its initialization timed out before the self-test is completed, and mistakenly report a "controller not responding" fault code; by turning off the diagnostic enable, the primary controller blocks the monitoring of the controller during the self-test, and after the clearing is completed and the diagnostic function is restored through the feedback mechanism, it is re-incorporated into the global fault detection logic. This design eliminates the risk of false alarms caused by clearing delays from the root.

[0066] It's important to note that the transmission of event-type signals and the disabling of diagnostic enable work together to create a hierarchical purge execution environment. On the one hand, event-type signals ensure reliable command transmission and state reset; on the other hand, disabling diagnostic enable provides a stable operating window for the secondary controller. This combination enables the primary controller to precisely coordinate the purge process across multiple controllers while maintaining a balance between bus load and system real-time performance. For example, when a sudden vehicle acceleration causes a surge in bus load, the short pulse characteristics of the event-type signal reduce contention for bus resources, while disabling diagnostic enable prevents logic conflicts caused by cross-interference between purge operations and powertrain control commands.

[0067] In one embodiment of the present application, after the primary controller receives the OBD fault code clearing instruction sent by the diagnostic instrument, the method further includes: triggering a first fault code clearing mechanism to clear the OBD fault code of the primary controller.

[0068] In this embodiment, the "first fault code clearing mechanism" is a self-performed fault reset operation executed by the primary controller upon receiving a diagnostic tool command, independent of the secondary controller's management process. Once the primary controller interprets and confirms the validity of the diagnostic tool's clearing command, it immediately triggers this mechanism to ensure that the internally stored fault codes and associated status flags are completely cleared, providing a stable execution environment for subsequent levels of coordinated clearing.

[0069] Specifically, the execution logic of the first fault code clearing mechanism covers three core actions: first, deleting all historical OBD fault codes recorded in the non-volatile memory; second, resetting the dynamic operating status flags associated with the fault codes (such as communication anomalies, sensor failures, etc.); third, releasing the resources occupied by the system protection strategy triggered by the fault (such as communication bandwidth limitations, power output degradation). It can be understood that the essence of this mechanism is to return the primary controller to a "fault-free" baseline state to avoid residual fault codes interfering with its command distribution or status monitoring to the secondary controller. For example, if the primary controller has a historical fault code of "CAN bus load is too high" and it is not cleared, it may continue to limit the bus communication frequency, resulting in incomplete broadcast of subsequent event-type signals, thereby affecting the clearing operation of the secondary controller.

[0070] For example, in a hybrid electric vehicle's VCU (vehicle control unit) scenario, if the primary controller is in motor torque limit mode (e.g., limiting output to 50% of the rated value) due to a historical fault code, triggering the first fault code clearing mechanism will release the torque limit and restore the motor control logic to full power. This action not only ensures sufficient communication resources for event-type signal broadcasting, but also avoids vehicle power response lag caused by the limited performance of the primary controller itself, thereby providing a stable energy supply and communication environment for the clearing operation of the secondary controller (e.g., battery management system, motor controller).

[0071] It should be noted that the triggering and execution of the first fault code clearing mechanism has a strict time priority. It must be completed before the event-type signal broadcast and the diagnostic enable shutdown operation to ensure that the primary controller is in a "clean" state to coordinate subsequent processes. For example, if the primary controller broadcasts the event-type signal first and then performs self-clearing, it may cause broadcast interruption or signal distortion due to residual fault codes, thereby causing malfunction of the secondary controller. In addition, the atomic design of this mechanism ensures that its execution process cannot be interrupted. Even if a new fault is detected during the clearing process (such as a memory write failure), the primary controller will record the new fault code and terminate subsequent operations to prevent the system from entering an uncontrollable state.

[0072] Understandably, there are fundamental differences between the self-clearing mechanism of the primary controller and the clearing logic of the secondary controller. The former is an autonomous, instantaneous reset of the internal state, while the latter relies on cross-controller command interaction and feedback synchronization. For example, fault code clearing in the primary controller is typically completed within milliseconds, while in the secondary controller, it may take several seconds due to hardware self-test or software initialization. This differentiated design allows the primary controller to quickly release critical resources, reserving a time window for the secondary controller's lengthy operations.

[0073] For example, in a low-temperature cold start scenario, if a fault code indicating "low-temperature preheating incomplete" is present in a primary controller (such as the powertrain controller), the first fault code clearing mechanism is triggered, deleting the fault code and simultaneously removing the associated preheating restriction strategy (such as prohibiting high-torque output from the motor). This allows the primary controller to immediately respond to the driver's acceleration request without having to wait for the secondary controller (such as the battery heating module) to complete fault clearing, thereby improving user experience and system response efficiency.

[0074] Step 202 : Within a first preset time window after disabling the diagnostic enable of a plurality of secondary controllers, if the primary controller receives a clearing completion signal from any secondary controller, the primary controller enables the diagnostic enable of the corresponding secondary controller.

[0075] In this embodiment, after disabling the diagnostic enable of the secondary controller, the primary controller starts a first preset time window (e.g., 5 seconds) and continuously monitors the clearing completion signal fed back by the secondary controller within this window. The "clearing completion signal" is an event-type signal sent by the secondary controller via the CAN bus after the secondary controller completes clearing its own fault codes.

[0076] Specifically, when a secondary controller completes the fault code clearing operation, it immediately triggers the generation and sending of a clearing completion signal. For example, after a motor controller (secondary controller) clears the overtemperature fault code of the inverter module, it feeds back the completion status to the primary controller through the generated clearing completion signal. If the primary controller detects the clearing completion signal within the time window, it determines that the controller has successfully cleared the fault code and immediately turns on its diagnostic enable function. It can be understood that the "turning on diagnostic enable" means that the primary controller switches the internal status flag of the corresponding secondary controller from "disabled" to "enabled", and restores the real-time monitoring and reporting logic of its fault status.

[0077] In one embodiment of the present application, after the secondary controller receives the OBD fault code clearing instruction for the first time, it triggers the second fault code clearing mechanism to clear its own OBD fault code, and triggers the preset repeated clearing instruction non-response mechanism, so that within the second preset time window after the first receipt of the OBD fault code clearing instruction, after receiving the OBD fault code clearing instruction again, the second fault code clearing mechanism is not triggered.

[0078] In this embodiment, the response logic of the secondary controller to the clear instruction is implemented through the collaborative design of event-driven and time window constraints. When the secondary controller first parses the event-type clear instruction (any pulse signal with a value of 1) broadcast by the primary controller through the CAN bus, it immediately triggers the second fault code clearing mechanism and performs the clearing operation of its own fault code. The clearing operation includes deleting all OBD fault codes recorded in the non-volatile memory, resetting the associated status flags (such as communication anomalies, sensor over-limit, etc.), and releasing the degradation mode triggered by the fault (such as limiting output power or shutting down non-critical functions). It can be understood that the essence of this mechanism is to return the secondary controller to a fault-free baseline state, providing a prerequisite for the subsequent recovery of the diagnostic enable.

[0079] Specifically, after completing the fault code clearing, the secondary controller immediately starts a second preset time window (for example, 5 seconds) and activates the repeated clear instruction shielding function within this window. The shielding function is implemented through an internal state machine: when the controller switches from the "standby" state to the "clearing completed" state, its instruction parsing module will automatically ignore all newly received clear instruction signals, regardless of whether these instructions are retransmissions from the primary controller or bus noise interference. For example, in a scenario where bus communication is momentarily interrupted, if the primary controller resends the clear instruction because it does not receive feedback, the secondary controller will directly discard the repeated instruction within the second time window to avoid resource competition or logic conflicts caused by repeated execution of the clear operation.

[0080] It should be noted that the second preset time window must cover the entire cycle of the secondary controller from clearing completion to state stabilization. For example, for controllers involving hardware initialization (such as a motor controller that needs to restart the inverter module), the second time window may be extended to 5 seconds to ensure that its self-test process is completely completed; while for controllers that only require a software reset (such as a lighting controller), the window duration can be shortened to 1 second. This differentiated design ensures reliability while avoiding system response delays caused by excessive waiting.

[0081] For example, when a battery management system (secondary controller) receives a clear command for the first time, it first clears the battery overvoltage fault code and resets the balancing module, then initiates a second time window of 5 seconds. During this time, if the primary controller resends the clear command due to communication delays, it will simply ignore subsequent commands and maintain the "clear complete" status until the end of the window. This design prevents repeated clear operations from interfering with the battery balancing process and preventing cell parameter calibration failures.

[0082] It can be understood that the repeated instruction shielding mechanism forms a closed-loop collaboration with the event-type signal broadcast of the first-level controller. The first-level controller ensures the reliable transmission of instructions through redundant pulse sequences (6 times value 1 + 6 times value 0), while the second-level controller avoids repeated responses through time window constraints. The cooperation between the two solves the problem of multiple clearing caused by bus retransmission or environmental interference from the root. For example, in a scenario with strong electromagnetic interference, if the clearing instruction is misinterpreted multiple times by the second-level controller due to signal distortion, the shielding mechanism can ensure that it only performs an effective clearing action once, thereby maintaining the consistency of the system state.

[0083] In one embodiment of the present application, after the OBD fault code of the secondary controller is cleared, the secondary controller uses an event-type signal to periodically send a preset number of clearing completion signals to the primary controller via the CAN bus in a pulse sequence; after the clearing completion signal is sent, the default signal is periodically sent to the primary controller via the CAN bus in a pulse sequence a preset number of times.

[0084] In this embodiment, the clear completion signal is an event-based feedback signal generated by the secondary controller after clearing its own fault codes. Essentially, it uses a preset pulse sequence to notify the primary controller that the clear operation has been successfully executed. This signal is generated only upon the specific event of clear completion, rather than being sent periodically or continuously, thereby avoiding unnecessary use of bus resources.

[0085] Specifically, the sending of the clear completion signal is divided into two stages: the clear completion pulse segment: the secondary controller sends 6 consecutive pulse signals with a value of 1 through the CAN bus, and the duration of each pulse is 50 milliseconds; the default signal coverage segment: after the clear completion pulse is sent, 6 consecutive pulse signals with a value of 0 are immediately sent, and the duration of each pulse is also 50 milliseconds.

[0086] It is understandable that the repeated transmission of the value 1 pulse (6 times) is intended to improve the reliability of signal transmission. For example, in a scenario with high bus load, if a value 1 pulse is lost due to signal conflict, subsequent pulses can still be successfully received by the primary controller, thereby avoiding feedback omissions due to single transmission failures. The transmission of the value 0 pulse is used to clearly mark the end of the clear completion event, preventing the primary controller from mistakenly treating the historical value 1 signal as a new feedback event. For example, if the secondary controller only sends a value 1 pulse but not a value 0 pulse, the primary controller may misjudge the presence of a continuous high-level signal due to bus noise or capacitance effects, resulting in repeated responses or logic disorders.

[0087] For example, when a battery management system (secondary controller) completes fault code clearing, it immediately generates an event signal: a pulse of value 1 is sent in the first 300 milliseconds (6×50ms), indicating that the clearing operation is successful; a pulse of value 0 is sent in the next 300 milliseconds (6×50ms), covering the residual state of value 1.

[0088] During this process, even if the first-level controller fails to interpret the first two value 1 pulses due to transient interference, the remaining four value 1 pulses can still trigger an effective response; and the sending of the value 0 pulse ensures that the first-level controller stops listening after the signal cycle ends, avoiding mistaking subsequent bus noise for secondary feedback.

[0089] It's important to note that the timing parameters of the event-type signal (6 times x 50ms) and its total duration (600ms) ensure reliability while avoiding long-term bus resource occupation. For example, in a hybrid electric vehicle motor control scenario, if the clear completion signal from a secondary controller (such as the inverter controller) occupies the bus for too long, it may block the transmission of critical control commands (such as torque requests). The limited 600ms window balances feedback needs with system real-time performance.

[0090] It's understandable that the purge completion signal and the purge command signal broadcast by the primary controller form a closed-loop handshake mechanism. The signal structure (six pulses of value 1 + six pulses of value 0) and timing rules for both signals are identical, allowing the primary controller to use the same parsing logic to process commands and feedback, reducing system complexity. For example, when monitoring feedback, the primary controller only needs to detect six consecutive pulses of value 1 to determine that the purge is complete, eliminating the need for a dedicated decoding algorithm, thereby improving processing efficiency.

[0091] For example, when an emissions controller (secondary controller) completes a purge after three seconds due to oxygen sensor calibration, the purge completion signal it generates will be interpreted by the primary controller as a valid event. If the controller repeatedly sends purge completion signals due to a software error, the zero-value pulse override design ensures that the primary controller only responds to the first valid signal. Subsequent signals are automatically ignored due to the zero-value reset, thus avoiding resource conflicts caused by repeated activation of diagnostic enable.

[0092] In one embodiment of the present application, after receiving the clearing completion signal from any secondary controller, the primary controller maintains the corresponding clearing completion signal in a response state of a third preset time window; wherein the end time of the third preset time window is later than the end time of the first preset time window.

[0093] In this embodiment, the "response state maintenance" mechanism is a redundant fault-tolerant strategy designed by the primary controller to ensure the integrity of the clearing completion signal. When the primary controller parses the clearing completion signal sent by the secondary controller through the CAN bus, it immediately marks the secondary controller identifier corresponding to the signal as "responded" and maintains this state within a third preset time window (for example, 6 seconds). It is understandable that the setting of the third time window needs to be later than the end time of the first time window, so as to provide a buffer period for signal transmission delays or transient interference, ensuring that the primary controller can cover all potential valid feedback when making the final decision.

[0094] Specifically, the response status is maintained through the internal state mapping table of the primary controller. The table records the unique identifiers of all secondary controllers and their current feedback status ("responded" or "unresponded"). When the clearing completion signal of a secondary controller is resolved, the status corresponding to its identifier is updated to "responded" and an independent countdown timer (third time window) is started. For example, in a bus communication delay scenario, if a secondary controller sends a signal 1 second before the end of the first preset time window, but the primary controller is delayed by 0.5 seconds due to congestion in the processing queue before resolving the signal, the setting of the third time window (such as extending by 1 second than the first time window) can ensure that the signal is still considered valid at the time of the final judgment.

[0095] For example, if a motor controller (secondary controller) sends a clear completion signal 0.5 seconds before the end of the first time window, the primary controller may delay interpreting the signal by 0.3 seconds due to real-time processing of other high-priority instructions (such as a brake signal). The third time window's hold mechanism ensures that the signal remains valid within the window, avoiding misjudgments caused by processing delays.

[0096] It's important to note that the length of the third time window must be designed based on the maximum expected system latency. For example, if the maximum command processing latency of the primary controller is 2 seconds, the third time window must cover at least 2 seconds of signal analysis after the end of the first time window. This design allows the primary controller to generate a clearing response based on more comprehensive feedback data when making its final decision, thereby improving the accuracy of its decision.

[0097] It's understandable that the response state maintenance mechanism complements the monitoring logic of the first time window. The first time window is used to limit the operation time of the secondary controller, while the third time window provides additional fault tolerance for signal parsing and state synchronization. For example, in high-temperature environments, the CAN bus may experience slight timing drift due to changes in signal propagation rate. The redundant design of the third time window can absorb such drift, preventing the system from misjudging controller status due to hardware differences.

[0098] For example, if a battery management system (secondary controller) sends a purge completion signal before the end of the first time window, but the primary controller is unable to immediately interpret it due to excessive bus load, the third time window retention mechanism allows the signal to be re-detected and marked as valid within the window. Without this mechanism, the primary controller may erroneously report a purge failure due to delayed interpretation, triggering unnecessary diagnostic instrument intervention.

[0099] In one embodiment of the present application, after turning on the diagnostic enable of the corresponding secondary controller, the method also includes: after the first preset time window ends, determining the feedback status of the several secondary controllers based on whether there is a clearing completion signal to maintain the response state; if there is a clearing completion signal to maintain the response state, the corresponding secondary controller is a normally responding secondary controller; if there is no clearing completion signal to maintain the response state, the corresponding secondary controller is an abnormal secondary controller.

[0100] In this embodiment, the core is to achieve accurate judgment of the clearing feedback of the secondary controller through the redundant design of the time window and the state maintenance mechanism. When the first preset time window (for example, 5 seconds) ends, the primary controller traverses the state mapping table maintained internally to check whether the clearing completion signal of each secondary controller remains in the "response state". The "response state" means that the clearing completion signal sent by the secondary controller has been successfully parsed by the primary controller and has not been reset to the default state within the third time window. If the signal state of a controller continues to be valid during this window period, it is determined to be a normal response node; otherwise, it is marked as an abnormal node.

[0101] It should be noted that the determination of normal response and abnormal nodes directly affects the clearing results fed back by the primary controller to the diagnostic instrument. For normal response nodes, the primary controller assumes that it has completed fault clearing and restored diagnostic enablement; for abnormal nodes, it is inferred that its clearing operation is incomplete or the communication link is abnormal, and it is necessary to forcibly restore the diagnostic enablement and report the clearing failure in the subsequent process. For example, in a hybrid system, if the battery management system (normal node) and the motor controller (abnormal node) coexist, the primary controller will feedback a "partial success" status to the diagnostic instrument, prompting technicians to conduct targeted inspections on the abnormal nodes.

[0102] In one embodiment of the present application, after the first preset time window ends, the primary controller turns on the diagnosis enable of the abnormal secondary controller and sends a clear result response to the diagnostic instrument based on the feedback status of several secondary controllers.

[0103] In this embodiment, the core is to perform forced restoration of diagnostic enable on abnormal secondary controllers that have not fed back the clearing completion signal in time, so as to ensure the integrity and real-time performance of the system monitoring function. When the first preset time window ends, the primary controller performs a diagnostic enable start operation on all secondary controllers marked as "abnormal" based on the feedback status of the secondary controller. The "turning on diagnostic enable" means that the primary controller switches the internal status flag of the corresponding controller from "disabled" to "enabled", and restores the real-time detection and reporting function of its fault status. It can be understood that this operation is used to avoid the long-term shutdown of the diagnostic function due to communication abnormalities or clearing failures, thereby ensuring the OBD system's continuous monitoring capability of potential faults.

[0104] It should be noted that the design of the forced recovery mechanism takes into account both system robustness and fault tolerance. Even if a secondary controller fails to complete the clearing operation due to a hardware failure or software error, the primary controller will still enable its diagnostics to ensure that residual or newly triggered fault codes can be re-detected later, thus avoiding monitoring loopholes caused by diagnostic isolation. For example, in a scenario where the communication link is momentarily interrupted, if an emission controller (abnormal node) fails to feedback a clearing completion signal due to signal loss, after the diagnostics enable is forced to be restored, the primary controller can immediately detect any initialization faults that may exist after its restart and re-record the fault code.

[0105] For example, if a motor controller (abnormal node) fails to clear an overtemperature fault code due to an inverter module firmware error, the primary controller can re-detect the fault code and report it to the diagnostic tool after forcibly restoring its diagnostics, triggering a maintenance reminder. If this is not done, the controller's fault status may be ignored for a long time, resulting in degraded motor performance or safety hazards.

[0106] It is understandable that the forced recovery operation and the on-demand recovery of normal response nodes form a complementary logic. Normal nodes immediately resume diagnosis after the clearing process is completed, while abnormal nodes are uniformly restored after a timeout. The collaboration between the two ensures that all controllers are in a monitorable state after the clearing process is completed. For example, in a hybrid system, normal nodes (such as the battery management system) immediately participate in the energy scheduling of the entire vehicle after the clearing process is completed, while abnormal nodes (such as the motor controller) are re-included in fault monitoring after forced recovery, thereby maintaining a balance between system functionality and safety.

[0107] In a possible implementation of the present application, the above-described embodiment of the present application provides a method for clearing fault codes of an OBD system, and its overall process is as follows: Figure 3 As shown, Figure 3 A schematic diagram of a fault code clearing process for an OBD system provided in an embodiment of the present application.

[0108] 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 an electronic device, whose structure is as follows Figure 4 shown.

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

[0110] at least one processor 401;

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

[0112] The memory 402 stores instructions that can be executed by at least one processor. The instructions are executed by the at least one processor 401 to enable the at least one processor 401 to:

[0113] After receiving the OBD fault code clearing instruction sent by the diagnostic instrument, the primary controller broadcasts the OBD fault code clearing instruction and turns off the diagnostic enable of the plurality of secondary controllers;

[0114] Within the first preset time window after turning off the diagnostic enable of the several secondary controllers, if the first-level controller receives a clearing completion signal from any secondary controller, it will immediately turn on the diagnostic enable of the corresponding secondary controller, and after the first preset time window ends, it will send a clearing result response to the diagnostic instrument based on the feedback status of the several secondary controllers.

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

[0116] a memory for storing executable program code;

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

[0118] After receiving the OBD fault code clearing instruction sent by the diagnostic instrument, the primary controller broadcasts the OBD fault code clearing instruction and turns off the diagnostic enable of the plurality of secondary controllers;

[0119] Within the first preset time window after turning off the diagnostic enable of the several secondary controllers, if the first-level controller receives a clearing completion signal from any secondary controller, it will immediately turn on the diagnostic enable of the corresponding secondary controller, and after the first preset time window ends, it will send a clearing result response to the diagnostic instrument based on the feedback status of the several secondary controllers.

[0120] 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:

[0121] After receiving the OBD fault code clearing instruction sent by the diagnostic instrument, the primary controller broadcasts the OBD fault code clearing instruction and turns off the diagnostic enable of the plurality of secondary controllers;

[0122] Within the first preset time window after turning off the diagnostic enable of the several secondary controllers, if the first-level controller receives a clearing completion signal from any secondary controller, it will immediately turn on the diagnostic enable of the corresponding secondary controller, and after the first preset time window ends, it will send a clearing result response to the diagnostic instrument based on the feedback status of the several secondary controllers.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational 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.

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

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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 method for clearing fault codes of an OBD system, characterized in that: Applied to an OBD system, the OBD system includes a diagnostic instrument, a primary controller, and several secondary controllers. The method includes: The primary controller receives the OBD fault code clearing instruction sent by the diagnostic instrument, broadcasts the OBD fault code clearing instruction, and turns off the diagnostic enable of the plurality of secondary controllers; Within a first preset time window after the diagnosis enable of the plurality of secondary controllers is turned off, if the primary controller receives a clearing completion signal from any secondary controller, the diagnosis enable of the corresponding secondary controller is turned on.

2. The method for clearing fault codes of an OBD system according to claim 1, characterized in that: After the primary controller receives the OBD fault code clearing instruction sent by the diagnostic instrument, the method further includes: The first fault code clearing mechanism is triggered to clear the OBD fault code of the primary controller.

3. The method for clearing fault codes of an OBD system according to claim 1, characterized in that: Broadcasting the OBD fault code clearing instruction specifically includes: The primary controller periodically broadcasts the OBD fault code clearing instruction a preset number of times in a pulse sequence via the CAN bus using an event-type signal; After completing the broadcast of the OBD fault code clearing instruction, the default signal is periodically broadcast a preset number of times in a pulse sequence via the CAN bus.

4. The method for clearing fault codes of an OBD system according to claim 3, characterized in that: The method further comprises: After the secondary controller receives the OBD fault code clearing instruction for the first time, it triggers the second fault code clearing mechanism to clear its own OBD fault code, and triggers the preset repeated clearing instruction non-response mechanism, so that within the second preset time window after the first receipt of the OBD fault code clearing instruction, after receiving the OBD fault code clearing instruction again, the second fault code clearing mechanism will not be triggered.

5. The method for clearing fault codes of an OBD system according to claim 4, characterized in that: The method further comprises: After the OBD fault code of the secondary controller is cleared, the secondary controller periodically sends a preset number of clearing completion signals to the primary controller via the CAN bus in a pulse sequence using an event-type signal; After the clearing completion signal is sent, a default signal is periodically sent to the primary controller a preset number of times in a pulse sequence via the CAN bus.

6. The method for clearing fault codes of an OBD system according to claim 1, characterized in that: The method further comprises: After receiving the clearing completion signal from any secondary controller, the primary controller maintains the corresponding clearing completion signal in a response state of a third preset time window; wherein the end time of the third preset time window is later than the end time of the first preset time window.

7. The method for clearing fault codes of an OBD system according to claim 6, characterized in that: After enabling the diagnosis of the corresponding secondary controller, the method further includes: After the first preset time window ends, determining the feedback status of the plurality of secondary controllers according to whether a clearing completion signal for maintaining the response state exists; If there is a clearing completion signal that maintains the response state, the corresponding secondary controller is a normal response secondary controller; If there is no clearing completion signal maintaining the response state, the corresponding secondary controller is an abnormal secondary controller.

8. The method for clearing fault codes of an OBD system according to claim 7, characterized in that: The method further comprises: After the first preset time window ends, the primary controller turns on the diagnosis enable of the abnormal secondary controller and sends a clear result response to the diagnostic instrument based on the feedback status of the multiple secondary controllers.

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