Method and device for repairing abnormal dormancy of vehicle

Abstract

The invention relates to the field of vehicle abnormity monitoring, in particular to a method and device for repairing abnormal dormancy of a vehicle. According to the invention, the abnormal dormancy event of the vehicle is monitored in real time through the cloud, the accidental abnormal wake-up fault of the electronic control unit can be actively captured, and the problem of difficult fault reproduction is solved. Log data in the abnormal electronic control unit is obtained and analyzed, whether resetting is needed or not is accurately judged, invalid operation is avoided, and the repairing efficiency is improved. The vehicle state monitoring data threshold value is automatically detected, a reset instruction is sent after the condition is met, remote automatic repair is achieved, manual intervention is reduced, and cost is reduced. The whole process from fault monitoring, analysis and judgment to instruction sending is automatic, full-automatic closed-loop processing is achieved, and the vehicle low-power-consumption management requirement under the complex electronic and electrical architecture is met. The vehicle is reset when conditions such as vehicle locking duration and electric quantity are met, normal use of a user is not affected, rapid fault repair is achieved, and vehicle reliability and user experience are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle anomaly monitoring, and specifically to a method and apparatus for repairing abnormal vehicle hibernation. Background Technology

[0002] With the increasing complexity of automotive electronic and electrical architectures, the network management mechanism of the Electronic Control Unit (ECU) has become crucial for the low-power design of the entire vehicle. When the vehicle enters sleep mode, the ECU must switch to a low-power mode according to predetermined logic to prevent excessive battery drain. However, in actual use, problems such as internal ECU logic errors, software lag, and communication protocol anomalies frequently occur, leading to continuous activation of buses such as the Controller Area Network (CAN) and Linking Network (LIN), frequent network wake-ups, and consequently, faults such as excessive static current and battery depletion, seriously affecting the user experience and vehicle reliability. Traditional solutions mainly rely on users actively reporting faults and then using offline diagnostic equipment to read ECU fault codes and perform software rewriting for repair.

[0003] However, this approach has many drawbacks: abnormal wake-up faults are sporadic, and offline diagnosis makes it difficult to reproduce the fault scenario, leading to difficulties in problem localization; the repair process that relies entirely on manual intervention is not only time-consuming and costly, but also causes inconvenience to users by making the vehicle unusable; existing remote diagnostic technologies can only report faults, and subsequent repairs still require manual operation by the user or parking assistance, which cannot achieve a fully automated closed-loop process from fault detection to repair. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method and apparatus for repairing abnormal vehicle hibernation, in order to solve the problems of traditional ECU abnormal wake-up fault handling methods, such as difficulty in fault reproduction, low repair efficiency, high cost, and inability to achieve fully automated closed-loop processing.

[0005] In a first aspect, embodiments of the present invention provide a method for repairing abnormal vehicle hibernation, the method comprising:

[0006] When an abnormal sleep event is detected in the vehicle, the abnormal electronic control unit in the vehicle is located;

[0007] Obtain the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle;

[0008] If the reset command is sent to the vehicle, then it is checked whether the vehicle's status monitoring data has reached the corresponding threshold.

[0009] When the status monitoring data reaches the corresponding threshold, a reset command is sent to the vehicle, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

[0010] Furthermore, the method for locating the abnormal electronic control unit in the vehicle includes:

[0011] Obtain the exception type corresponding to the abnormal sleep event;

[0012] The electronic control units in the vehicle are investigated according to the investigation strategy corresponding to the anomaly type to identify the abnormal electronic control units in the vehicle.

[0013] Furthermore, the step of investigating the electronic control unit in the vehicle according to the investigation strategy corresponding to the anomaly type to obtain the abnormal electronic control unit in the vehicle includes:

[0014] If the abnormality type is a deep sleep state without sleep type, a wake-up command is sent to the vehicle's on-board terminal, wherein the on-board terminal is used to switch the vehicle's entire network to an inactive state according to the wake-up command, wherein the deep sleep state without sleep type is used to indicate that the vehicle is unable to enter deep sleep mode due to system failure, special function activation or external device connection.

[0015] When the vehicle's network is inactive, read the static power consumption data of all electronic control units in the vehicle, as well as the difference in state of charge of the vehicle's battery before and after wake-up.

[0016] By comparing the static power consumption data with a preset power consumption threshold, electronic control units whose static power consumption data is greater than or equal to the preset power consumption threshold are selected as candidate electronic control units, and candidate electronic control units whose static power consumption data is correlated with the difference in state of charge are selected as abnormal electronic control units.

[0017] Furthermore, the step of investigating the electronic control unit in the vehicle according to the investigation strategy corresponding to the anomaly type to obtain the abnormal electronic control unit in the vehicle includes:

[0018] If the abnormality type is the inactive state non-sleep type, then the bus data of the vehicle is read and the bus data is converted into a binary data sequence. The inactive state non-sleep type is used to characterize that the vehicle is waiting for user operation, the system self-test has not been completed, or the vehicle has not entered a relatively static sleep state due to environmental perception requirements.

[0019] Each bit in the binary data sequence is matched with its corresponding status signal to obtain the target bit in the binary data sequence that is in a non-sleep state. The electronic control unit corresponding to the target bit is then used as the abnormal electronic control unit. Each bit in the binary data sequence corresponds to one electronic control unit, and the status signal is used to indicate whether the electronic control unit is in a sleep state.

[0020] Furthermore, detecting whether the vehicle's status monitoring data reaches a corresponding threshold includes:

[0021] Obtain the list of devices to be repaired corresponding to the malfunctioning electronic control unit;

[0022] Acquire various status monitoring data of the vehicle, including vehicle locking duration, battery health data, and network performance data;

[0023] The vehicle identifier of the vehicle is added to the list of vehicles to be repaired, and the status monitoring data of each status are monitored in real time to see if they reach the corresponding threshold.

[0024] Furthermore, when the status monitoring data reaches a corresponding threshold, a reset command is sent to the vehicle, including:

[0025] When all status monitoring data reach the corresponding threshold, it is detected whether the vehicle has received an unlocking command.

[0026] If the vehicle does not receive the unlock command, the vehicle's vehicle identifier is removed from the list of vehicles to be repaired, and a reset command is sent to the vehicle.

[0027] Furthermore, the method also includes:

[0028] If the vehicle receives the unlock command, then stop sending reset commands to the vehicle, and wait for the vehicle to re-enter the locked state before executing the step of sending reset commands.

[0029] Furthermore, after sending a reset command to the vehicle, the method further includes:

[0030] Detect whether the vehicle is still experiencing abnormal sleep events;

[0031] If the vehicle still experiences abnormal sleep events, the vehicle identifier will be added back to the list of vehicles to be repaired, and the status monitoring data will be continuously monitored to see if they reach the corresponding thresholds.

[0032] Furthermore, the method also includes:

[0033] If it is determined that the reset command will not be sent to the vehicle, then the system update data packet corresponding to the internal log data is obtained;

[0034] The system update data package is pushed to the vehicle, wherein the vehicle is used to repair the malfunctioning electronic control unit according to the system update data package.

[0035] Secondly, embodiments of the present invention provide a repair device for abnormal vehicle hibernation, the device comprising:

[0036] The detection module is used to locate the abnormal electronic control unit in the vehicle when an abnormal sleep event is detected in the vehicle.

[0037] The acquisition module is used to acquire the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle.

[0038] An analysis module is used to detect the vehicle's status monitoring data if the reset command is sent to the vehicle.

[0039] The sending module is used to send a reset command to the vehicle when the status monitoring data reaches a corresponding threshold, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

[0040] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0041] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0042] This application utilizes real-time cloud monitoring of abnormal vehicle sleep events to proactively detect intermittent abnormal wake-up faults in electronic control units (ECUs), resolving the difficulty in reproducing these faults. It analyzes internal log data from the abnormal ECU to accurately determine whether a reset is necessary, avoiding ineffective operations and improving repair efficiency. It automatically detects vehicle status monitoring data thresholds and sends a reset command when conditions are met, achieving remote automatic repair, reducing manual intervention and costs. The entire process, from fault monitoring and analysis to command sending, is automated, achieving a fully automated closed-loop process that meets the low-power management requirements of vehicles with complex electronic and electrical architectures. The vehicle performs a reset when conditions such as lock duration and battery level are met, without affecting normal user operation, enabling rapid fault repair and improving vehicle reliability and user experience. Attached Figure Description

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating a method for repairing abnormal vehicle hibernation according to some embodiments of the present invention;

[0045] Figure 2 This is a flowchart illustrating another method for repairing abnormal vehicle hibernation according to some embodiments of the present invention;

[0046] Figure 3 This is a flowchart illustrating another method for repairing abnormal vehicle hibernation according to some embodiments of the present invention;

[0047] Figure 4 This is a flowchart illustrating another method for repairing abnormal vehicle hibernation according to some embodiments of the present invention;

[0048] Figure 5 This is a structural block diagram of a vehicle abnormal sleep repair device according to an embodiment of the present invention;

[0049] Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] According to an embodiment of the present invention, a method and apparatus for repairing abnormal vehicle hibernation are provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0052] This embodiment provides a method for repairing abnormal vehicle hibernation. Figure 1This is a flowchart of a method for repairing abnormal vehicle hibernation according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0053] Step S101: When an abnormal sleep event is detected in the vehicle, locate the abnormal electronic control unit in the vehicle.

[0054] In this embodiment, it is first necessary to clarify that an abnormal sleep event refers to a situation where, after the vehicle is turned off and locked, it fails to enter a normal sleep state (such as Inactive or Abandon mode) according to preset logic, which manifests as abnormal battery power consumption and continuous high power consumption operation of some electronic control units. The cloud monitors the abnormality by collecting bus data (such as M241 data) and battery status data (such as state of charge and static power consumption) uploaded by the vehicle terminal (TCAM) in real time.

[0055] In this embodiment of the application, locating an abnormal electronic control unit in a vehicle includes the following steps:

[0056] Step A1: Obtain the exception type corresponding to the abnormal sleep event.

[0057] Specifically, based on the bus data (such as M241 data) and battery status information (such as state of charge and static power consumption) uploaded by the vehicle terminal, the system automatically distinguishes the abnormality type as either inactive (non-sleep) or deep sleep (abandon) (non-sleep) through a preset algorithm.

[0058] Among them, the type of deep sleep state without sleep refers to the situation where the vehicle should enter deep sleep mode to save power to the greatest extent after the engine is turned off and the car is locked. At this time, most hardware components should be turned off. However, in reality, some electronic control units or components are still consuming power and have not entered deep sleep state. This can be judged by phenomena such as abnormal battery power consumption and excessive difference in battery state of charge before and after waking up.

[0059] Step A2: Investigate the electronic control units in the vehicle according to the investigation strategy corresponding to the anomaly type to identify the abnormal electronic control units in the vehicle.

[0060] Specifically, the electronic control units in the vehicle are investigated according to the investigation strategy corresponding to the anomaly type to identify the abnormal electronic control units in the vehicle, including the following steps A201-A203:

[0061] Step A201: If the abnormality type is deep sleep state non-sleep state, a wake-up command is sent to the vehicle's on-board terminal, wherein the on-board terminal is used to switch the vehicle's entire network to an inactive state according to the wake-up command.

[0062] When the anomaly is determined to be a state of deep sleep not being in sleep mode, the cloud sends a wake-up command to the vehicle's onboard terminal via a mobile communication network (such as 4G / 5G). Upon receiving the command, the onboard terminal first activates its own communication module, and then sends a network management wake-up frame to the vehicle network via the controller area network bus, switching the vehicle from deep sleep mode (where all non-essential ECUs are powered down) to an inactive state (where some ECUs maintain low-power operation). The "deep sleep not in sleep mode" type indicates that the vehicle cannot enter deep sleep mode due to system failure, activation of special functions, or connection of external devices.

[0063] During this process, the vehicle terminal verifies the legality of the wake-up command (such as command signature and timestamp) to ensure that unauthorized operations cannot trigger wake-up. At the same time, it records the timestamp and trigger source of the wake-up event as log basis for subsequent analysis.

[0064] Step A202: When the vehicle's network is inactive, read the static power consumption data of all electronic control units in the vehicle, as well as the difference in state of charge of the vehicle's battery before and after wake-up.

[0065] After the vehicle network switches to an inactive state, the onboard terminal sends a power consumption query command to all electronic control units (ECUs) via diagnostic services (such as the UDS protocol). Each ECU returns its current static power consumption data (in milliamperes). Simultaneously, the onboard terminal reads the pre-wake-up state of charge (SOC) value recorded by the battery management system and collects the current post-wake-up SOC value in real time, calculating the difference between the two (ΔSOC). To ensure data accuracy, three data collections are performed after the inactive state has stabilized for 5 minutes, and the average value is taken as the final result. If ΔSOC exceeds a preset threshold (e.g., 0.5%), abnormal power consumption is considered to exist.

[0066] Step A203: Compare the static power consumption data with the preset power consumption threshold, and select the electronic control units whose static power consumption data is greater than or equal to the preset power consumption threshold as candidate electronic control units, and select the candidate electronic control units whose static power consumption data is correlated with the difference between the static power consumption data and the state of charge as abnormal electronic control units.

[0067] The static power consumption data of each electronic control unit collected is compared with a preset threshold (such as normal sleep power consumption should be less than 5 mA), and ECUs with power consumption values ​​≥ the threshold are marked as candidate electronic control units.

[0068] Subsequently, by calculating the Pearson correlation coefficient (r) between the power consumption value and ΔSOC of each candidate electronic control unit, if r≥0.7 and p<0.05, it is determined that the abnormal power consumption of the ECU is significantly correlated with the battery power consumption, and it is confirmed as an abnormal electronic control unit.

[0069] For example, if a candidate electronic control unit has a static power consumption of 20 mA (far exceeding the threshold) and its power consumption fluctuation is highly consistent with the trend of ΔSOC change, then the candidate electronic control unit will be identified as the root cause of the deep sleep abnormality. A diagnostic report containing the identifier of the abnormal electronic control unit, power consumption value, and correlation coefficient will be generated for engineers to further analyze and repair.

[0070] Step S102: Obtain the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle.

[0071] In this embodiment, after locating the malfunctioning electronic control unit (ECU), a data request command is sent to the ECU via the On-Board Diagnostics (OBD) interface. Upon receiving the command, the ECU transmits its internally stored operating log data (such as fault codes, event timestamps, software operating status, and real-time sensor data) to the vehicle terminal via the controller area network (CLAN) bus.

[0072] The vehicle-mounted terminal encrypts the data (e.g., using the AES-128 algorithm) before uploading it to the cloud via the mobile communication network. Upon receiving the log data, the cloud automatically performs format verification and integrity checks to ensure the data is accurate before storing it in a dedicated database, providing a foundation for subsequent analysis.

[0073] The cloud-based system performs a multi-dimensional evaluation of internal log data: First, it checks for recurring fault codes (e.g., recording the same fault code three times consecutively); if present, it marks them as persistent anomalies. Second, it analyzes the temporal changes of key parameters (e.g., voltage fluctuations during sleep mode switching, signal response delays) to determine if software logic errors exist. Finally, it combines the hardware health score of the electronic control unit (calculated based on parameters such as operating temperature and runtime) to assess whether the fault is caused by a temporary software anomaly or a potential hardware problem. If the analysis results indicate that the anomaly is caused by a transient software error (e.g., signal timeout, memory overflow), and the electronic control unit hardware is normal, it is determined that normal operation can be restored via a reset command.

[0074] If there is a risk of hardware failure or persistent software logic errors, an OTA upgrade or manual repair process will be triggered to avoid unnecessary reset operations. Finally, the analysis results and decision-making basis will be used to generate a diagnostic report for engineers to review and confirm before executing the corresponding instructions.

[0075] Step S103: If it is determined that a reset command will be sent to the vehicle, then check whether the vehicle's status monitoring data has reached the corresponding threshold.

[0076] In this embodiment of the application, detecting whether the vehicle's status monitoring data has reached the corresponding threshold includes: obtaining a list of devices to be repaired corresponding to abnormal electronic control units; obtaining various status monitoring data of the vehicle, wherein the status monitoring data includes the vehicle's locking duration, battery health data, and network performance data; adding the vehicle's vehicle identifier to the list of devices to be repaired, and monitoring in real time whether each status monitoring data has reached the corresponding threshold.

[0077] Specifically, after locating the malfunctioning electronic control unit (ECU), the system automatically retrieves the standardized repair process template corresponding to that type of malfunction from the cloud-based database, generating a list of ECUs to be repaired. The list includes the ECU's component number, a description of the fault type (e.g., not in deep sleep mode), a suggested repair method (reset or OTA upgrade), and repair records of vehicles with similar malfunctions.

[0078] Meanwhile, the list of vehicles to be repaired will be linked to information such as the vehicle identification number (VIN) and user contact information, which will facilitate the issuance of subsequent repair instructions and status tracking, ensuring that the repair task for each abnormal vehicle is uniquely identified and managed.

[0079] Then, the vehicle's status monitoring data is collected in real time through the on-board terminal. For example, the duration of vehicle locking is recorded by the Body Control Controller (BCM) and transmitted to the on-board terminal via the CAN bus; battery health data, including parameters such as State of Charge (SOC), internal resistance, and voltage, is monitored and uploaded in real time by the Battery Management System (BMS); network performance data, covering indicators such as signal strength, transmission latency, and packet loss rate of mobile communication networks, is automatically collected by the communication module of the on-board terminal. All data is encrypted and stored in the cloud to ensure the security of data transmission and storage, and is updated every minute to ensure real-time performance.

[0080] Finally, the Vehicle Identification Number (VIN) and engine number of the currently malfunctioning vehicle are added to the corresponding entry in the repair list, forming a binding relationship with the malfunctioning electronic control unit. Simultaneously, real-time monitoring is initiated: when the vehicle is locked for more than 10 minutes (to avoid interfering with user operation), the battery SOC is greater than 40% and the health score is higher than 80 points (to prevent insufficient power during repair), and the network signal strength is greater than -85dBm and the latency is less than 200 milliseconds (to ensure stable command transmission), the repair command issuance process will be triggered if the monitored data reaches the preset thresholds. If any indicator fails to meet the standard, data fluctuations will be continuously monitored and recorded until all thresholds are met or the corresponding threshold is reached.

[0081] Step S104: When the status monitoring data reaches the corresponding threshold, a reset command is sent to the vehicle, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

[0082] In this embodiment, when the vehicle is locked for more than 10 minutes, the battery state of charge (SOC) is greater than 40% and the health score is higher than 80, the network signal strength is greater than -85dBm and the transmission delay is less than 200 milliseconds, the cloud confirms that the status monitoring data has reached a preset threshold and immediately generates a reset command containing the identifier of the abnormal electronic control unit. This command is encrypted using a symmetric encryption algorithm (such as AES-128) and is supplemented with a timestamp and digital signature to ensure the legitimacy of the command.

[0083] The command is sent to the vehicle terminal via the mobile communication network. Upon receiving the command, the vehicle terminal first verifies the signature and timeliness, and then sends a hard reset signal (e.g., power off and then back on) or a soft reset command (e.g., triggering a watchdog timer) to the malfunctioning electronic control unit via the controller area network bus. After the reset is complete, the electronic control unit reinitializes and enters self-test mode, feeding back the reset result (success / failure) to the vehicle terminal via the CAN bus. The vehicle terminal encrypts and uploads the result to the cloud, while simultaneously recording log information such as reset time and execution status, forming a complete closed-loop control process.

[0084] This application utilizes real-time cloud monitoring of abnormal vehicle sleep events to proactively detect intermittent abnormal wake-up faults in electronic control units (ECUs), resolving the difficulty in reproducing these faults. It analyzes internal log data from the abnormal ECU to accurately determine whether a reset is necessary, avoiding ineffective operations and improving repair efficiency. It automatically detects vehicle status monitoring data thresholds and sends a reset command when conditions are met, achieving remote automatic repair, reducing manual intervention and costs. The entire process, from fault monitoring and analysis to command sending, is automated, achieving a fully automated closed-loop process that meets the low-power management requirements of vehicles with complex electronic and electrical architectures. The vehicle performs a reset when conditions such as lock duration and battery level are met, without affecting normal user operation, enabling rapid fault repair and improving vehicle reliability and user experience.

[0085] Figure 2 This is a flowchart of a method for repairing abnormal vehicle hibernation according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0086] Step S201: When an abnormal sleep event is detected in the vehicle, locate the abnormal electronic control unit in the vehicle.

[0087] In this embodiment, it is first necessary to clarify that an abnormal sleep event refers to a situation where, after the vehicle is turned off and locked, it fails to enter a normal sleep state (such as Inactive or Abandon mode) according to preset logic, which manifests as abnormal battery power consumption and continuous high power consumption operation of some electronic control units. The cloud monitors the abnormality by collecting bus data (such as M241 data) and battery status data (such as state of charge and static power consumption) uploaded by the vehicle terminal (TCAM) in real time.

[0088] In this embodiment of the application, locating an abnormal electronic control unit in a vehicle includes the following steps:

[0089] Step B1: Obtain the exception type corresponding to the abnormal sleep event.

[0090] Specifically, based on the bus data (such as M241 data) and battery status information (such as state of charge and static power consumption) uploaded by the vehicle terminal, the system automatically distinguishes the abnormality type as either inactive (non-sleep) or deep sleep (abandon) (non-sleep) through a preset algorithm.

[0091] The "inactive state without hibernation" type refers to a situation where, after the vehicle is turned off and locked, it should enter a low-power inactive state. However, some electronic control units fail to stop working as expected and remain operational, preventing the vehicle from entering a normal hibernation state. This anomaly can be detected through relevant signals in the bus data, manifested by the corresponding electronic control unit's status flag showing an active state. The "inactive state without hibernation" type is used to characterize situations where the vehicle is waiting for user operation, the system self-check is incomplete, or environmental sensing requirements prevent it from entering a relatively static hibernation state.

[0092] Step B2: Investigate the electronic control units in the vehicle according to the investigation strategy corresponding to the anomaly type to identify the abnormal electronic control units in the vehicle.

[0093] Specifically, the electronic control units in the vehicle are investigated according to the investigation strategy corresponding to the anomaly type, and the abnormal electronic control units in the vehicle are identified, including:

[0094] Step B201: If the exception type is an inactive, non-dormant state, then read the vehicle's bus data and convert the bus data into a binary data sequence.

[0095] If the cloud determines the anomaly type to be an inactive state without sleep, it first reads the vehicle's controller area network bus data (such as M241 data) in real time through the vehicle terminal (TCAM). After the bus data is transmitted to the cloud in hexadecimal format, the data parsing module is called to convert it into 8 groups of binary data sequences (corresponding to Group1 to Group8 signals).

[0096] For example, if the received hexadecimal data is "0F", it will be "00001111" after conversion to binary, with each bit representing the sleep state indicator of an electronic control unit (ECU). During the conversion process, a CRC check will be performed to ensure data integrity, and a timestamp will be added to mark the data acquisition time, providing an accurate time series for subsequent analysis.

[0097] Step B202: Match each bit in the binary data sequence with the corresponding status signal to obtain the target bit in the non-sleep state in the binary data sequence, and take the electronic control unit corresponding to the target bit as the abnormal electronic control unit. Here, each bit in the binary data sequence corresponds to an electronic control unit, and the status signal is used to indicate whether the electronic control unit is in a sleep state.

[0098] The cloud compares each bit in the binary data sequence with preset status signal rules: if a binary bit is "1", the corresponding ECU has not entered sleep mode (maintains wake-up state); if it is "0", it indicates that it has entered normal sleep mode. Through a predefined mapping table (e.g., bit0 of Group 1 corresponds to the engine control unit, bit1 corresponds to the transmission control unit), it automatically identifies all target bits in the "1" state and marks the corresponding ECUs as candidate abnormal units.

[0099] Subsequently, a logical check is performed based on the vehicle's current operating conditions (e.g., all occupants should be put to sleep if the vehicle is locked for more than 10 minutes). ECUs that are working normally (e.g., the anti-theft system needs to be kept awake) are excluded. Finally, ECUs that do not meet the sleep rules are identified as abnormal electronic control units, and a diagnostic report containing the ECU number, function description, and abnormal duration is generated to provide a precise target for subsequent repairs.

[0100] Step S202: Obtain the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle.

[0101] In this embodiment, after locating the malfunctioning electronic control unit (ECU), a data request command is sent to the ECU via the On-Board Diagnostics (OBD) interface. Upon receiving the command, the ECU transmits its internally stored operating log data (such as fault codes, event timestamps, software operating status, and real-time sensor data) to the vehicle terminal via the controller area network (CLAN) bus.

[0102] The vehicle-mounted terminal encrypts the data (e.g., using the AES-128 algorithm) before uploading it to the cloud via the mobile communication network. Upon receiving the log data, the cloud automatically performs format verification and integrity checks to ensure the data is accurate before storing it in a dedicated database, providing a foundation for subsequent analysis.

[0103] The cloud-based system performs a multi-dimensional evaluation of internal log data: First, it checks for recurring fault codes (e.g., recording the same fault code three times consecutively); if present, it marks them as persistent anomalies. Second, it analyzes the temporal changes of key parameters (e.g., voltage fluctuations during sleep mode switching, signal response delays) to determine if software logic errors exist. Finally, it combines the hardware health score of the electronic control unit (calculated based on parameters such as operating temperature and runtime) to assess whether the fault is caused by a temporary software anomaly or a potential hardware problem. If the analysis results indicate that the anomaly is caused by a transient software error (e.g., signal timeout, memory overflow), and the electronic control unit hardware is normal, it is determined that normal operation can be restored via a reset command.

[0104] If there is a risk of hardware failure or persistent software logic errors, an OTA upgrade or manual repair process will be triggered to avoid unnecessary reset operations. Finally, the analysis results and decision-making basis will be used to generate a diagnostic report for engineers to review and confirm before executing the corresponding instructions.

[0105] Step S203: If it is determined that a reset command will be sent to the vehicle, then check whether the vehicle's status monitoring data has reached the corresponding threshold.

[0106] In this embodiment of the application, if it is determined that a reset command needs to be sent to the vehicle, the vehicle's status monitoring data is first collected in real time through the vehicle terminal.

[0107] Specific detection indicators include: vehicle locking time (must exceed 10 minutes, recorded by the vehicle controller), battery state of charge (SOC must be greater than 40%, provided by the battery management system), battery health score (must be higher than 80 points, calculated based on parameters such as internal resistance and cycle count), mobile communication network signal strength (must be greater than -90dBm), and transmission latency (must be less than 200 milliseconds). The cloud compares this real-time data with preset thresholds. If all indicators meet the standards, a qualified status indicator is generated; if any indicator fails to meet the standards, data changes are continuously monitored and recorded until all thresholds are met or a timeout (e.g., 30 minutes) is triggered, in which case manual intervention is initiated.

[0108] Step S204: When all status monitoring data reach the corresponding threshold, check whether the vehicle has received an unlock command.

[0109] In this embodiment, after confirming that the status monitoring data meets the standards, an unlock command detection mechanism is initiated. A real-time communication channel is established between the vehicle terminal and the remote service platform (TSP) to listen for unlock requests from terminals such as car keys and mobile apps. Since the TSP uploads the unlock command (approximately 1 second) earlier than the physical unlocking execution time of the vehicle (2-3 seconds), the command status can be obtained before the unlocking action is executed. If an unlock command is detected, the vehicle is immediately marked as "pending unlocking," the issuance of reset commands is paused, and the vehicle is kept in the repair list, awaiting reassessment in the next locking cycle. If no unlock command is detected within a preset time window (e.g., 5 minutes), the vehicle is determined to be in a safe state, and a reset operation can be performed.

[0110] In step S205, if the vehicle does not receive an unlock command, the vehicle identifier is removed from the list of vehicles to be repaired, and a reset command is sent to the vehicle.

[0111] In this embodiment, once it is confirmed that the vehicle has not received an unlock command and the status monitoring data meets the requirements, the vehicle identification number (VIN) is automatically removed from the list of vehicles to be repaired, and an encrypted reset command is generated. The command content includes the identifier of the abnormal electronic control unit, the reset type (hard reset or soft reset), and the execution parameters.

[0112] The command is sent to the vehicle terminal via the mobile communication network. Upon receiving the command, the vehicle terminal first verifies the signature and timeliness, and then sends a hard reset signal (e.g., power off and then back on) or a soft reset command (e.g., triggering a watchdog timer) to the malfunctioning electronic control unit via the controller area network bus. After the reset is complete, the electronic control unit reinitializes and enters self-test mode, feeding back the reset result (success / failure) to the vehicle terminal via the CAN bus. The vehicle terminal encrypts and uploads the result to the cloud, while simultaneously recording log information such as reset time and execution status, forming a complete closed-loop control process.

[0113] In this embodiment of the application, the method further includes: if the vehicle receives an unlock command, stopping sending a reset command to the vehicle, and waiting for the vehicle to re-enter the locked state before executing the step of sending a reset command.

[0114] In this embodiment of the application, if the cloud detects that the vehicle has received an unlocking command (such as an unlocking signal from the car key or mobile APP) after the status monitoring data meets the standard, the interruption mechanism is activated: first, the generation or issuance of reset commands is stopped to avoid performing a reset operation when the user uses the vehicle and affecting normal functions; second, the vehicle identification number (VIN) of the vehicle is retained in the list to be repaired and marked as "to be processed next time the car is locked".

[0115] The cloud continuously monitors the vehicle's door lock status. When it detects that the vehicle has re-entered the locked state (confirmed by the door lock signal sent by the body controller), it automatically re-triggers the status monitoring process: re-evaluates threshold conditions such as lock duration, battery state of charge (SOC), and network signal strength. If the conditions are met and no new unlocking command is detected, the reset command sending step is immediately executed to ensure that the repair operation of the abnormal electronic control unit is completed within the sleep cycle that is imperceptible to the user.

[0116] Figure 3 This is a flowchart of a method for repairing abnormal vehicle hibernation according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps:

[0117] Step S301: After sending a reset command to the vehicle, monitor whether the vehicle still experiences abnormal sleep events.

[0118] In this embodiment of the application, after the cloud sends a reset command to the vehicle, it starts a continuous monitoring mechanism: it collects the vehicle's bus data (such as M241 data) and battery status information (such as state of charge SOC and static power consumption QCM) in real time through the vehicle terminal, and analyzes whether the vehicle will experience an abnormal sleep event again.

[0119] Specifically, for inactive states without hibernation, the cloud analyzes the binary sequence in the bus data to check if there is a corresponding "1" bit in the electronic control unit (not hibernating); for deep hibernation states without hibernation, the cloud compares the SOC difference before and after the vehicle enters deep hibernation again to see if it exceeds the normal threshold (e.g., 0.5%). The monitoring period is 72 hours after the reset to ensure coverage of multiple vehicle lock-sleep cycles and fully verify the reset effect.

[0120] In step S302, if the vehicle still experiences abnormal sleep events, the vehicle identifier is added back to the list to be repaired, and the monitoring data of each status is continuously monitored to see if they reach the corresponding thresholds.

[0121] In this embodiment, if an abnormal sleep event is detected after the vehicle is reset, the cloud automatically adds the vehicle's Vehicle Identification Number (VIN) back to the repair list and marks it as "reset failed". Simultaneously, the status monitoring process is restarted: real-time collection of vehicle locking duration (must exceed 10 minutes), battery health data (SOC > 40% and health score > 80 points), network performance data (signal strength > -85dBm and latency < 200 milliseconds), and other status parameters are continuously compared to preset thresholds.

[0122] If the status data meets the requirements, a reset command will be sent again. If the reset fails three times in a row or the status data continues to be unacceptable, a work order will be automatically generated and pushed to the engineer to trigger the manual intervention process. The internal logs of the electronic control unit will be combined to further analyze hardware faults or software logic problems, providing a basis for subsequent OTA upgrades or offline repairs.

[0123] This application effectively improves the accuracy and efficiency of fault handling through a continuous monitoring and dynamic repair mechanism. After sending a reset command, it continuously monitors abnormal vehicle sleep events to promptly verify the reset effect, preventing recurring problems due to incomplete repairs and overcoming the drawbacks of traditional solutions where faults are difficult to eradicate. If an anomaly occurs again, the vehicle identifier is automatically added back to the repair list, and status data thresholds are continuously monitored to ensure that secondary repairs are initiated only when the vehicle meets conditions such as lock duration, battery level, and network signal strength. This prevents invalid operations and avoids interfering with normal user operation. The entire process requires no repeated manual intervention, achieving fully automated closed-loop management of the fault repair process, significantly reducing repair costs, and meeting the needs for low-power management and rapid repair of vehicles with complex electronic and electrical architectures.

[0124] Figure 4 This is a flowchart of a method for repairing abnormal vehicle hibernation according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps:

[0125] Step S401: When an abnormal sleep event is detected in the vehicle, locate the abnormal electronic control unit in the vehicle.

[0126] In this embodiment, the abnormality type is automatically distinguished based on the bus data (such as M241 data) and battery status information uploaded by the vehicle terminal. If it is an inactive state and not in sleep mode, the hexadecimal value in the bus data is converted into a binary sequence. By matching the preset mapping relationship between 8 groups of signals (group 1 to group 8) and the sleep state of the electronic control unit, the abnormal electronic control unit with a binary bit of "1" (representing not in sleep mode) is directly located.

[0127] If the vehicle is in a deep sleep state but not in sleep mode, the cloud will automatically send a wake-up command to switch the vehicle to an inactive state because the vehicle terminal is in a sleep state and cannot upload data. The cloud will read the static power consumption data automatically recorded by each electronic control unit when it enters deep sleep and compare the difference in battery state of charge before and after wake-up. When the static power consumption of a certain electronic control unit exceeds a preset threshold and is significantly correlated with the difference in state of charge, it is determined to be an abnormal component, thereby completing the location of the abnormal electronic control unit.

[0128] Step S402: Obtain the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle.

[0129] In this embodiment, after locating the malfunctioning electronic control unit (ECU), a data request command is sent to the ECU via the On-Board Diagnostics (OBD) interface. Upon receiving the command, the ECU transmits its internally stored operating log data (such as fault codes, event timestamps, software operating status, and real-time sensor data) to the vehicle terminal via the controller area network (CLAN) bus.

[0130] The vehicle-mounted terminal encrypts the data (e.g., using the AES-128 algorithm) before uploading it to the cloud via the mobile communication network. Upon receiving the log data, the cloud automatically performs format verification and integrity checks to ensure the data is accurate before storing it in a dedicated database, providing a foundation for subsequent analysis.

[0131] The cloud-based system performs a multi-dimensional evaluation of internal log data: First, it checks for recurring fault codes (e.g., recording the same fault code three times consecutively); if present, it marks them as persistent anomalies. Second, it analyzes the temporal changes of key parameters (e.g., voltage fluctuations during sleep mode switching, signal response delays) to determine if software logic errors exist. Finally, it combines the hardware health score of the electronic control unit (calculated based on parameters such as operating temperature and runtime) to assess whether the fault is caused by a temporary software anomaly or a potential hardware problem. If the analysis results indicate that the anomaly is caused by a transient software error (e.g., signal timeout, memory overflow), and the electronic control unit hardware is normal, it is determined that normal operation can be restored via a reset command.

[0132] If there is a risk of hardware failure or persistent software logic errors, an OTA upgrade or manual repair process will be triggered to avoid unnecessary reset operations. Finally, the analysis results and decision-making basis will be used to generate a diagnostic report for engineers to review and confirm before executing the corresponding instructions.

[0133] Step S403: If it is determined that a reset command will not be sent to the vehicle, then obtain the system update data packet corresponding to the internal log data;

[0134] In this embodiment, if the cloud analyzes the internal log data and determines that the anomaly cannot be resolved by resetting (e.g., due to persistent software logic errors or version defects), a system update data package matching the model and software version of the abnormal electronic control unit is automatically retrieved from the cloud database. This data package contains the code patches, configuration files, or complete firmware required to fix the anomaly, and compatibility with the vehicle's existing system is ensured through a version comparison algorithm.

[0135] Simultaneously, the digital signature of the data packet is verified (using the SHA-256 hash algorithm and RSA asymmetric encryption) to ensure its integrity and security. If multiple update versions are available, the cloud will intelligently select the optimal version based on parameters such as the vehicle's usage region and hardware configuration, and generate an upgrade task order that includes a description of the update content and an estimated time consumption.

[0136] Step S404: Push system update data package to the vehicle, whereby the vehicle uses the system update data package to repair the malfunctioning electronic control unit.

[0137] In this embodiment, the cloud pushes system update data packets to the vehicle terminal via a mobile communication network, employing a breakpoint resume mechanism to ensure transmission reliability. Before pushing, the cloud checks the vehicle status: confirming that the vehicle has been locked for more than 10 minutes, the battery SOC is greater than 30%, and the network signal strength is greater than -85dBm. After the data packet arrives at the vehicle terminal, it first undergoes integrity verification (calculating the MD5 hash value and comparing it with the cloud data), and then stores it in a dedicated partition of the vehicle's storage device. When the vehicle starts up again, the electronic control unit automatically executes the update program, completing code replacement, configuration updates, or firmware upgrades according to predetermined steps, and performs a self-check. After the update is completed, the vehicle terminal feeds back the execution result (success / failure) and the updated software version information to the cloud. The cloud records the update log and marks the vehicle's abnormal status as resolved, forming a complete OTA upgrade closed-loop management.

[0138] This application's embodiments, through real-time monitoring of abnormal sleep events, can promptly capture intermittent faults, solving the problem of difficulty in fault reproduction; by acquiring and analyzing the internal log data of the abnormal electronic control unit, it accurately determines whether to perform a reset or push a system update data package, significantly improving repair efficiency. It eliminates the need for user offline repair requests and manual intervention, reducing maintenance costs and achieving a fully automated closed-loop process from fault location to repair. For complex electronic and electrical architectures, it flexibly adopts reset or system update strategies based on the fault type, completing the repair when the vehicle meets low-power management conditions, ensuring both power safety during vehicle sleep and rapid fault handling.

[0139] This embodiment also provides a vehicle abnormal sleep repair device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as described thereon. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0140] This embodiment provides a repair device for abnormal vehicle hibernation, such as... Figure 5 As shown, it includes:

[0141] Detection module 501 is used to locate the abnormal electronic control unit in the vehicle when an abnormal sleep event is detected in the vehicle;

[0142] The acquisition module 502 is used to acquire the internal log data corresponding to the abnormal electronic control unit and analyze the internal log data to determine whether to send a reset command to the vehicle.

[0143] Analysis module 503 is used to detect vehicle status monitoring data if it is determined that a reset command will be sent to the vehicle.

[0144] The sending module 504 is used to send a reset command to the vehicle when the status monitoring data reaches the corresponding threshold, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

[0145] In this embodiment, the detection module 501 is used to obtain the abnormal type corresponding to the abnormal sleep event; and to investigate the electronic control unit in the vehicle according to the investigation strategy corresponding to the abnormal type, so as to obtain the abnormal electronic control unit in the vehicle.

[0146] In this embodiment, the detection module 501 is used to send a wake-up command to the vehicle's on-board terminal if the abnormality type is a deep sleep state or non-sleep state. The on-board terminal is used to switch the vehicle's entire network to an inactive state according to the wake-up command. When the vehicle's entire network is in an inactive state, the module reads the static power consumption data of all electronic control units in the vehicle and the difference in the state of charge of the vehicle's battery before and after wake-up. The module compares the static power consumption data with a preset power consumption threshold, and selects the electronic control units whose static power consumption data is greater than or equal to the preset power consumption threshold as candidate electronic control units. The module also selects the candidate electronic control units whose static power consumption data is correlated with the difference in the state of charge as abnormal electronic control units.

[0147] In this embodiment, the detection module 501 is used to read the vehicle's bus data and convert the bus data into a binary data sequence if the abnormality type is an inactive, non-dormant state. Each bit in the binary data sequence is matched with the corresponding status signal to obtain the target bit in the non-dormant state in the binary data sequence, and the electronic control unit corresponding to the target bit is taken as the abnormal electronic control unit. Each bit in the binary data sequence corresponds to an electronic control unit, and the status signal is used to indicate whether the electronic control unit is in a dormant state.

[0148] In this embodiment, the analysis module 503 is used to obtain a list of abnormal electronic control units to be repaired; obtain various status monitoring data of the vehicle, including vehicle locking duration, battery health data, and network performance data; add the vehicle identifier to the list of units to be repaired; and monitor in real time whether each status monitoring data reaches the corresponding threshold.

[0149] In this embodiment of the application, the sending module 504 is used to detect whether the vehicle has received an unlocking command when all status monitoring data reach the corresponding threshold; if the vehicle has not received an unlocking command, the vehicle identifier is removed from the list to be repaired and a reset command is sent to the vehicle.

[0150] In this embodiment of the application, the device further includes: a monitoring module, configured to stop sending a reset command to the vehicle if the vehicle receives an unlock command, and wait for the vehicle to re-enter the locked state before executing the step of sending a reset command.

[0151] In this embodiment of the application, the device further includes: a monitoring module, used to monitor whether the vehicle still experiences abnormal sleep events; if the vehicle still experiences abnormal sleep events, the vehicle identifier is added back to the list to be repaired, and the monitoring data of each status is continuously monitored to see if they reach the corresponding threshold.

[0152] In this embodiment of the application, the device further includes: a push module, configured to, if it is determined that no reset command will be sent to the vehicle, obtain a system update data packet corresponding to the internal log data; and push the system update data packet to the vehicle, wherein the vehicle is used to repair the abnormal electronic control unit according to the system update data packet.

[0153] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0154] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0155] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0156] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0157] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0158] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0159] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0160] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for repairing abnormal vehicle hibernation, characterized in that, The method includes: When an abnormal sleep event is detected in the vehicle, the abnormal electronic control unit in the vehicle is located; Obtain the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle; If the reset command is sent to the vehicle, then it is checked whether the vehicle's status monitoring data has reached the corresponding threshold. When the status monitoring data reaches the corresponding threshold, a reset command is sent to the vehicle, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

2. The method according to claim 1, characterized in that, The method for locating the abnormal electronic control unit in the vehicle includes: Obtain the exception type corresponding to the abnormal sleep event; The electronic control units in the vehicle are investigated according to the investigation strategy corresponding to the anomaly type to identify the abnormal electronic control units in the vehicle.

3. The method according to claim 2, characterized in that, The step of investigating the electronic control unit in the vehicle according to the investigation strategy corresponding to the anomaly type to obtain the abnormal electronic control unit in the vehicle includes: If the abnormality type is a deep sleep state without sleep type, a wake-up command is sent to the vehicle's on-board terminal, wherein the on-board terminal is used to switch the vehicle's entire network to an inactive state according to the wake-up command, wherein the deep sleep state without sleep type is used to indicate that the vehicle is unable to enter deep sleep mode due to system failure, special function activation or external device connection. When the vehicle's network is inactive, read the static power consumption data of all electronic control units in the vehicle, as well as the difference in state of charge of the vehicle's battery before and after wake-up. By comparing the static power consumption data with a preset power consumption threshold, electronic control units whose static power consumption data is greater than or equal to the preset power consumption threshold are selected as candidate electronic control units, and candidate electronic control units whose static power consumption data is correlated with the difference in state of charge are selected as abnormal electronic control units.

4. The method according to claim 2, characterized in that, The step of investigating the electronic control unit in the vehicle according to the investigation strategy corresponding to the anomaly type to obtain the abnormal electronic control unit in the vehicle includes: If the abnormality type is the inactive state non-sleep type, then the bus data of the vehicle is read and the bus data is converted into a binary data sequence. The inactive state non-sleep type is used to characterize that the vehicle is waiting for user operation, the system self-test has not been completed, or the vehicle has not entered a relatively static sleep state due to environmental perception requirements. Each bit in the binary data sequence is matched with its corresponding status signal to obtain the target bit in the binary data sequence that is in a non-sleep state. The electronic control unit corresponding to the target bit is then used as the abnormal electronic control unit. Each bit in the binary data sequence corresponds to one electronic control unit, and the status signal is used to indicate whether the electronic control unit is in a sleep state.

5. The method according to claim 1, characterized in that, The detection of whether the vehicle's status monitoring data reaches the corresponding threshold includes: Obtain the list of devices to be repaired corresponding to the malfunctioning electronic control unit; Acquire various status monitoring data of the vehicle, including vehicle locking duration, battery health data, and network performance data; The vehicle identifier of the vehicle is added to the list of vehicles to be repaired, and the status monitoring data of each status are monitored in real time to see if they reach the corresponding threshold.

6. The method according to claim 5, characterized in that, When the status monitoring data reaches a corresponding threshold, a reset command is sent to the vehicle, including: When all status monitoring data reach the corresponding threshold, check whether the vehicle has received an unlock command. If the vehicle does not receive the unlock command, the vehicle's vehicle identifier is removed from the list of vehicles to be repaired, and a reset command is sent to the vehicle.

7. The method according to claim 6, characterized in that, The method further includes: If the vehicle receives the unlock command, then stop sending reset commands to the vehicle, and wait for the vehicle to re-enter the locked state before executing the step of sending reset commands.

8. The method according to claim 5, characterized in that, After sending a reset command to the vehicle, the method further includes: Detect whether the vehicle is still experiencing abnormal sleep events; If the vehicle still experiences abnormal sleep events, the vehicle identifier will be added back to the list of vehicles to be repaired, and the status monitoring data will be continuously monitored to see if they reach the corresponding thresholds.

9. The method according to claim 1, characterized in that, The method further includes: If it is determined that the reset command will not be sent to the vehicle, then the system update data packet corresponding to the internal log data is obtained; The system update data package is pushed to the vehicle, wherein the vehicle is used to repair the malfunctioning electronic control unit according to the system update data package.

10. A repair device for abnormal vehicle hibernation, characterized in that, The device includes: The detection module is used to locate the abnormal electronic control unit in the vehicle when an abnormal sleep event is detected in the vehicle. The acquisition module is used to acquire the internal log data corresponding to the abnormal electronic control unit, and analyze the internal log data to determine whether to send a reset command to the vehicle. An analysis module is used to detect the vehicle's status monitoring data if the reset command is sent to the vehicle. The sending module is used to send a reset command to the vehicle when the status monitoring data reaches a corresponding threshold, wherein the vehicle is used to perform a reset operation of the abnormal electronic control unit according to the reset command.

Images