Wake-up source fault detection method, controller and vehicle

Abstract

In order to solve the problem that a controller cannot sleep or is frequently awakened when an awakening source is abnormal, the invention provides an awakening source fault detection method, a controller and a vehicle. The method comprises the following steps: continuously sampling a switching value wake-up source signal during the period that a whole vehicle is powered off and a power supply gear is turned off, so as to obtain the single turn-on time and effective jump count of a switching value device; and determining whether the switching value wake-up source has a fault according to the single turn-on time and the effective jump count.

Description

Technical Field

[0001] This application relates to the field of vehicle fault diagnosis technology, specifically to a method for detecting wake-up source faults, a controller, and a vehicle. Background Technology

[0002] For controllers that support network management, when a wake-up source that needs to be enabled to wake up the vehicle network is detected, a network wake-up request will be sent, and multiple controllers will be in a wake-up state. When the wake-up source malfunctions, such as being continuously enabled and unable to be turned off or being enabled intermittently, the vehicle network will be unable to enter sleep mode or will wake up repeatedly, resulting in excessive static current in the vehicle, leading to energy loss in the low-voltage battery and increasing the risk of vehicle power failure. For devices whose wake-up source signals are switching quantities, such as switches and position sensors, jamming or loose connection faults often occur. The signal may appear as continuously valid or intermittently valid to invalid transitions. If the controller does not diagnose such signals and judges them as valid wake-up sources, the vehicle network will be awakened for a long time, leading to vehicle power failure, and it will also be difficult to determine the root cause of the vehicle network not entering sleep mode or abnormally waking up. Summary of the Invention

[0003] To address the issue of controllers failing to sleep or frequently waking up when the wake-up source is faulty, this application provides a method for detecting wake-up source faults, a controller, and a vehicle.

[0004] The technical solution of this invention is as follows: This application provides a method for detecting wake-up source failure, applied to a controller with a switching device and capable of waking up a network. The detection method includes: During the period when the vehicle is powered off and the power is turned off, the switch wake-up source signal is continuously sampled to obtain the single turn-on time and effective transition count of the switch device. Based on the single connection time and the effective transition count, determine whether the switch wake-up source is faulty.

[0005] Preferably, the method further includes: When the switch wake-up source fails and the vehicle network has already been woken up, first send the fault information that caused the vehicle network to be abnormally woken up to the cloud, and then trigger the vehicle network to hibernate. If the switch wake-up source fails and the vehicle network is not woken up, the vehicle network will not be woken up again, and the controller will re-enter sleep mode.

[0006] Preferably, the step of determining whether the switch wake-up source is faulty based on the connection time and the transition count includes: If the single-time turn-on time of the switch wake-up source signal is greater than or equal to the first preset duration, it is determined that the switch wake-up source has a jamming fault; the first preset duration is a threshold defined based on the maximum execution time of the switch device. If the effective number of transitions of the switch wake-up source signal is greater than the preset number of transitions, it is determined that the switch wake-up source has a signal abnormal transition fault; the preset number of transitions is the maximum number of wake-up times calculated based on the voltage of the low-voltage battery dropping to a set threshold value after the vehicle is powered off.

[0007] Preferably, the counting method for the effective transition count includes: Set a detection period window and a jump frequency threshold; When the single connection time is detected to be greater than or equal to the second preset duration, the counting of the number of transitions of the switch wake-up source signal is initiated; The total number of times the switch wake-up source signal changes from invalid to valid within the detection period window is counted. The jump frequency is calculated based on the total number of jumps and the duration of the detection period window; The switching frequency is compared with the switching frequency threshold, and the valid switching counts in the switching counter are differentially accumulated based on the comparison result.

[0008] Preferably, the step of differentially accumulating the valid transition counts in the transition counter based on the comparison results includes: If the transition frequency is less than the transition frequency threshold, the valid transition counts in the transition counter are added to the total number of counts within the detection period window; If the transition frequency is greater than or equal to the transition frequency threshold, the effective transition count in the transition counter is incremented by 1.

[0009] Preferably, the counting method for the effective transition count includes: When it is determined that the switch wake-up source is stuck, the effective jump count in the jump counter is incremented by 1.

[0010] Preferably, fault information is reported through a predefined remote diagnostic message, which includes a fault code for identifying a specific fault and a fault status characterizing the current state of the fault. When a fault is diagnosed, the fault information is sent once using a confirmation of the fault status. When fault recovery is diagnosed, the fault information is sent once using the historical fault status. When there is no fault information to send, the remote diagnostic message is periodically sent with a payload filled with a specific value.

[0011] Preferably, the remote diagnostic message is 8 bytes long, with each 4 bytes forming a group of DTC information. The format consists of high, medium, and low bytes and a status byte. The status byte uses only bits 0 and 3: bit 0 = 1 and bit 3 = 1 indicates a confirmed fault, and bit 0 = 0 and bit 3 = 1 indicates a historical fault. When a fault occurs, the DTC byte group is set to 0x00 after sending a confirmed fault status. When a fault recovers, the entire frame is periodically filled with 0x00 after sending a historical fault status. When there is only one DTC, the remaining 4 bytes are filled with 0x00. When there is no fault, bytes 0-7 are all filled with 0x00.

[0012] This application also provides a controller, which has a switching device and is capable of waking up a network, the controller comprising: The switch wake-up source signal sampling module is used to continuously sample the switch wake-up source signal during the period when the vehicle is powered off and the power is turned off, so as to obtain the single turn-on time and effective transition count of the switch device. The switch wake-up source fault detection module is used to determine whether the switch wake-up source is faulty based on the single connection time and the effective transition count.

[0013] This application also provides a vehicle including the aforementioned controller.

[0014] The beneficial effects of this invention are as follows: To address the issue of repeated vehicle wake-ups caused by abnormal wake-up sources in the switching devices, fault diagnosis was performed on the switching wake-up sources. Abnormal wake-up sources were shielded during the controller's sleep or wake-up process, allowing the entire vehicle network to enter sleep mode normally and preventing the vehicle from failing to start due to low-voltage battery depletion. Simultaneously, by collecting fault information reported by each controller and uploading it to the cloud, maintenance personnel can remotely monitor vehicle power-related faults and accurately locate abnormal controllers, thus improving maintenance efficiency. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the wake-up source failure detection method in the embodiments of this application. Figure 1 ; Figure 2 This is a flowchart illustrating the wake-up source failure detection method in the embodiments of this application. Figure 2 ; Figure 3 This is a schematic diagram of the vehicle structure in an embodiment of this application. Detailed Implementation

[0016] To address the issue of intermittent failures of the switching device causing the controller to fail to sleep or frequently wake up the vehicle network, refer to Figure 1This application provides a method for detecting wake-up source failure, applied to a controller with a switching device and capable of waking up the network. The detection method includes: S101, during the period when the vehicle is powered off and the power is turned off, the switch wake-up source signal is continuously sampled to obtain the single turn-on time and effective transition count of the switch device. S102, determine whether the switch wake-up source is faulty based on the single connection time and the effective transition count.

[0017] After the vehicle is powered off, the controller enters a low-power sleep state. Its main MCU (microcontroller unit) and most of its peripherals are powered down, but the hardware circuitry dedicated to the wake-up function (such as the wake-up input pin and low-power auxiliary modules) remains powered on and monitored. This hardware circuitry is configured to detect level changes (typically rising edges) on specific wake-up source pins.

[0018] When a switching device (such as a height adjustment switch) is operated, and its signal transitions from low level (0) to high level (1), this transition acts as a hardware interrupt signal, directly triggering the controller's wake-up process. The controller's main MCU then powers on and resets, entering the working state from the sleep state.

[0019] Once the controller is woken up, its underlying software (such as BSW) or application layer tasks immediately identify the source of the wake-up (i.e., determine which digital wake-up source pin triggered it). Once the source is identified, the diagnostic tasks associated with this method are activated, and detailed sampling and analysis of the wake-up source signal begins.

[0020] After the controller is woken up, it begins continuous monitoring and timing of the wake-up signal. The rising edge of the signal that wakes up the controller is taken as the absolute starting point for this pulse timing. In the wake-up state, the controller continuously samples the wake-up signal at a preset sampling frequency (e.g., 1kHz). The purpose of sampling is twofold: first, to confirm whether the signal is continuously at a valid high level (in case of transient interference); and second, to accurately capture the falling edge of the signal. When the sampling detects a falling edge (a transition from 1 to 0), timing stops; the duration from the starting point to the ending point is recorded as the single-pulse on-time t.

[0021] The measured single-connection time t is compared with a pre-calibrated second preset duration (which is a de-shake threshold Tmin defined based on the possible high and low signal jitter when the switch is pressed, for example, 50ms).

[0022] If the single - turn - on time t < Tmin, it is considered that this wake - up is caused by switch contact jitter or noise interference, which belongs to an invalid wake - up. After simply recording the log, the controller will quickly re - enter the sleep state without any counting. If the single - turn - on time t ≥ Tmin, it is determined that this is a valid switch event; the controller will update the data required for jump - frequency analysis accordingly and intelligently update the valid jump count.

[0023] In the embodiment of the present application, the counting method of the valid jump count includes: Set a detection - period window (the time length of this detection - period window is fixed, for example, 5 s) and a jump - frequency threshold F_threshold (this jump - frequency threshold is a fixed frequency value, for example, 0.8 Hz); When it is monitored that the single - turn - on time is greater than or equal to the second preset duration, start counting the number of jumps of the switch - quantity wake - up source signal; only when the condition of the single - turn - on time t ≥ the second preset duration is met, it is considered that this is a "valid switch event" worthy of further analysis, and then start the counting process of the number of jumps. If the single - turn - on time t < the second preset duration, this wake - up is ignored.

[0024] Count the total number of times that the switch - quantity wake - up source signal changes from invalid to valid within the detection - period window; the controller maintains a first - in - first - out (FIFO) queue or a timestamp list in the memory for recording record The timestamps of all valid "invalid - to - valid" jump events that occurred within the most recent detection - period window (i.e., the just - passed T_window time, such as 5 seconds) For example, if the current time is 10:00:05, the system will count the time from 10:00:00 to 10:00:05. The jump that occurs within the time window of 00:05.

[0025] When each valid event that meets the conditions occurs, the algorithm will query this timestamp list and count the total number of jumps recorded within the most recent T_window duration to obtain the total number n. For example: within the past 5 seconds, 4 jumps are recorded in the timestamp list, then n = 4.

[0026] Calculate the jump frequency according to the total number and the duration of the detection - period window; According to the physical definition, frequency = number / time. Therefore, the calculation formula for the jump frequency f is: f = n / T_window. For example, in the above example: f = 4 / 5 = 0.8 Hz.

[0027] Compare the jump frequency with the jump - frequency threshold and differentially accumulate the valid jump count in the jump counter according to the comparison result.

[0028] The steps for differentially accumulating the valid transition counts in the transition counter based on the comparison results include: If the transition frequency is less than the transition frequency threshold, the valid transition counts in the transition counter are added to the total number of counts within the detection period window; If the transition frequency is greater than or equal to the transition frequency threshold, the effective transition count in the transition counter is incremented by 1.

[0029] If the switching frequency f ≥ the switching frequency threshold F_threshold, this indicates that the signal switching is too frequent within the detection window, far exceeding the calibrated normal operating frequency, and is judged as an abnormal switching (such as contact jitter). In this case, regardless of how many times it switches (the value of n), the signal switching counter Ni only increases by 1, i.e., Ni = Ni + 1. If f ≤ F: this indicates that the signal switching frequency is within the normal range and is judged as normal operation (such as the user intentionally pressing multiple times). In this case, the signal switching counter Ni increases by the total number of switching times n counted, i.e., Ni = Ni + n.

[0030] In this embodiment, the counting method for valid transitions includes incrementing the valid transition count in the transition counter by 1 when a stuck fault is determined to occur in the switch wake-up source. A stuck fault means that the switch may be stuck or become jammed, causing the signal to remain in the ON state. This is a failure mode that is completely different from high-frequency transitions, characterized by continuous on rather than jitter. By converting this persistent fault state of stuckness into a countable event, each transition from normal to stuck state is recorded as a fault event (Ni+1).

[0031] In this embodiment of the application, step S102, which determines whether the switch wake-up source is faulty based on the connection time and the transition count, includes: S1021, if the single-connection time of the switch wake-up source signal is greater than or equal to the first preset duration, it is determined that the switch wake-up source has a jamming fault; the first preset duration is a threshold defined based on the maximum execution time of the switch device. S1022, if the effective number of transitions of the switch wake-up source signal is greater than the preset number of transitions, it is determined that the switch wake-up source has a signal abnormal transition fault; the preset number of transitions is the maximum number of wake-up times calculated based on the voltage of the low-voltage battery dropping to a set threshold value after the vehicle is powered off.

[0032] The single-time activation t is compared with the first preset duration Tmax. The first preset duration Tmax is a threshold pre-calibrated based on the physical characteristics and functional logic of the switching device. If the single-time activation t ≥ the first preset duration Tmax, then a lag fault is determined in the switching wake-up source.

[0033] The first preset duration Tmax is determined by the maximum reasonable operating time of the switching device. For example, for a window switch, Tmax should be greater than the total time required for the window to go from fully open to fully closed; for a seat adjustment switch, Tmax should be greater than the total time required for the seat to move from the forward position to the rear position. Since no normal user operation can keep the switch continuously on for more than Tmax, once this time is exceeded, it can be determined that the switch mechanism is stuck, contaminated, or the circuit is short-circuited to the power supply, causing the signal to remain valid.

[0034] If the number of valid transitions Ni ≥ the preset number of transitions Nmax (e.g., 60 times), then the switch wake-up source is determined to have a signal abnormality transition fault. The value of the preset number of transitions Nmax is based on the vehicle's power management strategy, and its calculation logic is as follows: Set a battery voltage threshold to ensure the vehicle can start normally (e.g., 11.5V); below this voltage, the starter motor may not work; calculate the amount of electricity released when the battery voltage drops from the initial voltage (e.g., 12.5V) to the threshold (11.5V). Measure or estimate the average amount of electricity (Q_single) consumed by the controller when it is woken up once and completes one effective operation; where: Nmax = (total available power) / (power consumption Q_single for a single wake-up).

[0035] The preset number of transitions, Nmax, defines the maximum number of safe wake-ups the battery can tolerate before it is completely discharged. Regardless of whether these wake-ups are caused by normal user operation or abnormal signals, if the total number exceeds Nmax, there is a risk of battery discharge, and fault protection must be triggered.

[0036] In this embodiment, after diagnosing a fault in the switch wake-up source, the controller does not immediately go into sleep mode. Instead, it needs to execute a differentiated processing strategy based on the current network status of the vehicle to both protect the battery and report fault information. (Refer to...) Figure 2 The method in this application embodiment further includes: S103, when the switch wake-up source fails and the vehicle network has been woken up, first send the fault information that caused the vehicle network to be abnormally woken up to the cloud, and then trigger the vehicle network to hibernate. S104: When the switch wake-up source fails and the vehicle network is not woken up, the controller will no longer wake up the vehicle network and will re-enter sleep mode.

[0037] In step S103, after the vehicle is powered off, the controller is woken up for other legitimate reasons (such as another normal wake-up source) and diagnoses the fault of the current wake-up source in the network wake-up state. Since the controller is already in the network wake-up state (i.e., it has successfully sent network management messages and application messages, activating the vehicle communication network), during this period, the controller diagnoses in real time whether a certain switch quantity wake-up source has a stuck fault or an abnormal signal jump fault.

[0038] When troubleshooting, the controller immediately sends a fault message to the gateway or directly to the vehicle communication terminal (T-Box) via the bus (such as CAN / FD). This message includes a fault code (DTC) and a confirmed fault status (such as 0x09), clearly indicating the root cause of the current abnormal state.

[0039] After sending the fault information, the controller immediately executes a sleep procedure: it stops sending all data packets related to application functions and stops sending network management packets used to maintain network activity. These operations cause the gateway to shut down the communication network, putting the entire vehicle network into a sleep state. Finally, the controller itself enters a low-power sleep mode.

[0040] Step S103 utilizes the currently activated network channel to preemptively report the fault, ensuring the cloud receives diagnostic information immediately. Immediately after reporting, a forced hibernation is initiated to minimize network activity time caused by this abnormal wake-up and reduce unnecessary power consumption.

[0041] In step S104, the controller is woken up by a faulty wake-up source, but has not yet (or has just begun) woken up the vehicle network. At this time, the controller is locally woken up from sleep by a certain switch wake-up source and is in a naked wake-up state. In the very short time after being woken up and before preparing to wake up the vehicle network, the controller finds that the current wake-up source itself is faulty by querying the fault flag bit (for example, the source of this wake-up is a switch that has been marked as an abnormal switching fault).

[0042] The specific processing flow of step S104 is as follows: The controller suspends the normal network wake-up process; it will not send network management messages and application messages, thereby preventing the vehicle communication network from being woken up. While suppressing network wake-up, the controller only attempts to send a fault message once via the bus based on the local wake-up power supply; since the network is not fully woken up, this operation may only be completed within the local area network, or rely on the listening function of devices such as T-Box to capture this message. After completing the attempt to send the fault message, the controller itself does not perform any other operations and directly re-enters the sleep state. The purpose of step S104 is to avoid activating the entire large vehicle network system due to a single fluctuation of the fault source, thereby saving a lot of power; where possible, it still attempts to report fault information, but the priority of network sleep is higher than the completeness of fault reporting.

[0043] For steps S104 and S105, fault information is reported through a predefined remote diagnostic message, which includes a fault code for identifying a specific fault and a fault status for characterizing the current state of the fault. When a fault is diagnosed, the fault information is sent once using a confirmation of the fault status. When fault recovery is diagnosed, the fault information is sent once using the historical fault status. When there is no fault information to send, the remote diagnostic message is periodically sent with a payload filled with a specific value.

[0044] The remote diagnostic message is 8 bytes long, with each 4 bytes forming a DTC (Disaster Troubleshooting) information group. The format consists of high, medium, and low bytes and a status byte. The status byte uses only bits 0 and 3: bit 0 = 1 and bit 3 = 1 indicates a confirmed fault, and bit 0 = 0 and bit 3 = 1 indicates a historical fault. When a fault occurs, the DTC byte group is set to 0x00 after sending a confirmed fault status. When a fault recovers, the entire frame is periodically filled with 0x00 after sending a historical fault status. When there is only one DTC, the remaining 4 bytes are filled with 0x00. When there is no fault, bytes 0-7 are all filled with 0x00.

[0045] Taking the height adjustment switch as an example in this application embodiment, the DTC code for the height adjustment switch jamming fault is defined as 9D5071, the signal abnormal jump is 9D512F, the confirmed fault is 0x09, and the historical fault is 0x08. When the controller detects that the height adjustment switch jamming fault has occurred, it sends a fault information to the bus once. The remote diagnostic message bytes 0-7 are filled with (hexadecimal) 9D, 50, 71, 09, 00, 00, 00, 00 respectively, and then periodically sends 00, 00, 00, 00, 00, 00, 00, 00. If the controller detects that the switch jamming fault has been recovered, it will also send a fault information to the bus once. The remote diagnostic message bytes 0-7 are filled with 9D, 50, 71, 08, 00, 00, 00, 00 respectively, and then periodically sends 00, 00, 00, 00, 00, 00, 00, 00.

[0046] For the cloud platform, it parses the fault information uploaded by the vehicle, including parsing the fault code and the fault name and fault status. The confirmed fault is generated into a push notification and can be sent to maintenance personnel via APP or SMS to explain why the vehicle network does not sleep or wakes up abnormally.

[0047] Furthermore, in this embodiment of the application, after the controller diagnoses the stuck fault and the abnormal signal transition fault, the fault recovery logic is as follows: when the vehicle power supply is in the off cycle, if the controller detects that the switching device is continuously disconnected for a certain period of time (100ms in the embodiment), the stuck fault is recovered; when the vehicle power supply is not off, the abnormal signal transition fault is directly recovered, and the transition counter of all switching wake-up source signals is cleared to zero.

[0048] Furthermore, in this embodiment of the application, when the switching device experiences a stuck fault or an abnormal signal transition fault, the controller blocks this wake-up source.

[0049] The methods described in this application embodiment have the following beneficial effects: (1) By diagnosing the switch wake-up source, the network management message can be stopped when the switch wake-up source is abnormal, so that the whole vehicle network can enter hibernation and prevent the vehicle from failing to start due to power failure. (2) By effectively counting and accumulating the transitions of the switch wake-up source signal, the failure mode of the switch signal being enabled-disabled-entering sleep and then enabled again is covered. At the same time, it also prevents the problem of frequent vehicle wake-up and power loss caused by the user frequently operating the switch device after the vehicle is powered off. (3) By performing a counting process on the high-frequency transition of the switch wake-up source signal, the number of times the user can use the function normally after the vehicle is powered off is increased, so as to minimize user complaints. (4) By reporting the fault codes and fault code status of the switching device in real time through the controller, maintenance personnel can quickly and accurately locate the problem, which facilitates the repair of the low-voltage battery power failure problem of the vehicle.

[0050] In summary, this application embodiment addresses the issue of repeated vehicle wake-up caused by abnormal wake-up sources of switching devices by performing fault diagnosis on the switching wake-up sources and shielding abnormal wake-up sources during the controller's sleep or wake-up process. This allows the entire vehicle network to enter sleep mode normally, preventing the vehicle from failing to start due to low-voltage battery depletion. Simultaneously, by collecting fault information reported by each controller and uploading it to the cloud, maintenance personnel can remotely monitor vehicle power-related faults and accurately locate the abnormal controller, thus improving maintenance efficiency.

[0051] This application embodiment also provides a controller, which has a switching device and can wake up the network, the controller comprising: The switch wake-up source signal sampling module is used to continuously sample the switch wake-up source signal during the period when the vehicle is powered off and the power is turned off, so as to obtain the single turn-on time and effective transition count of the switch device. The switch wake-up source fault detection module is used to determine whether the switch wake-up source is faulty based on the single connection time and the effective transition count.

[0052] This application also provides a vehicle including the aforementioned controller.

[0053] Figure 3 This is a block diagram illustrating a vehicle 400 according to an exemplary embodiment. For example, vehicle 400 may be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicle. Vehicle 400 may be an autonomous vehicle, a semi-autonomous vehicle, or a non-autonomous vehicle.

[0054] Reference Figure 3 The vehicle 400 may include various subsystems, such as an infotainment system 410, a perception system 420, a decision control system 430, a drive system 440, and a computing platform 450. The vehicle 400 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of the vehicle 400 can be interconnected via wired or wireless means. In some embodiments, the infotainment system 410 may include a communication system, an entertainment system, and a navigation system, etc.

[0055] The perception system 420 may include several sensors for sensing information about the environment surrounding the vehicle 400. For example, the perception system 420 may include a global positioning system (which may be GPS, BeiDou, or other positioning systems), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0056] The decision control system 430 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system. The drive system 440 may include components that provide power to the vehicle 400. In one embodiment, the drive system 440 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0057] Some or all of the functions of the vehicle 400 are controlled by a computing platform 450. The computing platform 450 may include at least one processor 451 and a memory 452, the processor 451 being able to execute instructions 353 stored in the memory 452.

[0058] Processor 451 can be any conventional processor, such as a commercially available CPU. The processor may also include, for example, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), or a combination thereof.

[0059] The memory 452 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0060] In addition to instruction 353, memory 452 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 452 can be used by computing platform 450.

[0061] In this embodiment of the disclosure, processor 451 may execute instructions 353 to complete all or part of the steps of the above-described method.

[0062] This disclosure also provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the steps of the method provided in this disclosure.

[0063] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A; X applies B; or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0064] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding the specification and drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0065] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0066] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

[0067] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0068] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0069] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain.

[0070] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0071] It should be understood that various parts of the embodiments of this disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0072] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0073] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a hard disk, or an optical disk, etc.

[0074] Although embodiments of the present disclosure have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A method for detecting wake-up source failure, characterized in that, The detection method, applied to a controller with switching devices and the ability to wake up the network, includes: During the period when the vehicle is powered off and the power is turned off, the switch wake-up source signal is continuously sampled to obtain the single turn-on time and effective transition count of the switch device. Based on the single connection time and the effective transition count, determine whether the switch wake-up source is faulty.

2. The method according to claim 1, characterized in that, The method further includes: When the switch wake-up source fails and the vehicle network has already been woken up, first send the fault information that caused the vehicle network to be abnormally woken up to the cloud, and then trigger the vehicle network to hibernate. If the switch wake-up source fails and the vehicle network is not woken up, the vehicle network will not be woken up again, and the controller will re-enter sleep mode.

3. The method according to claim 1, characterized in that, The steps for determining whether the switch wake-up source is faulty based on the connection time and the transition count include: If the single-time turn-on time of the switch wake-up source signal is greater than or equal to the first preset duration, it is determined that the switch wake-up source has a jamming fault; the first preset duration is a threshold defined based on the maximum execution time of the switch device. If the effective number of transitions of the switch wake-up source signal is greater than the preset number of transitions, it is determined that the switch wake-up source has a signal abnormal transition fault; the preset number of transitions is the maximum number of wake-up times calculated based on the voltage of the low-voltage battery dropping to a set threshold value after the vehicle is powered off.

4. The method according to claim 3, characterized in that, The counting methods for the valid transition count include: Set a detection period window and a jump frequency threshold; When the single connection time is detected to be greater than or equal to the second preset duration, the counting of the number of transitions of the switch wake-up source signal is initiated; The total number of times the switch wake-up source signal changes from invalid to valid within the detection period window is counted. The jump frequency is calculated based on the total number of jumps and the duration of the detection period window; The switching frequency is compared with the switching frequency threshold, and the valid switching counts in the switching counter are differentially accumulated based on the comparison result.

5. The method according to claim 4, characterized in that, The step of differentially accumulating the valid jump counts in the jump counter based on the comparison results includes: If the transition frequency is less than the transition frequency threshold, the valid transition counts in the transition counter are added to the total number of counts within the detection period window; If the transition frequency is greater than or equal to the transition frequency threshold, the effective transition count in the transition counter is incremented by 1.

6. The method according to claim 3, characterized in that, The counting methods for valid transition counts include: When it is determined that the switch wake-up source is stuck, the effective jump count in the jump counter is incremented by 1.

7. The method according to claim 1, characterized in that, Fault information is reported through a predefined remote diagnostic message, which includes a fault code for identifying a specific fault and a fault status characterizing the current state of the fault. When a fault is diagnosed, the fault information is sent once using a confirmation of the fault status. When fault recovery is diagnosed, the fault information is sent once using the historical fault status. When there is no fault information to send, the remote diagnostic message is periodically sent with a payload filled with a specific value.

8. The method according to claim 7, characterized in that, The remote diagnostic message is 8 bytes long, with each 4 bytes forming a DTC (Disaster Troubleshooting) information group. The format consists of high, medium, and low bytes and a status byte. The status byte uses only bits 0 and 3: bit 0 = 1 and bit 3 = 1 indicates a confirmed fault, and bit 0 = 0 and bit 3 = 1 indicates a historical fault. When a fault occurs, the DTC byte group is set to 0x00 after sending a confirmed fault status. When a fault recovers, the entire frame is periodically filled with 0x00 after sending a historical fault status. When there is only one DTC, the remaining 4 bytes are filled with 0x00. When there is no fault, bytes 0-7 are all filled with 0x00.

9. A controller, characterized in that, The controller has a switching device and can wake up the network. The controller includes: The switch wake-up source signal sampling module is used to continuously sample the switch wake-up source signal during the period when the vehicle is powered off and the power is turned off, so as to obtain the single turn-on time and effective transition count of the switch device. The switch wake-up source fault detection module is used to determine whether the switch wake-up source is faulty based on the single connection time and the effective transition count.

10. A vehicle, characterized in that, Includes the controller as described in claim 9.

Images