Methods, devices, electronic equipment, and vehicles for handling frequent wake-up faults.

Abstract

This application provides a method, apparatus, electronic device, and vehicle for handling frequent wake-up faults. After the vehicle is powered off, the number of abnormal wake-ups of the body domain controller is determined. The abnormal wake-up severity value is determined by calculating the ratio of the abnormal wake-up number to a preset rated number. The fault level is determined by comparing the abnormal wake-up severity value with a preset fault level threshold. The abnormal wake-up severity value is chosen as the criterion for judging the fault level, rather than the number of abnormal wake-ups, because different vehicles have different situations. Choosing the relative variable abnormal wake-up severity value can adapt to the judgment of the level of frequent wake-up faults in different vehicles. After the fault level is determined, a corresponding handling method is determined according to different fault levels. Graded fault handling can more effectively deal with frequent wake-up faults and obtain more detailed handling results, thereby reducing the power consumption of the vehicle during static parking and extending the service life of vehicle electronic components.

Description

Technical Field

[0001] This application relates to the field of vehicle fault handling technology, and in particular to a method, apparatus, electronic device, and vehicle for handling frequent wake-up faults. Background Technology

[0002] With the development of vehicle intelligence and informatization, the number of in-vehicle electronic controllers is constantly increasing, leading to an increase in the overall power consumption of the vehicle. When the vehicle is in an abnormal state, after the entire vehicle is powered down, it may be woken up for various reasons during static parking. During static parking, the vehicle is powered only by the in-vehicle battery. Each wake-up will cause some in-vehicle electronic controllers to continue working for a period of time before they can go into hibernation. Frequent wake-ups will inevitably cause battery depletion, resulting in problems such as the vehicle being unable to start, electronic controller malfunctions, shortened battery life, or battery damage. Therefore, in order to reduce the power consumption of the entire vehicle during static parking and extend the service life of vehicle electronic components, it is urgent to address the frequent wake-up fault of vehicles. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a method, apparatus, electronic device and vehicle for handling frequent wake-up faults, so as to solve the above-mentioned problems.

[0004] To achieve the above objectives, the first aspect of this application provides a method for handling frequent wake-up faults, comprising:

[0005] In response to a vehicle power failure, determine the number of abnormal wake-ups of the body domain controller;

[0006] The abnormal wake-up severity value is determined based on the number of abnormal wake-ups and the preset rated number.

[0007] The fault level is determined based on the abnormal wake-up level value and the preset fault level threshold.

[0008] The corresponding processing is carried out based on the fault level.

[0009] Optionally, the fault level threshold includes a first threshold, a second threshold, and a third threshold that increase sequentially;

[0010] The step of determining the fault level based on the abnormal wake-up level value and a preset fault level threshold includes:

[0011] In response to the abnormal wake-up level value being greater than the first threshold and less than or equal to the second threshold, the fault level is determined to be a low-level fault and the corresponding first fault code is determined; or...

[0012] In response to the abnormal wake-up level value being greater than the second threshold and less than or equal to the third threshold, the fault level is determined to be a medium-level fault and the corresponding second fault code is determined; or...

[0013] In response to the abnormal wake-up level value being greater than the third threshold, the fault level is determined as a high-level fault and the corresponding third fault code is determined.

[0014] Optionally, determining the fault level based on the abnormal wake-up level value and a preset fault level threshold further includes:

[0015] If the abnormal wake-up level value is less than or equal to the first threshold, it is determined that there is no frequent wake-up fault.

[0016] Optionally, the corresponding processing based on the fault level includes:

[0017] In response to the fault level being the low-level fault, the first fault code is sent to the memory for storage; or,

[0018] In response to the fault level being the intermediate fault, the second fault code is sent to the memory for storage, the remote communication terminal is woken up, and a first alarm message is sent to the user terminal through the remote communication terminal; or;

[0019] In response to the fault level being the high-level fault, the third fault code is sent to the memory for storage, the DC-DC converter and the remote communication terminal are woken up, the battery of the vehicle domain controller is charged through the DC-DC converter, and a second alarm message is sent to the user terminal through the remote communication terminal.

[0020] Alternatively, methods for handling frequent wake-up failures may also include:

[0021] In response to the battery voltage reaching a preset voltage threshold, charging of the battery is stopped.

[0022] Alternatively, methods for handling frequent wake-up failures may also include:

[0023] After the vehicle is powered on, the number of abnormal wake-ups is reset to zero, and the abnormal wake-up level value is deleted.

[0024] A second aspect of this application provides a processing apparatus for frequent wake-up faults, comprising:

[0025] The counting module is configured to determine the number of abnormal wake-ups of the body domain controller in response to a vehicle power-down.

[0026] The calculation module is configured to: determine the abnormal wake-up level value based on the number of abnormal wake-ups and the preset rated number;

[0027] The fault level determination module is configured to determine the fault level based on the abnormal wake-up degree value and a preset fault level threshold.

[0028] The processing module is configured to perform corresponding processing based on the fault level.

[0029] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method provided in the first aspect of this application.

[0030] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method provided in the first aspect of this application.

[0031] The fifth aspect of this application provides a vehicle including a frequent wake-up fault processing device as described in the second aspect of this application, an electronic device as described in the third aspect of this application, or a computer-readable storage medium as described in the fourth aspect of this application.

[0032] As can be seen from the above, the frequent wake-up fault handling method, device, electronic equipment, and vehicle provided in this application determine the number of abnormal wake-ups of the body domain controller after the vehicle is powered off. Then, the abnormal wake-up severity value is determined by calculating the ratio of the abnormal wake-up number to the preset rated number. The fault level is determined by comparing the abnormal wake-up severity value with the preset fault level threshold. The abnormal wake-up severity value is selected as the criterion for judging the fault level, rather than the number of abnormal wake-ups, because different vehicles have different situations. Choosing the relative variable abnormal wake-up severity value can adapt to the level judgment of frequent wake-up faults in different vehicles. After the fault level is determined, the corresponding handling method is determined according to the different fault levels. Graded fault handling can more effectively deal with frequent wake-up faults and obtain more detailed handling results, thereby reducing the power consumption of the vehicle during static parking and extending the service life of vehicle electronic components. Attached Figure Description

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

[0034] Figure 1 This is a flowchart of a method for handling frequent wake-up faults according to an embodiment of this application;

[0035] Figure 2 A flowchart for determining the fault level in the embodiments of this application;

[0036] Figure 3 This is a flowchart illustrating the fault handling process in an embodiment of this application.

[0037] Figure 4 This is a schematic diagram of the structure of the device for handling frequent wake-up faults according to an embodiment of this application;

[0038] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0040] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0041] A counter is set up inside the vehicle domain controller. After the vehicle is powered off and the network is in normal sleep mode, each time the Electronic Control Unit (ECU) is woken up due to local reasons (including being woken up by LIN slave nodes; any wake-up source that requires the vehicle to be woken up through the ECU is considered a local ECU reason), various wake-up sources will actively wake up the ECU, and then wake up other electronic controls. Each time it is woken up, the counter counts once (Counter = 1; when there is no wake-up, Counter = 0 by default). When the cumulative count reaches a preset threshold, the data logging function is triggered, and the counting stops, storing the fault code for later troubleshooting. However, limiting the number of times a fault is used is not adaptable to different vehicles, has low universality, and the single method of storing fault codes is too crude and cannot provide a clear understanding of the fault. When the cumulative count is close to but does not exceed the threshold, data logging is not triggered, which delays the repair time for frequent vehicle wake-up faults.

[0042] The frequent wake-up fault handling method, apparatus, electronic device, and vehicle provided in this application embodiment determine the number of abnormal wake-ups of the body domain controller after the vehicle is powered off. Then, the abnormal wake-up severity value is determined by calculating the ratio of the abnormal wake-up number to a preset rated number. The fault level is determined by comparing the abnormal wake-up severity value with a preset fault level threshold. The abnormal wake-up severity value is chosen as the criterion for judging the fault level, rather than the number of abnormal wake-ups, because different vehicles have different situations. Choosing the relative variable abnormal wake-up severity value can adapt to the level judgment of frequent wake-up faults in different vehicles. No matter how the rated number changes, it will not affect the fault level judgment, making it more universal. After the fault level is determined, a corresponding handling method is determined according to different fault levels. Graded fault handling can more effectively deal with frequent wake-up faults and obtain more detailed processing results. This reduces the power consumption of the vehicle during static parking and extends the service life of vehicle electronic components. When the fault level is low, a fault code is recorded. When the fault level is high, the user is reminded while recording the fault code, and even the battery is charged to ensure that the vehicle can be woken up normally.

[0043] In some embodiments, such as Figure 1 As shown, the methods for handling frequent wake-up faults include:

[0044] Step 100: In response to the vehicle power failure, determine the number of abnormal wake-ups of the body domain controller.

[0045] In this step, when the vehicle is powered off and the body domain controller is in sleep mode, a counter set inside the body domain controller is woken up. Each time the wake-up source actively wakes up the body domain controller, a count is performed. The counter stores the accumulated number of abnormal wake-up counts in the memory of the body domain controller. The abnormal wake-up count data stored in the body domain controller will not be lost after the vehicle is powered off or the battery is de-energized. After the wake-up source actively wakes up the body domain controller again, the count is incremented based on the previous value. After any vehicle is powered on (when the user actively starts the vehicle), the abnormal wake-up count of the counter is reset. After the reset, the abnormal wake-up count data inside the counter is zero.

[0046] Step 200: Determine the abnormal wake-up level value based on the number of abnormal wake-ups and the preset number of times.

[0047] In this step, a higher abnormal wake-up level value indicates a higher degree of fault, and for the same vehicle, it means more abnormal wake-ups. For example, during the period from vehicle power-down to the next vehicle power-on, if the counter records n abnormal wake-ups and the preset rated number is N, then the abnormal wake-up level value is calculated according to the formula K = n / N * 100%. The abnormal wake-up level value is chosen as the criterion for judging the fault level, rather than the number of abnormal wake-ups, because different vehicles have different situations. Choosing the relative variable abnormal wake-up level value can adapt to the judgment of frequent wake-up fault levels in different vehicles. Regardless of how the rated number changes, it will not affect the fault level judgment, making it more universal.

[0048] Step 300: Determine the fault level based on the abnormal wake-up level value and the preset fault level threshold.

[0049] In this step, for example, when the second threshold ≥ the abnormal wake-up level value K > the first threshold, it indicates that the abnormal wake-up of the vehicle domain controller is not very frequent and belongs to a mild fault. Therefore, the fault level is set as a low-level fault, and the fault code corresponding to the low-level fault is determined. For example, the first threshold can be 20%, and the second threshold can be 50%. When the third threshold ≥ the abnormal wake-up level value K > the second threshold, it indicates that the abnormal wake-up of the vehicle domain controller is relatively frequent and belongs to a moderate fault. Therefore, the fault level is set as a medium-level fault, and the fault code corresponding to the medium-level fault is determined. The third threshold can be 70%. When the abnormal wake-up level value K > the third threshold, it indicates that the abnormal wake-up of the vehicle domain controller is very frequent, and each wake-up will cause some electronic controllers in the vehicle to continue to work for a period of time before they can go into hibernation. Frequent wake-ups will inevitably cause the battery to run out of power, resulting in many problems such as the vehicle not being able to start, electronic controller failure, shortened battery life or damage. This belongs to a severe fault, so the fault level is set as a high-level fault, and the fault code corresponding to the high-level fault is determined.

[0050] Step 400: Perform corresponding processing based on the fault level.

[0051] In this step, for example, different handling strategies are used for different fault levels:

[0052] When the fault level is determined to be low, the corresponding fault code is stored in the electrically erasable programmable read-only memory (EEPROM). When the fault level is determined to be medium, the telematics box (TBOX) is activated, and an alarm message is sent to the user via the TBOX: "Your vehicle is frequently waking up, please check!" When the fault level is determined to be high, the direct current converter (DC-DC) and the TBOX are activated, and the battery is charged via the DC-DC converter (automatically cutting off power when it reaches 12V). An alarm message is also sent to the user via the TBOX: "Your vehicle is seriously waking up, please check!"

[0053] In this embodiment, after the fault level is determined, a corresponding processing method is determined according to different fault levels. This tiered fault handling allows for more targeted treatment of frequent wake-up faults. When abnormal wake-ups are not frequent, the power consumption caused by abnormal wake-ups is small, and the impact on the lifespan of electronic components is also small. In this case, the corresponding fault code can be stored for analysis of the fault cause during subsequent maintenance. When abnormal wake-ups are relatively frequent, although they do not affect the normal wake-up function, the power consumption caused by abnormal wake-ups is large, and the impact on the lifespan of electronic components is also significant. In this case, while storing the corresponding fault code for analysis of the fault cause during subsequent maintenance, the user is also informed... An alarm message is sent to inform the user that the vehicle has a serious frequent wake-up fault, prompting the user to repair the fault as soon as possible to prevent the fault level from escalating. When abnormal wake-ups are very frequent, the power consumption caused by abnormal wake-ups can be very high, which may lead to severe battery depletion of the battery used to wake up the body domain controller, thus affecting the normal wake-up function and significantly impacting the lifespan of electronic controls. In this case, while storing fault codes and sending alarm messages to the user, the battery is charged through the wake-up DC-DC converter (automatically cutting off power when it reaches 12V) to ensure that the battery used to wake up the body domain controller does not fail to wake up the controller due to depletion. Through different and more detailed handling methods, the power consumption of the entire vehicle during static parking is reduced and the lifespan of vehicle electronic components is extended. Fault codes are recorded when the fault level is low, and when the fault level is high, fault codes are recorded while user reminders are sent, and even battery charging is performed to ensure that the vehicle can wake up normally, thus effectively handling frequent wake-up faults.

[0054] In some embodiments, the fault level threshold includes a first threshold, a second threshold, and a third threshold that increase sequentially; the greater the number of abnormal wake-ups, the greater the abnormal wake-up severity value. Figure 2 As shown, the fault level is determined based on the abnormal wake-up level value and the preset fault level threshold, including:

[0055] Step 310: In response to an abnormal wake-up level value that is greater than the first threshold and less than or equal to the second threshold, the fault level is determined to be a low-level fault and the corresponding first fault code is determined.

[0056] In this step, for example, let the first threshold be 20% and the second threshold be 50%. When the abnormal wake-up level value is greater than the first threshold and less than or equal to the second threshold, that is, when the abnormal wake-up level value 50% ≥ K > 20%, it means that the abnormal wake-up of the vehicle domain controller is not very frequent, the power consumption caused by the abnormal wake-up is small, and the impact on the life of the electronic control is also small. It belongs to a minor fault, so the fault level is set as a low-level fault.

[0057] Step 320: In response to the abnormal wake-up level value being greater than the second threshold and less than or equal to the third threshold, the fault level is determined to be a medium fault and the corresponding second fault code is determined.

[0058] In this step, for example, the third threshold is set to 70%. When the abnormal wake-up level value is greater than the second threshold and less than or equal to the third threshold, that is, when the abnormal wake-up level value 70% ≥ K > 50%, it indicates that the abnormal wake-up of the vehicle domain controller is relatively frequent and has a greater impact on the lifespan of the electronic control, but it will not affect the normal wake-up function. It belongs to a moderate fault, so the fault level is set as a medium fault.

[0059] Step 330: In response to the abnormal wake-up level value being greater than the third threshold, the fault level is determined to be a high-level fault and the corresponding third fault code is determined.

[0060] In this step, for example, when the abnormal wake-up level value is greater than the third, that is, when the abnormal wake-up level value K>70%, it means that the abnormal wake-up of the vehicle domain controller is very frequent and has a significant impact on the lifespan of the electronic control. The power consumption caused by the abnormal wake-up will be very large, which may lead to severe battery depletion of the battery used to wake up the vehicle domain controller, thereby affecting the normal wake-up function. This is a serious fault, so the fault level is set as a high-level fault.

[0061] Optionally, the first, second, and third fault codes corresponding to different fault levels can be pre-set. When the fault level is determined to be low, the first fault code is selected and sent to the memory for storage; when the fault level is determined to be medium, the second fault code is selected and sent to the memory for storage; and when the fault level is determined to be high, the third fault code is selected and sent to the memory for storage. Optionally, the first, second, and third fault codes corresponding to different fault levels can be generated after the fault level is determined. When the fault level is determined to be low, the first fault code is generated and sent to the memory for storage; when the fault level is determined to be medium, the second fault code is generated and sent to the memory for storage; and when the fault level is determined to be high, the third fault code is generated and sent to the memory for storage. When repairing frequent wake-up faults, maintenance personnel need to retrieve the first, second, or third fault code from the memory to determine the fault level and possible causes of the fault, which helps maintenance personnel quickly locate the fault level, improve maintenance efficiency, and save maintenance time.

[0062] In some embodiments, determining the fault level based on the abnormal wake-up level value and a preset fault level threshold further includes:

[0063] If the abnormal wake-up level value is less than or equal to the first threshold, it is determined that there is no frequent wake-up fault.

[0064] For example, if the first threshold is 20%, when the abnormal wake-up degree value is less than or equal to the first threshold, that is, when the abnormal wake-up degree value 20% ≥ K ≥ 0, it means that the number of abnormal wake-ups of the vehicle domain controller is very small, the power consumption caused by abnormal wake-ups is negligible, and the impact on the lifespan of electronic controls is also very small. It can be determined that there is no frequent wake-up fault.

[0065] In some embodiments, such as Figure 3 As shown, corresponding processing is carried out based on the fault level, including:

[0066] Step 410: In response to a low-level fault, the first fault code is sent to the memory for storage.

[0067] In this step, for example, when the abnormal wake-up level value is 50% ≥ K > 20%, and the fault level is determined to be a low-level fault, the first fault code is sent to the memory for storage so that the cause of the fault can be analyzed during subsequent maintenance.

[0068] Step 420: In response to the fault level being medium, the second fault code is sent to the memory for storage, the remote communication terminal is woken up, and the first alarm prompt information is sent to the user terminal through the remote communication terminal.

[0069] In this step, for example, when the abnormal wake-up level value is 70% ≥ K > 50%, and the fault level is determined to be a medium fault, it means that the abnormal wake-up of the vehicle domain controller is relatively frequent and has a significant impact on the lifespan of electronic controls, but it does not affect the normal wake-up function. This is a medium fault. At this time, while sending the corresponding second fault code to the memory for storage to analyze the cause of the fault during subsequent maintenance, the remote communication terminal is woken up, and the first alarm prompt information is sent to the user terminal through the remote communication terminal to inform the user that the vehicle has a relatively serious frequent wake-up fault, so that the user can repair the fault as soon as possible and avoid the fault level from escalating.

[0070] Step 430: In response to a high-level fault, the third fault code is sent to the memory for storage, the DC-DC converter and the remote communication terminal are woken up, the battery of the vehicle domain controller is charged through the DC-DC converter, and the second alarm message is sent to the user terminal through the remote communication terminal.

[0071] In this step, for example, when the abnormal wake-up level value K > 70%, the fault level is determined to be a high-level fault. This indicates that the abnormal wake-up of the vehicle domain controller is very frequent and has a significant impact on the lifespan of electronic controls. The power consumption caused by abnormal wake-up will be very high, which may lead to severe battery depletion of the battery used to wake up the vehicle domain controller, thereby affecting the normal wake-up function. At this time, while sending alarm prompt information to the user through the wake-up remote communication terminal and storing the third fault code, the battery is charged through the wake-up DC converter (automatically disconnected when charged to 12V) to ensure that the battery used to wake up the vehicle domain controller will not fail to wake up the vehicle domain controller normally due to battery depletion.

[0072] In some embodiments, the method for handling frequent wake-up faults further includes:

[0073] When the battery voltage reaches a preset voltage threshold, charging of the battery is stopped.

[0074] When a high-level fault is identified and the battery used to wake up the body domain controller is being charged, charging needs to be stopped according to a preset voltage threshold. Before the voltage threshold is reached, the battery may be severely depleted and unable to wake up the body domain controller properly. When the battery voltage reaches the charging threshold of 12V, it can be guaranteed that the battery can wake up the body domain controller. Continuing to charge will only increase the vehicle's energy consumption. Therefore, the power is automatically cut off when the voltage reaches 12V, stopping the charging of the battery, saving energy while ensuring the normal wake-up function.

[0075] In some embodiments, the method for handling frequent wake-up faults further includes:

[0076] In response to the vehicle power-on, the number of abnormal wake-ups is reset to zero, and the abnormal wake-up level value is deleted.

[0077] In order to avoid data interference between different vehicle power-offs, when the vehicle is powered on, i.e. the user actively wakes up the body domain controller, the number of abnormal wake-up counts recorded by the counter is reset to zero, and the calculated abnormal wake-up level value is deleted, so as to ensure that the fault level determination after the next vehicle power-off will not be affected by the fault judgment data of this time.

[0078] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0079] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0080] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a device for handling frequent wake-up faults.

[0081] refer to Figure 4 The frequent wake-up fault processing device includes:

[0082] The counting module 10 is configured to: determine the number of abnormal wake-ups of the body domain controller in response to a power-down of the vehicle;

[0083] The calculation module 20 is configured to determine the abnormal wake-up level value based on the number of abnormal wake-ups and the preset rated number.

[0084] The fault level determination module 30 is configured to determine the fault level based on the abnormal wake-up degree value and the preset fault level threshold.

[0085] Processing module 40 is configured to perform corresponding processing based on the fault level.

[0086] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0087] The apparatus of the above embodiments is used to implement the corresponding frequent wake-up fault handling method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0088] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the frequent wake-up fault handling method described in any of the above embodiments.

[0089] Figure 5This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0090] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0091] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0092] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0093] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0094] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0095] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0096] The electronic devices described above are used to implement the corresponding frequent wake-up fault handling methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0097] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a computer-readable storage medium storing computer instructions for causing the computer to execute the frequent wake-up fault handling method as described in any of the above embodiments.

[0098] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0099] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the frequent wake-up fault handling method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0100] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a vehicle, including a frequent wake-up fault processing device as described in the above embodiments, an electronic device as described in the above embodiments, or a computer-readable storage medium as described in the above embodiments.

[0101] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0102] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0103] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0104] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for handling frequent wake-up faults, characterized in that, The method comprises the following steps: determining the number of abnormal wake-ups of the body domain controller in response to the vehicle being powered off; determining an abnormal wake-up degree value according to the number of abnormal wake-ups and a preset rated number; wherein the abnormal wake-up degree value is the ratio of the number of abnormal wake-ups to the rated number; determining a fault level according to the abnormal wake-up degree value and a preset fault level threshold; performing corresponding processing based on the fault level; wherein the corresponding processing based on the fault level comprises: in response to the fault level being a low-level fault, generating a first fault code and sending the first fault code to a memory for storage; or, in response to the fault level being a medium-level fault, generating a second fault code, sending the second fault code to the memory for storage, waking up a remote communication terminal, and sending a first alarm prompt information to a user terminal through the remote communication terminal; or; in response to the fault level being a high-level fault, generating a third fault code, sending the third fault code to the memory for storage, waking up a direct current converter and the remote communication terminal, charging a battery of the body domain controller through the direct current converter, and sending a second alarm prompt information to the user terminal through the remote communication terminal.

2. The method of claim 1, wherein, The fault level threshold comprises a first threshold, a second threshold, and a third threshold that increase in turn; determining a fault level according to the abnormal wake-up degree value and a preset fault level threshold comprises: in response to the abnormal wake-up degree value being greater than the first threshold and less than or equal to the second threshold, determining the fault level as a low-level fault and determining a corresponding first fault code; or, in response to the abnormal wake-up degree value being greater than the second threshold and less than or equal to the third threshold, determining the fault level as a medium-level fault and determining a corresponding second fault code; or, in response to the abnormal wake-up degree value being greater than the third threshold, determining the fault level as a high-level fault and determining a corresponding third fault code.

3. The method of claim 2, wherein, determining a fault level according to the abnormal wake-up degree value and a preset fault level threshold further comprises: in response to the abnormal wake-up degree value being less than or equal to the first threshold, determining that there is no frequent wake-up fault.

4. The method of claim 1, wherein, The method further comprises: stopping charging the battery in response to the voltage of the battery reaching a preset voltage threshold.

5. The method of claim 1, wherein, The method further comprises: in response to the vehicle being powered on, resetting the number of abnormal wake-ups to zero and deleting the abnormal wake-up degree value.

6. A processing device for frequent wake-up failure, characterized by, The method comprises the following steps: a counting module configured to determine the number of abnormal wake-ups of the body domain controller in response to the vehicle being powered off; a calculating module configured to determine an abnormal wake-up degree value according to the number of abnormal wake-ups and a preset rated number, wherein the abnormal wake-up degree value is the ratio of the number of abnormal wake-ups to the rated number; a fault level determining module configured to determine a fault level according to the abnormal wake-up degree value and a preset fault level threshold; a processing module configured to perform corresponding processing based on the fault level; wherein the corresponding processing based on the fault level comprises: In response to the fault level being a low-level fault, a first fault code is generated, the first fault code is sent to the memory for storage; or, In response to the fault level being a medium-level fault, a second fault code is generated, the second fault code is sent to the memory for storage, a remote communication terminal is woken up, and a first alarm prompt information is sent to the user terminal through the remote communication terminal; or; In response to the fault level being a high-level fault, a third fault code is generated, the third fault code is sent to the memory for storage, a direct current converter and the remote communication terminal are woken up, the battery of the body area controller is charged through the direct current converter, and a second alarm prompt information is sent to the user terminal through the remote communication terminal.

7. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method of any one of claims 1 to 5.

8. A computer readable storage medium, storing computer instructions for causing a computer to execute the method of any one of claims 1 to 5.

9. A vehicle, comprising the frequent wake-up fault processing apparatus of claim 6, the electronic device of claim 7, or the computer readable storage medium of claim 8.

Images