A fault type determination method, device, storage medium and vehicle

Abstract

The application provides a fault type determination method and device, a storage medium and a vehicle, and belongs to the technical field of automobiles. The method comprises the following steps: when the vehicle is in an abnormal sleep state, acquiring state signals and function description signals of a plurality of ECUs in an active state in the vehicle, so as to select a fault ECU whose running information bit is in a working state from the plurality of ECUs according to the running information bit of each state signal, and determine a fault type causing the vehicle to be in the abnormal sleep state according to the function description signal of the fault ECU. The above method takes the ECUs in the active state as candidate ECUs, avoids misjudging the active ECUs which are passively awakened as the root cause of the fault through the running information bit, and determines the fault type by judging whether the task performed by the fault ECU is driven by an external condition through the function description signal, thereby improving the accuracy of the fault type determination.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and in particular to a method, apparatus, storage medium, and vehicle for determining fault types. Background Technology

[0002] With the continuous improvement of automotive electronics, more and more ECUs (Electronic Control Units) are being installed in vehicles to realize various electronic control functions.

[0003] During vehicle power-on, all ECUs in the vehicle are active. After the vehicle is powered off, some ECUs can stop operating, while others need to enter a dormant state to maintain low power consumption and preserve basic operating capabilities.

[0004] However, all ECUs in a vehicle are interconnected via a bus, and an ECU can only enter sleep mode when the bus is idle. When an ECU fails to enter sleep mode due to a malfunction, it continuously occupies the bus and sends signals, preventing other ECUs from entering sleep mode. In other words, the vehicle is in an abnormal sleep state. In this state, multiple ECUs are active simultaneously, making it difficult to identify the ECU that failed to enter sleep mode due to a malfunction, and consequently, it is impossible to accurately determine what kind of malfunction has occurred. Summary of the Invention

[0005] This application provides a method, apparatus, storage medium, and vehicle for determining fault types, improving the accuracy of fault type determination. The technical solution is as follows: On the one hand, a method for determining fault type is provided, the method including; When the vehicle is in an abnormal sleep state, the status signals and function description signals of multiple ECUs in the vehicle are acquired. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU. Based on status signals, candidate ECUs that are in an active state are selected from multiple ECUs; Based on the operating information bits in the status signals corresponding to the candidate ECUs, the faulty ECUs whose operating information bits are in the working state are selected from multiple candidate ECUs. Based on the functional description signal corresponding to the faulty ECU, the type of fault that causes the vehicle to enter an abnormal sleep state is determined.

[0006] In some embodiments, before acquiring the status signals and function description signals of multiple ECUs within the vehicle when the vehicle is in an abnormal sleep state, the method further includes: Obtain the vehicle's sleep condition signal; If all sleep condition signals are consistent with the vehicle's preset sleep signals, start the timer; The vehicle's network communication is monitored based on a timer during a first preset time period; If network communication malfunctions, it indicates that the vehicle is in an abnormal sleep state.

[0007] In some embodiments, when the vehicle is in an abnormal sleep state, acquiring status signals and function description signals of multiple ECUs within the vehicle includes: When a vehicle is in an abnormal sleep state, a time window is determined based on the current time. Acquire the status signals and function description signals of multiple ECUs within the vehicle within a time window.

[0008] In some embodiments, when the vehicle is in an abnormal sleep state, determining a time window based on the current time includes: When the vehicle is in an abnormal sleep state, the time window is obtained by extending the time window forward by a second preset time and backward by a third preset time, based on the current time.

[0009] In some embodiments, acquiring the status signals and function description signals of multiple ECUs within a time window includes: Within the time window, every fourth preset time interval, the status signals and function description signals of multiple ECUs in the vehicle are acquired.

[0010] In some embodiments, the fault type causing the vehicle to enter an abnormal sleep state is determined based on the functional description signal corresponding to the faulty ECU, including: Obtain the reference signals corresponding to the various function description signals of the faulty ECU in sleep mode; If all function description signals are consistent with the corresponding reference signals, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a software fault. If any of the function description signals contains a target function description signal that is inconsistent with the corresponding reference signal, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a hardware fault.

[0011] In some embodiments, if there is a target function description signal among the function description signals that is inconsistent with the corresponding reference signal, after determining the fault type that causes the vehicle to be in an abnormal sleep state as a hardware fault, the method further includes: Based on the mapping relationship between functional description signals and vehicle hardware devices, the target hardware device corresponding to the target functional description signal is determined. The vehicle's display devices output prompts information to remind the vehicle owner to repair the target hardware device.

[0012] On the other hand, a fault type determination apparatus is provided, the apparatus comprising: The signal acquisition unit is configured to acquire status signals and function description signals of multiple ECUs in the vehicle when the vehicle is in an abnormal sleep state. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU. The first screening unit is configured to select candidate ECUs that are in an active state from multiple ECUs based on status signals. The second screening unit is configured to screen out faulty ECUs whose operating information bits are in the working state from the candidate ECUs based on the operating information bits in the status signals corresponding to the candidate ECUs. The fault type determination unit is configured to determine the fault type that causes the vehicle to be in an abnormal sleep state based on the functional description signal corresponding to the faulty ECU.

[0013] In some embodiments, the apparatus further includes: a vehicle body state acquisition unit configured to acquire a sleep condition signal of the vehicle; The timer start unit is configured to start the timer if all sleep condition signals are consistent with the vehicle's preset sleep signals; The monitoring unit is configured to monitor the vehicle's network communication within a first preset time period based on a timer; The anomaly determination unit is configured to determine that the vehicle is in an abnormal sleep state if network communication fails.

[0014] In some embodiments, the signal acquisition unit is configured to determine a time window based on the current time when the vehicle is in an abnormal sleep state. Acquire the status signals and function description signals of multiple ECUs within the vehicle within a time window.

[0015] In some embodiments, the signal acquisition unit is configured to, when the vehicle is in an abnormal sleep state, extend forward by a second preset duration and backward by a third preset duration, respectively, based on the current time, to obtain a time window.

[0016] In some embodiments, the signal acquisition unit is configured to acquire status signals and function description signals of multiple ECUs in the vehicle at fourth preset time intervals within a time window.

[0017] In some embodiments, the fault type determination unit is configured to acquire reference signals corresponding to various functional description signals of the faulty ECU in a sleep state; If all function description signals are consistent with the corresponding reference signals, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a software fault. If any of the function description signals contains a target function description signal that is inconsistent with the corresponding reference signal, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a hardware fault.

[0018] In some embodiments, the fault type determination unit is configured to determine the target hardware device corresponding to the target function description signal based on the mapping relationship between the function description signal and the vehicle hardware device; The vehicle's display devices output prompts information to remind the vehicle owner to repair the target hardware device.

[0019] On the other hand, a vehicle is provided, which includes a main control module, the main control module including a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being used to execute the fault type determination method in the embodiments of this application.

[0020] On the other hand, a computer-readable storage medium is provided for storing at least one computer program, which is loaded and executed by a processor to implement the fault type determination method in the embodiments of this application.

[0021] On the other hand, a computer program product is provided, including a computer program that is executed by a processor to implement the fault type determination method in the embodiments of this application.

[0022] This application provides a method for determining fault types. When a vehicle is in an abnormal sleep state, the method acquires status signals and functional description signals of multiple ECUs within the vehicle. Based on the status signals, candidate ECUs in an active state are identified from among the multiple ECUs. Then, based on the operating information bits in the status signals of the candidate ECUs, faulty ECUs whose operating information bits are in a working state are selected from among the multiple ECUs. Based on the functional description signal of the faulty ECU, the fault type causing the vehicle to be in an abnormal sleep state is determined. ECUs in an active state continuously occupy the bus, preventing other ECUs from entering a sleep state. Therefore, selecting active ECUs as candidate ECUs first reduces the data processing workload for subsequent faulty ECU selection and improves the efficiency of faulty ECU location. If the operating information bit of an active ECU is in a working state, it indicates that there is a task being executed within that active ECU. This active ECU may be the faulty ECU preventing sleep from occurring. By using the operating information bits, the method avoids misjudging passively awakened active ECUs as the root cause of the fault, improving the accuracy of faulty ECU location. Functional description signals are external trigger conditions for ECUs to execute tasks. After determining that there is a task being executed in the faulty ECU, the functional description signals are used to determine whether the task being executed by the faulty ECU is driven by external conditions, thereby determining the fault type and improving the accuracy of fault type determination. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the implementation environment of a fault type determination method provided in an embodiment of this application; Figure 2 This is a flowchart of a fault type determination method provided according to an embodiment of this application; Figure 3 This is a flowchart of a fault type determination method provided according to an embodiment of this application; Figure 4 This is a block diagram of a fault type determination device according to an embodiment of this application; Figure 5 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0026] In this application, the terms "first", "second", etc. are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is there any limitation on the quantity or execution order.

[0027] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0028] It should be noted that the information, data and signals involved in this application (including but not limited to vehicle sleep condition signals, status signals and function description signals of each ECU, etc.) are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0029] Figure 1 This is a schematic diagram illustrating the implementation environment of a fault type determination method provided in an embodiment of this application. See also... Figure 1The implementation environment is in vehicle 101, which is equipped with TBOX (Telematics BOX) 1011 and multiple ECUs 1012. ECUs 1012 include BCM (Body Control Module) 10121 and VCU (Vehicle Control Unit) 10122.

[0030] The TBOX1011 receives sleep condition signals from the BCM10121 and VCU10122 via the CAN (Controller Area Network) bus. These signals include, but are not limited to, key signals and driver's door signals. The signals from the VCU10122 include, but are not limited to, intelligent charging signals and charging permission signals related to charging status. Based on the signals from the BCM10121 and VCU10122, as well as its own sleep condition signal, the TBOX1011 determines whether the vehicle 101 meets the conditions for entering sleep mode. If the vehicle 101 meets the conditions, the TBOX1011 starts a timer. If, during the timer, the vehicle 101 fails to enter sleep mode, or enters sleep mode but cannot re-enter sleep mode after being woken up, the vehicle 101 is determined to be in an abnormal sleep state. TBOX1011 monitors the status signals and function description signals of multiple active ECUs 1012 in vehicle 101 via the CAN bus, identifies the faulty ECU among the multiple active ECUs 1012 based on the status signals, and then determines the fault type of the faulty ECU based on the function description signals.

[0031] Figure 2 This is a flowchart of a fault type determination method provided according to an embodiment of this application. The method is executed by a vehicle, such as... Figure 2 As shown, the method for determining the fault type includes the following steps: S201, when the vehicle is in an abnormal sleep state, acquire the status signals and function description signals of multiple ECUs in the vehicle. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU.

[0032] In this embodiment, when the vehicle is in an abnormal sleep state, the TBOX acquires status signals and function description signals uploaded by multiple ECUs within the vehicle via the CAN bus. An abnormal sleep state refers to a situation where the vehicle meets the conditions for entering a sleep state but fails to do so. Status signals, also known as network management messages, indicate the state of an ECU. An ECU can be in a sleep state, a wake-up state, or an active state. A sleep state refers to a state where the ECU maintains basic operational functions with low power consumption. An ECU in a sleep state can announce its entry into sleep mode to other ECUs connected to the CAN bus by sending a status signal, or it can stop sending status signals to the CAN bus to indicate its entry into sleep mode. A wake-up state is a brief transitional state after an ECU is awakened from sleep mode. An ECU in a wake-up state sends a status signal to the CAN bus to announce its awakening to other ECUs connected to the CAN bus. An active state refers to a state where the ECU can normally perform bus communication, receive, and process signals. In an active state, the ECU periodically sends status signals and function description signals to the CAN bus. The function description signal is a signal sent to the CAN bus by an ECU in an active state during operation, used to indicate the status of the functions associated with that ECU. For example, taking the VCU as an example, its corresponding functional description signals are intelligent charging signal and charging enable signal; taking the BCM as an example, its corresponding functional description signals include key signal, driver's door signal, passenger door signal, driver's door lock signal, and hazard warning light signal.

[0033] S202, based on status signals, selects candidate ECUs that are in an active state from multiple ECUs.

[0034] In this embodiment, based on the states indicated by each status signal, an ECU in an active state is selected as a candidate ECU from multiple ECUs. When the vehicle is in an abnormal sleep state, the status signals obtained by the TBOX may indicate that the ECU is in a sleep state, a wake-up state, or an active state. However, an ECU in a sleep state will only enter a sleep state after briefly sending a status signal, while an ECU in a wake-up state will enter an active state after briefly sending a status signal and will continue to send status signals together with the ECU that was originally in an active state, preventing the vehicle from entering a sleep state. Therefore, an ECU in an active state is selected as a candidate for a faulty ECU.

[0035] S203, based on the operating information bit in the status signal corresponding to the candidate ECU, select the faulty ECU whose operating information bit is in the working state from the candidate ECUs.

[0036] In this embodiment, the value of the operation information bit is extracted from the status signal corresponding to each candidate ECU. Based on this value, it is determined whether the operation information bit is in a working state. If the operation information bit is in a working state, the candidate ECU is identified as a faulty ECU. The operation information bit is a flag bit in the status signal, used to indicate whether the ECU is currently executing a task. When the ECU is executing a task, the ECU sets the value of the operation information bit in the status signal to a first preset value (e.g., 1), indicating that the operation information bit is in a working state. When the ECU is not executing a task, the ECU sets the value of the operation information bit in the status signal to a second preset value (e.g., 0), indicating that the operation information bit is in an idle state.

[0037] The operation information bit is an important basis for determining whether the ECU remains active due to the execution of a task. When the vehicle is in an abnormal sleep state, if the operation information bit of a certain ECU is in the working state, it means that the ECU may be preventing the vehicle from entering the sleep state because the task is not completed or the task is abnormal. Therefore, the ECU with the operation information bit in the working state is identified as a faulty ECU.

[0038] S204, based on the function description signal corresponding to the faulty ECU, determines the type of fault that causes the vehicle to be in an abnormal sleep state.

[0039] In this embodiment, based on the functional description signal corresponding to the faulty ECU, the fault type that prevents the faulty ECU from entering a sleep state is determined, i.e., the fault type that causes the vehicle to be in an abnormal sleep state. The running information bit only indicates that a task is being executed in the faulty ECU, but it cannot indicate whether the task is triggered by external conditions or internal conditions. The function associated with the faulty ECU is the external condition that can trigger its task execution. Therefore, based on the functional description signal corresponding to the faulty ECU, it is determined whether the function associated with the faulty ECU has triggered the faulty ECU to execute a task, and then the fault type that prevents the faulty ECU from entering a sleep state is determined based on the determination result.

[0040] When the vehicle is in sleep mode, each function associated with the ECU has a corresponding reference signal. By comparing the current function description signal of each function with the reference signal of each function in sleep mode, it can be determined whether the function has triggered the faulty ECU to execute a task. The reference signal is used to indicate the preset reference state that each function associated with the ECU should be in when the vehicle is in normal sleep mode. For example, when the ECU is a VCU, the function description signals include the intelligent charging signal (VCU_stSmartCharge) and the charging allow signal (VCU_ChargeAllow). VCU_stSmartCharge is used to indicate whether the vehicle's intelligent charging function is active, and its corresponding reference signal is Not-Allow, that is, the intelligent charging function is prohibited from being activated; VCU_ChargeAllow is used to indicate whether the vehicle's charging function is allowed, and its corresponding reference signal is Charge-forbidden, that is, the charging function is prohibited.

[0041] This application provides a method for determining fault types. When a vehicle is in an abnormal sleep state, the method acquires status signals and functional description signals of multiple ECUs within the vehicle. Based on the status signals, candidate ECUs in an active state are identified from among the multiple ECUs. Then, based on the operating information bits in the status signals of the candidate ECUs, faulty ECUs whose operating information bits are in a working state are selected from the candidate ECUs. Based on the functional description signal of the faulty ECU, the fault type causing the vehicle to be in an abnormal sleep state is determined. ECUs in an active state continuously occupy the bus, preventing other ECUs from entering a sleep state. Therefore, selecting active ECUs as candidate ECUs first reduces the data processing workload for subsequent faulty ECU selection and improves the efficiency of faulty ECU location. If the operating information bit of an active ECU is in a working state, it indicates that there is a task being executed within that active ECU. This active ECU may be the faulty ECU preventing sleep. By using the operating information bits, the method avoids misjudging passively awakened active ECUs as the root cause of the fault, improving the accuracy of faulty ECU location. Functional description signals are external trigger conditions for ECUs to execute tasks. After determining that there is a task being executed in the faulty ECU, the functional description signals are used to determine whether the task being executed by the faulty ECU is driven by external conditions, thereby determining the fault type and improving the accuracy of fault type determination.

[0042] The above embodiment describes the process of selecting active candidate ECUs from multiple ECUs, then selecting faulty ECUs from the candidate ECUs based on the operating information bits in the status signals corresponding to the candidate ECUs, and finally determining the fault type causing the vehicle to enter an abnormal sleep state based on the functional description signal corresponding to the faulty ECU. Based on this, Figure 3This is a flowchart of another fault type determination method provided according to an embodiment of this application. The method describes how to determine if a vehicle is in an abnormal sleep state, how to acquire status signals and function description signals, and how to determine the fault type based on the function description signal corresponding to the faulty ECU. This method is executed by the vehicle. Figure 3 As shown, the method for determining the fault type includes the following steps: S301, Obtain the vehicle's sleep condition signal.

[0043] In this embodiment, the hibernation condition signal is a signal generated or collected by the vehicle's ECU to characterize the vehicle's current physical state or operating conditions, and is used to determine whether the vehicle meets the conditions for entering hibernation mode. The hibernation condition signal includes, but is not limited to, key signal, charging enable signal, intelligent charging signal, remote control signal, and online upgrade signal. Specifically, the key signal indicates whether the vehicle's key is in the off state; this signal originates from the BCM, which sends it to the CAN bus, and the TBOX obtains it from the CAN bus. The charging enable signal indicates whether the vehicle's charging function is enabled, and the intelligent charging signal indicates whether the vehicle's intelligent charging function is active; both originate from the VCU, which sends these two signals to the CAN bus, and the TBOX obtains them from the CAN bus. The remote control signal indicates whether the vehicle is in a non-remote control state, and the online upgrade signal indicates whether the vehicle is in an online upgrade state; both originate from the TBOX itself. Therefore, the TBOX can obtain these two hibernation condition signals by querying its own status.

[0044] S302, if all sleep condition signals are consistent with the vehicle's preset sleep signals, start the timer.

[0045] In this embodiment, the preset sleep signal is used to indicate the vehicle state that each sleep condition signal should indicate when the vehicle meets the conditions for entering sleep mode. The TBOX compares the acquired sleep condition signals with the corresponding preset sleep signals. If all sleep condition signals match the corresponding preset sleep signals, an internal timer is started. Specifically, the preset sleep signal corresponding to the key signal indicates that the vehicle key is off; the preset sleep signal corresponding to the charging allow signal indicates that the vehicle's charging function is disabled; the preset sleep signal corresponding to the smart charging signal indicates that the vehicle's smart charging function is not activated; the preset sleep signal corresponding to the remote control signal indicates that the vehicle is currently in a non-remote control state, i.e., the vehicle has not received a remote control command; and the preset sleep signal corresponding to the prior upgrade signal indicates that the vehicle is not in an online upgrade state, i.e., the vehicle is not currently performing an online upgrade task. If any sleep condition signal does not match the corresponding preset sleep signal, sleep condition signals are continuously acquired until all sleep condition signals match the corresponding preset sleep signals, at which point the timer is started.

[0046] S303 monitors the vehicle's network communication within a first preset time period based on a timer.

[0047] In this embodiment, based on a timer, the TBOX monitors the network communication of each ECU in the vehicle within a first preset time period via the CAN bus to determine whether the vehicle has entered a sleep state within the first preset time period. The first preset time period can be set according to the average duration of the vehicle entering a sleep state.

[0048] S304. If network communication is abnormal, it is determined that the vehicle is in an abnormal sleep state.

[0049] In this embodiment, if network communication malfunctions, it is determined that the vehicle has not entered a hibernation state, i.e., the vehicle is in an abnormal hibernation state. An abnormal network communication means that the vehicle has met the conditions for entering a hibernation state, but network communication on the CAN bus that does not conform to the hibernation scenario still exists, preventing the vehicle from entering hibernation. Specifically, this includes the following two situations: the first situation is that network communication that does not conform to the hibernation scenario exists on the CAN bus for a first preset time period; the second situation is that the vehicle enters hibernation within the first preset time period but is abnormally awakened, and network communication that does not conform to the hibernation scenario exists for a first preset time period after the abnormal awakening, preventing the vehicle from entering hibernation again. The network communication conforming to the hibernation scenario refers to the status signals indicating the hibernation state sent by each ECU in the vehicle.

[0050] In the first scenario, TBOX continuously monitors the CAN bus of the vehicle for network communication that does not conform to the sleep scenario from the start of the timer. If network communication that does not conform to the sleep scenario still exists on the CAN bus when the timer reaches the first preset duration, it is determined that the network communication is abnormal and the vehicle is in an abnormal sleep state.

[0051] For example, the first preset duration is 20 minutes. During the 20th minute, the vehicle continues to have periodic network communication due to a software fault of a certain ECU (e.g., the infotainment controller fails to properly process the hibernation command), causing the vehicle to fail to enter hibernation. When the timer reaches 20 minutes, the TBOX detects that the network communication still exists and determines that the vehicle is in an abnormal hibernation state.

[0052] In the second scenario, during the timer's timing, TBOX first detects network communication on the CAN bus that matches the sleep scenario, i.e., status signals containing sleep commands sent by each ECU. Then, if no network communication is detected on the CAN bus within a preset silent period, it determines that the vehicle has entered sleep mode, resets the timer, and continues monitoring network communication on the CAN bus. If, after the vehicle enters sleep mode, a status signal indicating wake-up status is detected on the CAN bus from an ECU, it determines that the vehicle has been woken up, and proceeds to step S301 to reacquire the vehicle's sleep condition signal. Based on the sleep condition signal, it determines whether the vehicle meets the conditions for entering sleep mode. If the vehicle meets the conditions for entering sleep mode, the timer is restarted, and monitoring of network communication within the first preset period continues until the vehicle consistently fails to meet the sleep scenario's network communication requirements within the first preset period, meaning the vehicle cannot re-enter sleep mode after being woken up, thus determining that the vehicle is in an abnormal sleep state.

[0053] For example, the first preset duration is 20 minutes. Five minutes after the timer starts, if no network communication occurs on the CAN bus, the vehicle is determined to be in sleep mode. However, when the timer reaches 10 minutes, the TBOX may mistakenly trigger a remote door unlock command due to an internal timed task. The BCM is woken up to execute the remote door unlock command. Simultaneously, based on this wake-up event, the TBOX resets the timer and reacquires the vehicle's sleep condition signals. If all sleep condition signals meet the preset conditions for the vehicle to enter sleep mode, the timer is restarted, and network communication within the vehicle is monitored for 20 minutes. Under normal circumstances, the vehicle should re-enter sleep mode after the remote door unlock command is executed. However, the execution of this remote unlock command may unexpectedly prevent the BCM or gateway module (or other ECUs) from entering sleep mode. This ECU continuously sends status signals containing wake-up or activation commands to the CAN bus, causing the vehicle to maintain network communication that does not conform to the sleep scenario for 20 minutes, preventing it from re-entering sleep mode and determining that the vehicle is in an abnormal sleep state.

[0054] S305: When a vehicle is in an abnormal sleep state, a time window is determined based on the current time.

[0055] In this embodiment of the application, when it is determined that the vehicle is in an abnormal sleep state, a time window is determined based on the current time, and the time range for subsequently acquiring status signals and function description signals of multiple ECUs is defined by the time window.

[0056] In some embodiments, when the vehicle is in an abnormal sleep state, a time window is obtained by extending the current time forward by a second preset duration and extending it backward by a third preset duration. The second preset duration and the third preset duration may be equal or unequal. For example, both the second preset duration and the third preset duration may be 10 seconds, that is, the time window is a time interval of 10 seconds before and after determining that the vehicle is in an abnormal sleep state.

[0057] S306 acquires the status signals and function description signals of multiple ECUs within the vehicle within a time window.

[0058] In some embodiments, within a time window, TBOX acquires status signals and function description signals of multiple ECUs in the vehicle every fourth preset time interval.

[0059] S307, based on status signals, selects candidate ECUs that are in an active state from multiple ECUs.

[0060] Please refer to step S202 for the specific process, which will not be repeated here.

[0061] S308, based on the operating information bit in the status signal corresponding to the candidate ECU, filters out the faulty ECU whose operating information bit is in the working state from the candidate ECU.

[0062] Please refer to step S203 for the specific process, which will not be repeated here.

[0063] S309: Obtain the reference signals corresponding to the various function description signals of the faulty ECU in sleep mode.

[0064] In this embodiment, the TBOX stores reference signals corresponding to the functions associated with the ECU when the vehicle is in a sleep state. These reference signals are the function description signals corresponding to the functions in a sleep state. By acquiring the reference signals, the function description signals can be compared with the reference signals to determine the fault type.

[0065] S310, if all function description signals are consistent with the corresponding reference signals, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a software fault.

[0066] In this embodiment, each functional description signal is compared with its corresponding reference signal. If all functional description signals match the corresponding reference signal, the fault type causing the vehicle to enter an abnormal sleep state is determined to be a software fault. The fact that all functional description signals match the corresponding reference signal indicates that the external conditions for each ECU to enter a sleep state are met; that is, the vehicle can enter a sleep state. However, there is a task being executed in the faulty ECU. Therefore, the faulty ECU is not being triggered by the external condition of the functional description signal to execute the task, but rather by an internal software logic anomaly causing the faulty ECU to execute the task. Therefore, the fault type is a software fault.

[0067] For example, if a timer in a faulty ECU fails to properly shut down or reset after the vehicle is powered off, it causes the timer to periodically generate false interrupt or wake-up events during its sleep state. The application layer of the faulty ECU responds to these false events, continuously waking up and attempting to start a task, ultimately resulting in the runtime information bit remaining in an active state. However, the task start request from the faulty ECU is not triggered by external conditions; the task cannot be fully executed but exits after startup due to unmet conditions. Therefore, the runtime information of the faulty ECU is due to a software malfunction.

[0068] It should be noted that after determining that the fault type is a software fault, TBOX can send this diagnostic result to the corresponding service terminal of the vehicle so that the repair personnel or service terminal can perform software repair on the faulty ECU, such as software flashing, firmware upgrade, software reset, etc.

[0069] S311, if there is a target function description signal in each function description signal that is inconsistent with the corresponding reference signal, the fault type that causes the vehicle to be in an abnormal sleep state will be determined as a hardware fault.

[0070] In this embodiment, if at least one target function description signal among the function description signals is inconsistent with the corresponding reference signal, the fault type causing the vehicle to enter an abnormal sleep state is determined to be a hardware fault. When the target function description signal is inconsistent with the corresponding reference signal, it is determined that the faulty ECU is triggered by the function corresponding to the target function description signal to execute the corresponding task, sets the running information bit to the working state, and continuously sends a status signal containing an active command to the CAN bus to prevent the vehicle from entering a sleep state. Therefore, this fault type is a hardware fault.

[0071] For example, suppose the faulty ECU is the BCM, the target function description signal is the driver's side door signal, and the reference signal corresponding to the driver's side door signal is the driver's side door closed state. However, the external sensors of the BCM may be stuck or damaged, causing the door microswitch to still send a driver's side door open level signal to the BCM even when the driver's side door is closed. Therefore, the BCM mistakenly believes that the driver's side door is open, resulting in the driver's side door signal obtained by the TBOX being the driver's side door open state.

[0072] In some embodiments, after determining that the fault type is a hardware fault, the target hardware device corresponding to the target functional description signal is determined based on the mapping relationship between functional description signals and vehicle hardware devices. A prompt message is output based on the vehicle's display device, prompting the vehicle owner to repair the target hardware device. The TBOX pre-stores the mapping relationship between each functional description signal and vehicle hardware devices. When the fault type is determined to be a hardware fault and the target functional description signal is inconsistent with the corresponding reference signal, the target hardware device corresponding to the target functional description signal is determined. It should be noted that each functional description signal corresponds to at least one vehicle hardware device, and the prompt message includes at least one target hardware device, allowing repair personnel to troubleshoot the target hardware device.

[0073] It should be noted that the embodiments of this application are implemented in the TBOX inside the vehicle. In some embodiments, the TBOX can send the status signals and function description signals of multiple ECUs to a server that communicates with the vehicle, and the fault type determination method provided in the embodiments of this application is implemented on the server.

[0074] This application provides a method for determining fault types. First, it acquires the vehicle's sleep condition signal. Based on this signal, it determines whether the vehicle meets the preset conditions for entering sleep mode. A collaborative verification mechanism using multiple sleep condition signals avoids misjudgments of abnormal sleep mode caused by a single signal, improving the reliability of sleep mode detection. A time window is determined based on the time period before and after the determination of the vehicle's abnormal sleep state, enabling the acquisition of complete data sent to the CAN bus by each ECU, avoiding the randomness of single-point sampling and improving the accuracy of fault ECU location. Active ECUs are first selected as candidate ECUs, reducing the data processing workload for subsequent fault ECU selection and improving the efficiency of fault ECU location. The use of runtime information bits avoids misjudging passively awakened active ECUs as the root cause of faults, further improving the accuracy of fault ECU location. Functional description signals are used to determine whether the task executed by the faulty ECU is driven by external conditions, thereby determining the fault type and improving the accuracy of fault type determination.

[0075] Figure 4This is a block diagram of a fault type determination apparatus according to an embodiment of this application. The apparatus is used to perform the steps of the fault type determination method described above, see below. Figure 4 The device includes: The signal acquisition unit 401 is configured to acquire status signals and function description signals of multiple ECUs in the vehicle when the vehicle is in an abnormal sleep state. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU. The first screening unit 402 is configured to screen candidate ECUs that are in an active state from multiple ECUs based on status signals. The second screening unit 403 is configured to screen out faulty ECUs whose operating information bits are in the working state from the candidate ECUs based on the operating information bits in the status signals corresponding to the candidate ECUs. The fault type determination unit 404 is configured to determine the fault type that causes the vehicle to be in an abnormal sleep state based on the function description signal corresponding to the faulty ECU.

[0076] In some embodiments, the apparatus further includes: a vehicle body state acquisition unit configured to acquire a sleep condition signal of the vehicle; The timer start unit is configured to start the timer if all sleep condition signals are consistent with the vehicle's preset sleep signals; The monitoring unit is configured to monitor the vehicle's network communication within a first preset time period based on a timer; The anomaly determination unit is configured to determine that the vehicle is in an abnormal sleep state if network communication fails.

[0077] In some embodiments, the signal acquisition unit 401 is configured to determine a time window based on the current time when the vehicle is in an abnormal sleep state. Acquire the status signals and function description signals of multiple ECUs within the vehicle within a time window.

[0078] In some embodiments, the signal acquisition unit 401 is configured to, when the vehicle is in an abnormal sleep state, extend forward by a second preset duration and backward by a third preset duration, respectively, based on the current time, to obtain a time window.

[0079] In some embodiments, the signal acquisition unit 401 is configured to acquire status signals and function description signals of multiple ECUs in the vehicle at fourth preset time intervals within a time window.

[0080] In some embodiments, the fault type determination unit 404 is configured to acquire reference signals corresponding to various functional description signals of the faulty ECU in a sleep state. If all function description signals are consistent with the corresponding reference signals, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a software fault. If any of the function description signals contains a target function description signal that is inconsistent with the corresponding reference signal, the fault type that causes the vehicle to be in an abnormal sleep state will be identified as a hardware fault.

[0081] In some embodiments, the fault type determination unit 403 is configured to determine the target hardware device corresponding to the target function description signal based on the mapping relationship between the function description signal and the vehicle hardware device; The vehicle's display devices output prompts information to remind the vehicle owner to repair the target hardware device.

[0082] This application provides a fault type determination device. When a vehicle is in an abnormal sleep state, the device acquires status signals and functional description signals of multiple ECUs within the vehicle. Based on the status signals, it identifies candidate ECUs that are active from among the multiple ECUs. Then, based on the running information bits in the status signals of the candidate ECUs, it filters out faulty ECUs whose running information bits are in the working state from among the multiple ECUs. Based on the functional description signal of the faulty ECU, it determines the fault type causing the vehicle to be in an abnormal sleep state. Active ECUs continuously occupy the bus, preventing other ECUs from entering a sleep state. Therefore, filtering active ECUs as candidate ECUs first reduces the data processing workload of subsequent faulty ECU filtering and improves the efficiency of faulty ECU location. If the running information bit of an active ECU is in the working state, it indicates that there is a task being executed within that active ECU. This active ECU may be the faulty ECU preventing sleep from occurring. By using the running information bits, it avoids misjudging passively awakened active ECUs as the root cause of the fault, improving the accuracy of faulty ECU location. Functional description signals are external trigger conditions for ECUs to execute tasks. After determining that there is a task being executed in the faulty ECU, the functional description signals are used to determine whether the task being executed by the faulty ECU is driven by external conditions, thereby determining the fault type and improving the accuracy of fault type determination.

[0083] It should be noted that the fault type determination device provided in the above embodiments is only illustrated by the division of the above functional modules when running the application. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the fault type determination device and the fault type determination method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0084] Figure 5This is a structural schematic diagram of a vehicle provided according to an embodiment of this application.

[0085] Typically, vehicle 500 includes: a main control module 501, a CAN interface 502, a hard-wired input interface 503, and a hard-wired output interface 504. The main control module 501 is connected to the CAN interface 502, the hard-wired input interface 503, and the hard-wired output interface 504, respectively.

[0086] The main control module 501 typically includes a processor and memory. The processor may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor can be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the vehicle's screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning. The memory may include one or more computer-readable storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, a non-transitory computer-readable storage medium in the memory is used to store at least one computer program, which is executed by a processor to implement the fault type determination method provided in the method embodiments of this application.

[0087] The CAN interface 502 may include a powertrain CAN interface, a motor CAN interface, and a diagnostic CAN interface. The powertrain CAN interface is used to communicate with the vehicle's powertrain module, the motor CAN interface is used to communicate with the vehicle's motor controller, and the diagnostic CAN interface is used to communicate with diagnostic equipment.

[0088] The hard-wired input interface 503 is used to receive hard-wired control signals. The hard-wired output interface 504 is used to send control commands to the vehicle's electronic control components, causing them to perform corresponding actions. These electronic control components include a power management system, a motor controller, an on-board charger, and a body control system.

[0089] The main control module 501 can communicate with the vehicle's powertrain module, motor controller, and diagnostic equipment via the CAN interface 502, and generate control commands based on the hard-wired control signals received by the hard-wired input interface 503, so as to send the control commands to the vehicle's electronic control components via the hard-wired output interface 504.

[0090] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on vehicle 500 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0091] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor of an electronic device to implement the operations performed by the electronic device in the fault type determination method of the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0092] This application also provides a computer program product, including a computer program loaded and executed by a processor to implement the fault type determination method as described in the above embodiments.

[0093] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0094] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining fault type, characterized in that, The method includes: When the vehicle is in an abnormal sleep state, the status signals and function description signals of multiple ECUs in the vehicle are acquired. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU. Based on the status signal, candidate ECUs that are in an active state are selected from the plurality of ECUs; Based on the operating information bit in the status signal corresponding to the candidate ECU, the faulty ECUs whose operating information bits are in the working state are selected from the candidate ECUs; Based on the functional description signal corresponding to the faulty ECU, the fault type that caused the vehicle to be in an abnormal sleep state is determined.

2. The method according to claim 1, characterized in that, Before acquiring the status signals and function description signals of multiple ECUs within the vehicle when the vehicle is in an abnormal sleep state, the method further includes: Obtain the vehicle's sleep condition signal; If all the sleep condition signals are consistent with the vehicle's preset sleep signal, start the timer; The timer is used to monitor the vehicle's network communication within a first preset time period; If the network communication malfunctions, it is determined that the vehicle is in an abnormal sleep state.

3. The method according to claim 1, characterized in that, When the vehicle is in an abnormal sleep state, the process of acquiring status signals and function description signals of multiple ECUs within the vehicle includes: When a vehicle is in an abnormal sleep state, a time window is determined based on the current time. The status signals and function description signals of multiple ECUs in the vehicle are acquired within the time window.

4. The method according to claim 3, characterized in that, When the vehicle is in an abnormal sleep state, determining the time window based on the current time includes: When the vehicle is in an abnormal sleep state, the time window is obtained by extending the time window forward by a second preset time and backward by a third preset time, based on the current time.

5. The method according to claim 3, characterized in that, The acquisition of status signals and function description signals of multiple ECUs within the vehicle during the time window includes: Within the time window, at every fourth preset time interval, the status signals and function description signals of multiple ECUs in the vehicle are acquired.

6. The method according to claim 1, characterized in that, The determination of the fault type causing the vehicle to enter an abnormal sleep state based on the functional description signal corresponding to the faulty ECU includes: Obtain the reference signals corresponding to the various function description signals of the faulty ECU in the sleep state; If all the function description signals are consistent with the corresponding reference signals, the fault type that causes the vehicle to be in an abnormal sleep state will be determined as a software fault. If any of the function description signals is inconsistent with the corresponding reference signal, the fault type that causes the vehicle to be in an abnormal sleep state will be determined as a hardware fault.

7. The method according to claim 6, characterized in that, After determining that the fault type causing the vehicle to enter an abnormal sleep state is a hardware fault, if any of the aforementioned function description signals contains a target function description signal that is inconsistent with the corresponding reference signal, the method further includes: Based on the mapping relationship between the functional description signal and the vehicle hardware device, the target hardware device corresponding to the target functional description signal is determined; The vehicle's display device outputs a prompt message, which is used to remind the vehicle owner to repair the target hardware device.

8. A fault type determination device, characterized in that, The device includes: The signal acquisition unit is configured to acquire status signals and function description signals of multiple ECUs in the vehicle when the vehicle is in an abnormal sleep state. The status signals are used to indicate the status of the ECU, and the function description signals are used to indicate the status of the functions associated with the ECU. The first screening unit is configured to screen out candidate ECUs that are in an active state from the plurality of ECUs based on the status signal. The second screening unit is configured to screen out faulty ECUs whose operating information bits are in a working state from the candidate ECUs based on the operating information bits in the status signals corresponding to the candidate ECUs. The fault type determination unit is configured to determine the fault type that causes the vehicle to be in an abnormal sleep state based on the function description signal corresponding to the faulty ECU.

9. A vehicle, characterized in that, The vehicle includes a main control module, which includes a processor and a memory. The memory is used to store at least one computer program, which is loaded by the processor and executed as the fault type determination method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program for performing the fault type determination method according to any one of claims 1 to 7.

Images