Power lack risk monitoring method and device, electronic equipment and storage medium

Abstract

The invention provides a power shortage risk monitoring method and device, electronic equipment and a storage medium, and the method comprises the steps: periodically obtaining the bus data of a target vehicle after the power-off of the target vehicle, and determining the equipment information according to the bus data; based on the periodically acquired bus data, detecting whether the target vehicle has a network non-dormancy fragment; when it is detected that the target vehicle has the network non-dormancy fragment, determining a non-dormancy reason based on the device information and bus data corresponding to the network non-dormancy fragment, and determining whether the target vehicle has a power shortage risk; and when the target vehicle has the power shortage risk, outputting early warning information according to the non-dormancy reason. According to the method, active prevention and control of the vehicle power shortage risk are achieved, the limitation of a traditional method on non-original equipment identification and reason positioning is broken through, the situation that the vehicle cannot be started due to battery depletion is prevented, normal operation of the vehicle is ensured, and user experience is improved.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and in particular to a method, device, electronic device, and storage medium for monitoring the risk of battery depletion. Background Technology

[0002] With the rapid development of intelligent connected vehicles, automotive electronic and electrical functions are becoming increasingly numerous, in-vehicle software is becoming more complex, and personalization is leading to a surge in aftermarket equipment. This has resulted in an increase in abnormal in-vehicle ECU networks. Due to the diversity and non-standardization of aftermarket equipment, there is a growing trend of abnormal and non-dormant vehicle networks, posing a greater challenge to the prevention and control of vehicle battery drain.

[0003] Currently, vehicles typically manage function scheduling and power consumption through network management. If the vehicle network malfunctions, it will wake up, causing the battery to continuously and abnormally drain. Once the battery is depleted, the vehicle will be unable to start, impacting not only normal vehicle use and user experience but also potentially posing a threat to vehicle safety and reliability. Therefore, quickly identifying the specific reasons for a vehicle not entering sleep mode and the resulting battery drain, and providing timely solutions, is becoming increasingly important. Summary of the Invention

[0004] This application provides a method, device, electronic device, and storage medium for monitoring the risk of low battery power, aiming to solve the technical problem of how to quickly identify vehicles that are not in sleep mode and the reasons for this.

[0005] In a first aspect, embodiments of this application provide a method for monitoring the risk of battery drain, applied to a battery drain risk monitoring system. The battery drain risk monitoring system is used to monitor the battery drain risk of multiple vehicles, including:

[0006] After the target vehicle is powered off, the bus data of the target vehicle is periodically acquired, and the device information is determined based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose faults in the target vehicle;

[0007] Based on the periodically acquired bus data, detect whether the target vehicle experiences network non-sleep segments;

[0008] When the target vehicle is detected to have a network non-sleep segment, the cause of the non-sleep segment is determined based on the device information and the bus data corresponding to the network non-sleep segment, and it is determined whether the target vehicle is at risk of losing power.

[0009] When the target vehicle is at risk of battery depletion, a warning message is output based on the reason for not going into sleep mode.

[0010] Secondly, embodiments of this application also provide a power loss risk monitoring device, applied to a power loss risk monitoring system, which is used to monitor the power loss risk of multiple vehicles, including:

[0011] The first acquisition module is used to periodically acquire the bus data of the target vehicle after the target vehicle is powered off, and determine the device information based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose the faults of the target vehicle;

[0012] The detection module is used to detect whether the target vehicle has a network non-sleep segment based on the periodically acquired bus data;

[0013] The first determining module is used to determine the cause of the non-sleep segment based on the device information and the bus data corresponding to the non-sleep segment when the target vehicle is detected to have the network non-sleep segment, and to determine whether the target vehicle is at risk of losing power.

[0014] The early warning module is used to output early warning information based on the reason for not going into sleep mode when the target vehicle is at risk of battery depletion.

[0015] Thirdly, embodiments of this application also provide an electronic device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the above-mentioned power loss risk monitoring method.

[0016] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned power loss risk monitoring method.

[0017] The embodiments of this application include at least the following technical effects:

[0018] The technical solution of this application embodiment comprehensively monitors network activity and device status after the vehicle is powered off, identifies various reasons that cause the network to not sleep, assesses the risk of battery depletion, and finally outputs targeted early warning information. This achieves proactive prevention and control of vehicle battery depletion risk, overcoming the limitations of traditional methods in identifying non-original equipment and locating causes, preventing the vehicle from failing to start due to battery depletion, ensuring normal vehicle operation, and improving user experience. Attached Figure Description

[0019] Figure 1 This is one of the flowcharts illustrating the power loss risk monitoring method provided in the embodiments of this application;

[0020] Figure 2 This is the second flowchart illustrating the power loss risk monitoring method provided in the embodiments of this application;

[0021] Figure 3 This is a schematic diagram of the power loss risk monitoring system provided in the embodiments of this application;

[0022] Figure 4 This is a schematic diagram of the power loss risk monitoring device provided in the embodiments of this application;

[0023] Figure 5 A block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0025] In related technologies, with the rapid development of intelligent connected vehicles, automotive electronic and electrical functions are becoming increasingly numerous, in-vehicle software is becoming more complex, and personalization is leading to a surge in aftermarket devices. This has resulted in a rise in anomalies in in-vehicle ECU networks. Furthermore, the diversity and non-standardization of aftermarket devices have led to an increasing trend of vehicle networks failing to shut down, posing a greater challenge to vehicle battery drain prevention and control. Currently, vehicles typically manage function scheduling and power consumption through network management. Once the vehicle network malfunctions, it will wake up, causing the battery to continuously and abnormally drain power. Once the battery is depleted, the vehicle will be unable to start, affecting not only normal vehicle use and user experience but also potentially posing a threat to vehicle safety and reliability. Therefore, the ability to quickly identify vehicle non-shutdown behavior and the specific causes of battery drain and non-shutdown issues, and to provide timely solutions, is becoming increasingly important.

[0026] Based on this, this application provides a method, device, electronic device and storage medium for monitoring the risk of battery depletion in vehicles, which realizes the proactive prevention and control of the risk of battery depletion in vehicles, breaks through the limitations of traditional methods in identifying non-original equipment and locating the cause, prevents the vehicle from failing to start due to battery depletion, ensures the normal operation of the vehicle and improves the user experience.

[0027] Example 1

[0028] This application provides a method for monitoring the risk of battery drain, applied to a battery drain risk monitoring system. The battery drain risk monitoring system is used to monitor the battery drain risk of multiple vehicles. Please refer to [reference needed]. Figure 1 This includes the following steps:

[0029] Step 101: After the target vehicle is powered off, periodically acquire the bus data of the target vehicle and determine the device information based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is the device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose the faults of the target vehicle.

[0030] The power loss risk monitoring method provided in this application embodiment is applied to a power loss risk monitoring system, which can be set up on a cloud server and can monitor the power loss risk of multiple vehicles after power failure.

[0031] Specifically, in this embodiment of the application, after detecting that the target vehicle is powered down (here, the target vehicle is any one of the multiple vehicles corresponding to the power loss risk monitoring system), the bus data of the target vehicle is periodically acquired. The bus data can be collected from the vehicle network, including data sent by the vehicle's electronic control unit, diagnostic equipment, target devices, etc., providing a data source for subsequent data processing and analysis.

[0032] Specifically, bus data includes target device data messages and vehicle design messages. Vehicle design messages include network management messages, diagnostic messages, and application messages.

[0033] For target device data messages, there are many types of messages from automotive target devices, involving multiple systems and functions of vehicle design messages. These messages are mainly used for data exchange and communication between devices to ensure that the target device can work normally and cooperate with the original vehicle system. They are usually composed of message identifier (ID), data length code (DLC), and data field containing the actual data content carried by the message.

[0034] Network management messages are used to manage the sleep and wake-up of the vehicle's ECU network, ensuring smooth network communication. These messages consist of signals such as the ECU ID, network wake-up source, and network sustaining source. For example, the ECU ID consists of 2 bytes, and the network wake-up source and sustaining source each consist of 4 bytes. Each bit represents a sustaining source or wake-up source. An example of the network management message composition for ECU1 is [0x20, 0x0001], where 0x20 is the ECU1 ID identifier and 0x0001 indicates that the wake-up source is network wake-up. An example of the network management message composition for ECU2 is [0x30, 0x0002], where 0x30 is the ECU2 ID identifier and 0x0002 indicates that the headlights are not turned off, causing network wake-up or preventing sleep. An example of the network management message composition for ECU3 is [0x40, 0x0060], where 0x40 is the ECU3 ID identifier and 0x0060 indicates remote service and Bluetooth key functionality.

[0035] Diagnostic message IDs are used to read ECU (Electronic Control Unit) information, fault codes, and to rewrite ECUs. They are usually sent by diagnostic equipment, which sends diagnostic requests and receives diagnostic responses from the ECU. The message identifier (ID) is usually used to distinguish application messages and is typically identified by a fixed ID segment (e.g., 0x7XX).

[0036] Application message IDs and related signals: These are sent periodically by the ECU and include device status information, sensor data, etc. The application message IDs include all design application message IDs on the vehicle network. The signals that need to be collected for the application message include:

[0037] Vehicle Identification Number (VIN) is a unique identifier for each vehicle.

[0038] Data acquisition time: Records the specific time point of data acquisition, in seconds.

[0039] Vehicle States: Includes the vehicle's power-off (0), power-on driving (1), charging (2) and other states.

[0040] Storage battery: battery current, battery voltage, battery SOC, etc.

[0041] Examples of daily car electrical statuses used by car owners: status of four doors and two hoods (doors (open: 1, closed: 0), engine hood (open: 1, closed: 0), trunk lid (open: 1, closed: 0)), air conditioning (open: 1, closed: 0), seats (open: 1, closed: 0), lights (open: 1, closed: 0), etc.

[0042] In this embodiment, the bus message acquisition frequency can be 1Hz, i.e., once per second. The acquisition of bus messages can be handled by nodes capable of acquiring vehicle signals, such as TBOX / gateway / central domain controller.

[0043] In this embodiment of the application, after obtaining bus data, device information can be determined based on the bus data; wherein, the device information is used to indicate whether a target device and a diagnostic device are installed on the target vehicle. The target device and the diagnostic device are different from the original equipment of the target vehicle. The target device is the device installed after the target vehicle leaves the factory, and the diagnostic device is used to diagnose faults in the target vehicle.

[0044] Step 102: Based on the periodically acquired bus data, detect whether the target vehicle has a network non-sleep segment.

[0045] By periodically acquiring the bus data of the target vehicle, the battery current of the target vehicle can be monitored to determine whether the target vehicle has a period of continuous discharge after power-off, i.e., a network non-sleep segment.

[0046] Step 103: When the target vehicle is detected to have a network non-sleep segment, the cause of the non-sleep segment is determined based on the device information and the bus data corresponding to the network non-sleep segment, and it is determined whether the target vehicle is at risk of power loss.

[0047] In this embodiment of the application, after detecting a network non-sleep segment, the cause of the non-sleep failure is determined based on the device information and the bus data corresponding to the network non-sleep segment, and it is determined whether the target vehicle is at risk of battery depletion.

[0048] Step 104: When the target vehicle is at risk of battery depletion, output a warning message based on the reason for not going into sleep mode.

[0049] When there is a risk of battery depletion, a warning message needs to be issued. This message should include the risk level, cause, and recommendations. This warning message can be issued to users or to vehicle manufacturers.

[0050] This application embodiment comprehensively monitors network activity and device status after the vehicle is powered off, identifies various reasons that cause the network to not sleep, assesses the risk of battery depletion, and finally outputs targeted early warning information. This achieves proactive prevention and control of vehicle battery depletion risks, overcoming the limitations of traditional methods in identifying non-original equipment and locating causes, preventing the vehicle from failing to start due to battery depletion, ensuring normal vehicle operation, and improving user experience.

[0051] The following describes how to determine device information. In an optional embodiment of this application, determining device information based on the bus data includes:

[0052] Based on the bus data, determine the actual message identifier set;

[0053] Based on the design message library corresponding to the target vehicle, determine the set of design message identifiers;

[0054] The device information is determined by comparing the actual message identifier set with the designed message identifier set.

[0055] The vehicle bus serves as an information channel for communication between devices. All devices connected to the network (including original equipment manufacturer (OEM) devices, target devices, diagnostic devices, etc.) send signals containing unique "message identifiers" through the bus to identify themselves or transmit commands. The message identifiers of OEM devices are predefined and stored in the "design message library" at the factory, while the message identifiers of non-OEM devices such as target devices (e.g., dashcams, GPS devices) and diagnostic devices (e.g., fault detectors) are not included in this library.

[0056] This application embodiment can extract all occurrences of message identifiers from bus data and summarize them to obtain the actual message identifier set. Alternatively, it can obtain the design message identifier set by calling the design message library of the target vehicle. Different vehicle models have different original equipment, and therefore different sets of design message identifiers.

[0057] By comparing the actual message identifier set with the designed message identifier set, it is possible to accurately identify whether a vehicle has non-original equipment installed, i.e., whether diagnostic equipment and target equipment are installed, thereby determining the equipment information. This equipment information can clearly indicate whether diagnostic equipment and target equipment are installed on the target vehicle.

[0058] The above-described implementation scheme of this application can accurately identify whether a vehicle is equipped with target equipment or diagnostic equipment by extracting the actual message identifier on the bus and comparing it with the preset identifier in the vehicle design message library. Its identification method based on the uniqueness of message identifiers is highly universal and can be adapted to different vehicle models and equipment types. It not only avoids misjudging original equipment, but also provides a reliable basis for subsequent analysis of whether non-original equipment causes network non-sleep and power loss risks.

[0059] The following describes how to determine whether a network non-sleep segment has occurred. In an optional embodiment of this application, the bus data includes the battery current of the target vehicle; based on the periodically acquired bus data, detecting whether the target vehicle has a network non-sleep segment includes:

[0060] Based on the periodically acquired bus data, the battery current of the target vehicle is monitored;

[0061] When the duration during which the battery current is less than a preset current threshold is greater than a preset discharge duration, the duration during which the battery current is less than the preset current threshold is determined as the target period.

[0062] Determine the amount of bus data acquired during the target time period;

[0063] When the number exceeds a preset threshold, it is determined that the target vehicle has a network non-sleep segment, wherein the network non-sleep segment corresponds to the target time period.

[0064] The bus data includes a battery current signal, which reflects the battery's charging and discharging state; a positive value indicates charging, and a negative value indicates discharging. Based on periodically acquired bus data, battery current can be monitored. After the vehicle is powered off, the battery current should be close to zero or maintain a slight discharge. A sustained large discharge current may indicate network activity.

[0065] In this embodiment, a current can be preset as a current threshold, which is a critical value for abnormal discharge. When the battery current is detected to be continuously less than the preset current threshold, i.e., continuous abnormal discharge, and the duration of this state exceeds the preset discharge duration, this period is marked as a target period, serving as a candidate interval for possible network non-sleep segments.

[0066] Furthermore, within the defined target time period, the total amount of bus data actually collected is statistically analyzed. It is considered that if the network goes into sleep mode and devices stop communicating, the amount of bus data will decrease significantly or even be interrupted; if the network does not go into sleep mode and devices continue to send signals, the amount of data will remain at a stable level matching the collection cycle.

[0067] This application embodiment also sets a preset quantity threshold based on the collection cycle and the duration of the target time period. When the total amount of bus data exceeds the preset quantity threshold, the target time period is determined as a non-sleep segment of the network.

[0068] For example, if the target time period is 1 hour (3600 seconds), the preset threshold is 3400 records, and the actual data volume is 3500 records (>3400 records), it is determined to be a non-dormant network segment. If the actual data volume is 3000 records (<3400 records), it indicates that the network was not continuously active and is not determined to be a non-dormant segment.

[0069] The aforementioned implementation scheme of this application accurately identifies non-dormant segments of the vehicle network by monitoring the continuous abnormal discharge state of the battery current and judging the amount of bus data within the corresponding time period. Through triple verification of current threshold, duration, and data volume, it effectively eliminates instantaneous fluctuations and interference from non-network factors, accurately pinpointing the specific time periods of continuous network activity. This provides a precise and reliable basis for subsequent analysis of the causes of non-dormant activity and assessment of the risk of battery depletion.

[0070] The process for determining the cause of sleeplessness is described below. In an optional embodiment of this application, the cause of sleeplessness is determined based on the device information and the bus data corresponding to the network sleeplessness segment, including:

[0071] Based on the device information, the bus data corresponding to the non-sleep network segment, and a preset field set, the original data corresponding to the non-sleep network segment is determined; wherein, the non-sleep network segment corresponds to N bus data, the preset field set corresponds to M fields, and the original data includes N sets of signals, each set of signals including M signals; the preset field set includes a diagnostic device identifier field and a target device identifier field; the diagnostic device identifier and target device identifier in the original data are determined based on the device information;

[0072] Feature extraction is performed on the raw data to determine the feature data; wherein, the feature data includes human feature data, diagnostic equipment feature data, target equipment feature data, and design electronic control unit feature data;

[0073] Based on the aforementioned feature data, the reason for not going into hibernation is determined.

[0074] After identifying the network non-sleep segment in the target vehicle, it is necessary to pinpoint the specific reason for the non-sleep failure.

[0075] Specifically, the network non-sleep segment includes N bus data points, but not all data are related to the cause of the non-sleep issue. A preset field set includes M fields used to filter each of these N bus data points. The preset field set includes a diagnostic device identifier field and a target device identifier field. Based on the device information, the bus data corresponding to the network non-sleep segment, and the preset field set, the original data corresponding to the network non-sleep segment is determined. This original data includes N sets of signals, each set of signals including M fields.

[0076] After identifying the raw data, feature extraction is performed to transform the raw data into quantifiable and analyzable indicators, resulting in feature data. This feature data includes human characteristic data, diagnostic equipment characteristic data, target equipment characteristic data, and design electronic control unit characteristic data.

[0077] Human-related characteristic data is used to quantify the impact of human operations on the network, such as "the percentage of signals where at least one electrical appliance (door, light, etc.) is in a working state" and "the percentage of signals where the electrical appliance state changes frequently" (e.g., repeatedly opening and closing a door). Diagnostic device characteristic data is the percentage of signals whose identifiers are not default values ​​if the device information shows diagnostic devices (reflecting whether the diagnostic device is continuously active). Target device characteristic data is the percentage of signals whose identifiers are not default values ​​for the target device (reflecting whether the target device is continuously sending signals). Designed electronic control unit (ECU) characteristic data analyzes the wake-up / sustainment source signals of the original ECU, calculates the percentage of non-default values ​​(reflecting whether the ECU is abnormally active), and identifies the network's non-sleep type (continuously active or periodically wake-up).

[0078] Finally, based on the characteristic data, the reason for not hibernating was determined.

[0079] The above-described implementation scheme of this application forms raw data by filtering key information from the bus data of non-sleep segments of the network, and then extracts feature data related to human operation, diagnostic equipment, target equipment, and original manufacturer electronic control units, thereby determining the cause of non-sleep by layering judgments. This provides a clear basis for subsequent power loss risk assessment and accurate early warning, effectively improving the practicality of power loss risk monitoring.

[0080] The following describes the process of determining the cause of non-dormancy based on feature data. In an optional embodiment of this application, determining the cause of non-dormancy based on the feature data includes:

[0081] Determine whether the human feature data meets the first preset condition;

[0082] When the human-related characteristic data meets the first preset condition, the reason for not sleeping is determined to be human-related.

[0083] When the human characteristic data does not meet the first preset condition, it is determined whether the diagnostic device characteristic data meets the second preset condition;

[0084] When the diagnostic device feature data meets the second preset condition, the reason for not going into sleep mode is determined to be a diagnostic device reason, and the main diagnostic device is determined based on the diagnostic device feature data;

[0085] When the diagnostic device feature data does not meet the second preset condition, it is determined whether the design electronic control unit feature data meets the third preset condition.

[0086] When the design electronic control unit feature data meets the third preset condition, the reason for not sleeping is determined to be a design electronic control unit reason, and the main design electronic control unit is determined according to the design electronic control unit feature data;

[0087] When the design electronic control unit feature data does not meet the third preset condition, it is determined whether the target device feature data meets the fourth preset condition;

[0088] When the target device feature data meets the fourth preset condition, the reason for not sleeping is determined to be a target device reason, and the main target device is determined based on the target device feature data;

[0089] When the target device feature data does not meet the fourth preset condition, the target electronic control unit with the highest non-sleep ratio is determined based on the feature data, and the reason for non-sleep is determined to be the target electronic control unit.

[0090] In locating the cause of network non-sleep, this application embodiment uses a hierarchical and progressive logical judgment based on the priority order of human operation, diagnostic equipment, original equipment manufacturer (OEM) equipment, and target equipment to locate the dominant cause of network non-sleep from feature data.

[0091] Considering that user actions are the most common non-fault-related cause, early troubleshooting can avoid misdiagnosis of devices, reduce unnecessary investment in subsequent device analysis, and improve diagnostic efficiency. Diagnostic devices are often temporary connections, and their activity has clear scenario characteristics; therefore, temporary factors should be ruled out first. Original equipment manufacturer (OEM) devices are core components of the network, and their failures may cause systemic problems; therefore, they should be the focus of investigation after ruling out external devices. Target device compatibility issues must be confirmed after ruling out faults in the OEM device itself to avoid attributing OEM design flaws to the target device.

[0092] This application first determines whether the human-related characteristic data meets a first preset condition to determine if the cause of the sleep disorder is human-related. If it is not human-related, it further determines whether the diagnostic equipment characteristic data meets a second preset condition to determine if the cause of the sleep disorder is a diagnostic equipment-related cause. If so, the main cause, i.e., the main diagnostic equipment, needs to be identified. If it is not a diagnostic equipment-related cause, it further determines whether the design electronic control unit characteristic data meets a third preset condition to determine if the cause of the sleep disorder is a design electronic control unit. If so, the main cause, i.e., the main design electronic control unit, needs to be identified. If it is not a design electronic control unit, it further determines whether the target equipment characteristic data meets a fourth preset condition. If not, the target electronic control unit with the highest sleep disorder rate is identified as the cause of the sleep disorder. This ensures that the most likely dominant factor can still be found in complex scenarios, avoiding interruption in the judgment. It ensures that the cause can be located in all sleep disorder scenarios, improving the completeness of the solution.

[0093] The implementation scheme described in this application employs a hierarchical and progressive logic, prioritizing human operation, diagnostic equipment, original manufacturer electronic control unit, and target device. Combined with preset conditions, it identifies the primary cause of network non-sleep mode and can pinpoint the cause through percentage analysis in complex scenarios. This provides a clear basis for subsequent early warning and problem-solving, effectively improving the efficiency and accuracy of tracing the causes of non-sleep mode failures.

[0094] The following describes the process of extracting human feature data. In an optional embodiment of this application, the human feature data includes first human feature data and second human feature data. Feature extraction is performed on the original data to determine the feature data, including:

[0095] Extract N sets of application message signals corresponding to everyday electrical appliances from the raw data;

[0096] A first target application message signal is selected from the N groups of application message signals, and the number of the target application message signals is determined to be M1; wherein, the first target application message signal is an application message signal in which at least one of the everyday electrical appliances is in working condition;

[0097] A second target application message signal is selected from the N groups of application message signals, and the number of the target application message signals is determined to be M2; wherein, the second target application message signal is an application message signal in which at least one of the electrical appliances used by people in daily life shows a change in working status;

[0098] The ratio of M1 to N is determined as the first human characteristic data, and the ratio of M2 to N is determined as the second human characteristic data.

[0099] The first preset condition is that the first human feature data is greater than the first preset threshold or the second human feature data is greater than the second preset threshold.

[0100] When determining human-related characteristic data, N sets of application message signals corresponding to daily-use electrical appliances are selected from the raw data. Here, N is the number of bus data corresponding to the non-sleep segment of the network. Daily-use electrical appliances are devices that users can directly operate, such as four car doors, door locks, lights, air conditioners, etc. The working status of these devices directly reflects user behavior.

[0101] From N sets of application message signals, the first target application message signal is determined. This first target application message signal indicates that "at least one appliance is in operation," such as an open car door or an open air conditioner. The number of these first target application message signals is counted, which is denoted as M1. M1 reflects the duration during which "the user did not completely turn off all appliances." For example, if N = 3600 signals have 2800 signals indicating at least one appliance is operating, then M1 = 2800. It's important to note that multiple appliances operating simultaneously are still counted as one valid signal to avoid double counting and ensure that M1 reflects the period of "active activity" rather than the "number of active appliances." Quantifying the duration of "appliances not being completely turned off" using M1 provides data support for determining whether "the user forgot to turn off appliances."

[0102] The second target application message signal is determined from N sets of application message signals. This second target application message signal is defined as a signal indicating a change in the operating state of at least one user-operated appliance, such as a car door opening from closed to open, or a light turning on from off to on. The number of these second target application message signals is counted, which is denoted as M2. M2 reflects the frequency of frequent user operations on appliances. For example, if N = 3600 signals show state transitions such as door opening / closing or light brightness changes in 1500 signals, then M2 = 1500. State changes must be based on signal comparisons between adjacent moments (e.g., a car door was closed in the previous moment and is now open) to ensure that every operation is captured. Quantifying the frequency of frequent appliance operations using M2 provides a basis for determining whether repeated user operations are causing continuous network wake-ups.

[0103] The first characteristic data is the ratio of M1 to N, reflecting the proportion of time spent when "at least one appliance is working". The second characteristic data is the ratio of M2 to N, reflecting the proportion of time spent when "the state of the appliance changes".

[0104] Specifically, the first preset condition for determining whether the lack of sleep mode is due to human error is that a first human-caused feature data point is greater than a first preset threshold, or a second human-caused feature data point is greater than a second preset threshold. These first and second preset thresholds are calibrated experimentally, and the thresholds may differ for different vehicle models.

[0105] The above-described implementation scheme of this application extracts and analyzes application message signals from everyday electrical appliances, quantifies the proportion of continuous operation and status changes of these appliances, and determines whether the network failure to sleep is due to human error by combining preset conditions. By accurately linking user operations with network activity, abstract human factors are transformed into quantifiable objective indicators, effectively distinguishing between human operation and equipment failure, providing a reliable basis for locating the cause of failure to sleep, and reducing ineffective troubleshooting costs.

[0106] The following describes the process of extracting feature data from diagnostic equipment. In an optional embodiment of this application, feature extraction is performed on the raw data to determine the feature data, including:

[0107] Extract N diagnostic device identifiers from the raw data;

[0108] The number of diagnostic device identifiers among the N diagnostic device identifiers that are not the first value is determined as D; wherein, when the device information indicates that the target vehicle does not include a diagnostic device, the diagnostic device identifier in the original data is the first value;

[0109] The ratio of D to N is determined as the characteristic data of the diagnostic device;

[0110] The second preset condition is that the feature data of the diagnostic device is greater than the third preset threshold.

[0111] The primary diagnostic device is the diagnostic device corresponding to the diagnostic device identifier that appears most frequently among the D diagnostic device identifiers.

[0112] When determining the characteristic data of diagnostic equipment, N diagnostic equipment identifiers are first selected from the raw data. The raw data includes N sets of signals, each corresponding to a data acquisition time. Each set of signals includes M signals, and the diagnostic equipment identifier is one of these M signals. Each of the N sets of signals in the raw data includes a diagnostic equipment identifier, which is used to identify the diagnostic equipment. Different diagnostic equipment corresponds to different diagnostic equipment identifiers. This diagnostic equipment identifier is determined based on equipment information. Specifically, when the equipment information indicates that the target vehicle includes a diagnostic equipment, the diagnostic equipment identifier for that equipment is obtained and added to the raw data; when the equipment information indicates that the target vehicle does not include a diagnostic equipment, a first value is added to the raw data. This first value is distinct from other diagnostic equipment identifiers; for example, the first value can be set to 0x00.

[0113] Then, these N diagnostic device identifiers are further filtered to identify those whose identifiers are not the first value, and the number of these identifiers is counted, which is D. D reflects the actual duration of activity of the diagnostic device during the non-dormant segment. For example, if the original data contains 3600 signals, and 2000 of these signals have a diagnostic device identifier that is not "0x00", then D = 2000, indicating that the diagnostic device was active at 2000 moments. It should be noted that if the same diagnostic device sends signals at multiple moments, as long as the identifier is consistent, all signals are included in the count of D to ensure that its continuous activity is captured.

[0114] Finally, the characteristic data of the diagnostic equipment are calculated.

[0115] DK = D / N, where DK is the diagnostic device characteristic data, D is the number of diagnostic device identifiers that are not the first value, and N is the number of diagnostic device identifiers included in the original data.

[0116] Diagnostic device characteristic data reflects the percentage of active diagnostic devices in non-dormant segments.

[0117] Specifically, the second preset condition for determining whether the lack of sleep mode is due to the diagnostic equipment is that the diagnostic equipment's characteristic data exceeds a third preset threshold. This third preset threshold is calibrated experimentally, and the threshold may differ for different vehicle models.

[0118] If the reason for not hibernating is due to the diagnostic equipment, then it is necessary to further determine the primary diagnostic equipment, which is the main cause. The primary diagnostic equipment is the diagnostic equipment corresponding to the diagnostic equipment identifier that appears most frequently among D diagnostic equipment identifiers. Here, D diagnostic equipment identifiers refer to the diagnostic equipment identifiers that are not the first value selected from N diagnostic equipment identifiers. For example, if N=3600 and D=2000 for a certain non-hibernation segment, the ratio is approximately 55%, which exceeds the third preset threshold (e.g., 50%), then it is determined to be "diagnostic equipment cause"; among them, "DIAG-001" appears 1500 times, the most frequently, and is determined to be the primary diagnostic equipment, that is, this model of diagnostic equipment is the main cause of the vehicle not hibernating.

[0119] The above-described implementation scheme of this application extracts the diagnostic device identifier, counts the number of occurrences of its non-default values ​​and calculates the proportion, and combines it with a preset threshold to determine whether the diagnostic device is the cause of the network not sleeping. At the same time, it locates the main diagnostic device with the most occurrences, thereby achieving accurate identification of the active status and impact of the diagnostic device, objectively distinguishing between normal and abnormal interference, providing a clear basis for investigating specific interference sources and solving the non-sleep problem caused by the device, and effectively supporting the prevention and control of power loss risk.

[0120] The following describes the process of extracting feature data from the target device. In an optional embodiment of this application, feature extraction is performed on the original data to determine the feature data, including:

[0121] Extract N target device identifiers from the raw data;

[0122] The number of target device identifiers among the N target device identifiers that are not the second value is determined as P; wherein, when the device information indicates that the target vehicle does not include the target device, the diagnostic device identifier in the original data is the second value;

[0123] The ratio of P to N is determined as the characteristic data of the target device;

[0124] The fourth preset condition is that the target device feature data is greater than the fourth preset threshold.

[0125] The primary target device is the target device corresponding to the target device identifier that appears most frequently among the P target device identifiers.

[0126] When determining the target device characteristic data, N target device identifiers are first selected from the raw data. The raw data includes N sets of signals, each corresponding to a sampling time. Each set of signals includes M signals, and the target device identifier is one of these M signals. Each of the N sets of signals in the raw data includes a target device identifier, used to identify the target device. Different target devices correspond to different target device identifiers. The target device can be a non-original equipment (OEM) device such as a dashcam or in-car navigation system. This target device identifier is determined based on device information. Specifically, when the device information indicates that the target vehicle includes the target device, the target device identifier is obtained and added to the raw data; when the device information indicates that the target vehicle does not include the target device, a second value is added to the raw data. This second value is distinct from other target device identifiers; for example, the second value can be set to 0x00.

[0127] Then, these N target device identifiers are further filtered to identify those whose identifiers are not the first value, and the number of these is counted, which is P. P reflects the actual duration of the target device's activity during the non-sleep segment. For example, if the original data contains 3600 signals, and 2000 of these signals have a target device identifier that is not "0x00", then D = 2000, indicating that the target device was active at 2000 moments. It should be noted that if the same target device sends signals at multiple moments, as long as the identifier is consistent, they are all included in the count of D to ensure that its continuous activity is captured.

[0128] Finally, the characteristic data of the target device are calculated.

[0129] PK = D / N, where PK is the target device feature data, P is the number of target device identifiers that are not the second value, and N is the number of target device identifiers included in the original data.

[0130] The target device characteristic data reflects the active percentage of the target device in the non-dormant segment.

[0131] Specifically, the fourth preset condition for determining whether the reason for not sleeping is due to the target device is that the diagnostic device's characteristic data is greater than a fourth preset threshold. This fourth preset threshold is calibrated experimentally, and the threshold may vary for different vehicle models.

[0132] If the reason for not hibernating is due to a target device, then it is necessary to further determine the primary target device, which is the main cause. The primary target device is the target device corresponding to the target device identifier that appears most frequently among P target device identifiers. Here, P target device identifiers refer to the target device identifiers that are not the first value selected from N target device identifiers. For example, if N=3600 and P=2000 for a certain non-hibernation segment, the ratio is approximately 55%, exceeding the third preset threshold (e.g., 50%), then it is determined to be a "target device cause"; among them, "REC-002" appears 1500 times, the most frequent, and is determined to be the primary target device, that is, this target device is the main cause of the vehicle not hibernating.

[0133] The above-described implementation scheme of this application extracts the target device identifier, counts the number of occurrences of its non-default values ​​and calculates the proportion, and combines it with a preset threshold to determine whether the target device is the cause of the network not sleeping. At the same time, it locates the main target device with the most occurrences, thereby achieving accurate identification of the active status and impact of the target device, objectively distinguishing between normal and abnormal interference, providing a clear basis for investigating specific interference sources and solving the non-sleep problem caused by the device, and effectively supporting the prevention and control of power loss risk.

[0134] The following describes the process of extracting feature data from the electronic control unit (ECU). In an optional embodiment of this application, the feature data of the ECU includes non-sleep type and wake-up feature data corresponding to each ECU in the set of ECUs corresponding to the target vehicle; feature extraction is performed on the raw data to determine the feature data, including:

[0135] Based on the time interval between each adjacent acquisition time in the original data, the non-sleep type corresponding to the non-sleep segment is determined; wherein, when the time interval between each adjacent acquisition time is equal to the acquisition cycle of the bus data, the non-sleep type is determined to be a continuous non-sleep type; when at least one time interval between each adjacent acquisition time is greater than the acquisition cycle, the non-sleep type is determined to be a periodic wake-up non-sleep type, and the number of time intervals greater than the acquisition cycle is determined as the periodic wake-up count.

[0136] For each design electronic control unit in the set of design electronic control units, extract N wake-up sustaining source signals corresponding to the design electronic control unit from the original data;

[0137] The number of wake-up sustaining source signals that are neither the third nor the fourth value among the N wake-up sustaining source signals is determined as S;

[0138] The ratio of S to N is determined as the wake-up characteristic data corresponding to the designed electronic control unit;

[0139] The third preset condition is that the wake-up feature data corresponding to any design electronic control unit in the set of design electronic control units is greater than the fifth preset threshold, or the number of periodic wake-ups is greater than the sixth preset threshold.

[0140] When the non-sleep type is the continuous non-sleep type, the design electronic control unit whose wake-up feature data is greater than the seventh preset threshold in the set of design electronic control units is determined as the main design electronic control unit;

[0141] When the non-sleep type is the periodic wake-up non-sleep type, the design electronic control unit whose wake-up feature data is greater than the eighth preset threshold in the set of design electronic control units is determined as the main design electronic control unit.

[0142] Specifically, the design electronic control unit (ECU) characteristic data includes the non-sleep type and the wake-up characteristic data for each ECU in the set of ECUs corresponding to the target vehicle. The non-sleep type refers to the type of non-sleep segment in this network, including periodic wake-up non-sleep type and continuous non-sleep type; the wake-up characteristic data represents the active percentage of the ECU within the non-sleep segment. The following sections describe how to determine the non-sleep type and wake-up characteristic data.

[0143] I. Non-dormant type

[0144] When determining the non-sleep type, the time interval between each adjacent acquisition time in the original data is first determined. That is, the acquisition time signal column in the original data is processed by a window function to form a new signal column, which is denoted as the time interval signal column.

[0145] Then, the number of signals in the time interval signal train that are longer than the bus data acquisition period is counted and denoted as WC. The bus data used to generate the raw data is acquired at a fixed acquisition period, and the time interval between two adjacent acquisitions reflects whether the network remains active.

[0146] Finally, the non-sleep type is determined based on the value of WC. When WC equals zero, it indicates that the time interval between each adjacent acquisition time is equal to the bus data acquisition cycle, and the network is always active without any sleep periods. In this case, the non-sleep type is the continuous non-sleep type. When WC is greater than zero, it indicates that at least one of the time intervals between each adjacent acquisition time is greater than the acquisition cycle, and the network has undergone a process of being woken up after sleep. In this case, the non-sleep type is the periodic wake-up non-sleep type, and WC is recorded as the number of periodic wake-ups, reflecting the wake-up frequency.

[0147] For example, if the acquisition period is 1 second, and in a certain non-sleep segment of 3600 data sets, the adjacent intervals are all 1 second, it is determined to be "continuous non-sleep type", which may be caused by a certain ECU continuously sending signals. If there are 5 intervals of 5 seconds (greater than 1 second) and the rest are 1 second, it is determined to be "periodic wake-up non-sleep type", with a periodic wake-up count of 5, which may be caused by a certain ECU periodically waking up the network.

[0148] II. Awakening Feature Data

[0149] When determining the wake-up characteristic data, firstly, for each designed electronic control unit (ECU) in the set of designed ECUs, N wake-up sustaining source signals corresponding to the designed ECU are extracted from the raw data. The set of designed ECUs includes original vehicle ECUs, such as engine ECUs and body control ECUs. Each designed ECU has wake-up sustaining source signals. N wake-up sustaining source signals (N being the total data amount) for each designed ECU are extracted from the raw data throughout the entire non-dormant segment, forming the active trajectory of that designed ECU.

[0150] Then, for each designed electronic control unit, the number of wake-up sustaining source signals that are neither the third nor the fourth value among the N wake-up sustaining source signals is determined as S. The third and fourth values ​​are the default signal values ​​when the designed electronic control unit is in normal sleep mode. If the signal is not one of these two values, it indicates that the designed electronic control unit is in a wake-up or abnormally active state.

[0151] Finally, for each designed electronic control unit, the ratio of S to N is determined as the wake-up characteristic data corresponding to that electronic control unit. The wake-up characteristic data reflects the active percentage of that electronic control unit during the non-sleep segment.

[0152] Specifically, the determination of whether the reason for not sleeping is that the wake-up characteristic data corresponding to any electronic control unit in the set of designed electronic control units is greater than the fifth preset threshold, or the number of periodic wake-ups is greater than the sixth preset threshold.

[0153] After determining that the reason for the lack of sleep is due to the design of the electronic control unit, it is necessary to determine the main electronic control unit based on the type of lack of sleep. When the lack of sleep type is continuous lack of sleep, the electronic control unit whose wake-up characteristic data is greater than the seventh preset threshold is determined as the main electronic control unit; when the lack of sleep type is periodic wake-up lack of sleep, the electronic control unit whose wake-up characteristic data is greater than the eighth preset threshold is determined as the main electronic control unit.

[0154] Specifically, the fifth, sixth, seventh, and eighth preset thresholds are calibrated through experiments, and the thresholds may differ for different vehicle models.

[0155] The above-described implementation scheme of this application determines the type of non-sleep mode by analyzing time intervals, extracts the wake-up signal of the original electronic control unit and quantifies its active ratio, and combines different types of adaptive thresholds to locate the main electronic control unit. It can accurately distinguish between continuous active and periodic wake-up modes, convert the active state into comparable values, provide clear directions for maintenance, effectively fill the gap in locating the cause of non-sleep mode caused by original equipment abnormalities, improve vehicle network stability and reduce the risk of battery drain.

[0156] Specifically, when the reason for not sleeping is due to a design flaw in the electronic control unit (ECU), since there is a correlation between the ECU and the target device, to avoid judgment bias caused by a single cause, it is also necessary to investigate whether the malfunction of the ECU is caused by the installation of the target device. In an optional embodiment of this application, the target ECU is any ECU in the set of ECUs corresponding to the target vehicle. When the main ECU is the target ECU, after determining the reason for not sleeping, the method further includes:

[0157] When the device information corresponding to the target vehicle indicates that the target vehicle is equipped with a target device, the historical non-dormant data of the target vehicle model to which the target vehicle belongs within a preset time period is obtained.

[0158] Based on the historical non-sleep data records, determine the number of times the target-designed electronic control unit was identified as a cause of non-sleep within a preset time period;

[0159] When the number of times is greater than zero, it is determined whether the target device is installed on each vehicle for which the target electronic control unit is identified as not sleeping.

[0160] If so, the reason for not going into sleep mode will be determined to be due to the design of the electronic control unit or the target device.

[0161] In this embodiment, after determining that the cause of non-sleep is the design electronic control unit (ECU) and identifying the primary design ECU (where the primary design ECU is the target design ECU, and the target design ECU is any ECU in the set of design ECUs corresponding to the target vehicle), the process first determines whether the target vehicle has the target device installed. This can be determined based on the device information corresponding to the target vehicle. After confirming that the target vehicle has the target device installed, the historical non-sleep data of the target vehicle model within a preset time period is obtained. This preset time period can be the past three months. This historical non-sleep data includes records of other vehicles of the same model where the target design ECU was identified as having a non-sleep cause, as well as information on whether the corresponding vehicles have the target device installed. The scope of historical data acquisition focuses on the same vehicle model, as the compatibility between ECUs and target devices may differ between different vehicle models; data from the same vehicle model is more valuable for reference.

[0162] Then, based on historical non-sleep data records, the total number of times the target electronic control unit was identified as a non-sleep cause within a preset time period is counted. If the number is zero, it indicates that the abnormality of this electronic control unit is extremely rare in the same vehicle model, and the original single-cause judgment can be maintained, that is, it is determined that the non-sleep cause of this network non-sleep segment is only due to the design of the electronic control unit; if the number is greater than zero, further analysis of the installation status of the target equipment in the vehicle in these records is required.

[0163] Finally, if all vehicles for which the target electronic control unit (ECU) is identified as the cause of non-sleep are equipped with the target device, it indicates that the anomaly of the target ECU is highly correlated with the presence of the target device. This may be a synergistic effect caused by compatibility issues between the two, such as the signal sent by the target device interfering with the sleep logic of the target ECU. In this case, the cause of non-sleep is corrected to be a combination of the ECU design and the target device. If there are vehicles without the target device installed, it indicates that the anomaly of the target ECU may have an independent cause. The original single determination is maintained, that is, the cause of non-sleep in this network segment is determined to be solely due to the ECU design.

[0164] For example, the target electronic control unit is the vehicle's electronic control unit (ECU). Historical non-sleep data records show that the ECU of the same vehicle model was identified as having a non-sleep function 8 times in the past 3 months. In these 8 instances where the ECU was identified as the cause, all 8 vehicles had the target device (such as a navigation system or dashcam) installed. Therefore, it can be determined that the malfunction of the ECU is related to the target device. If one vehicle does not have any target device installed, it indicates that the ECU may have an independent fault and is not included in the composite cause assessment.

[0165] The aforementioned implementation scheme of this application, when the main electronic control unit is determined to be non-dormant and the target device is installed in the vehicle, verifies the correlation between the electronic control unit malfunction and the target device by retrieving historical data from the same vehicle model, thereby determining a compound cause. This avoids the bias of single-cause attribution, making the cause judgment more comprehensive and accurate, improving vehicle network stability and reducing the risk of battery depletion.

[0166] In an optional embodiment of this application, determining whether the target vehicle is at risk of battery depletion includes:

[0167] Obtain the first battery capacity corresponding to the start time and the second battery capacity corresponding to the end time of the non-dormant segment of the network, and determine the battery discharge amount based on the first battery capacity and the second battery capacity;

[0168] Obtain the minimum battery voltage corresponding to the non-dormant segment of the network;

[0169] Based on historical non-dormant data, determine the cumulative number of occurrences of the non-dormant cause within a preset time period;

[0170] When the battery discharge exceeds a preset threshold, or the minimum battery voltage is less than a preset voltage threshold, or the cumulative number of occurrences exceeds a preset number of occurrences threshold, it is determined that the target vehicle is at risk of battery depletion.

[0171] When determining the existence of a risk of battery depletion, the non-dormant network segment refers to a specific period of continuous network activity. It is necessary to obtain the capacity of the first battery at the start of this segment and the capacity of the second battery at the end. The difference between these two values ​​represents the battery discharge within that segment, directly reflecting the power consumption caused by the non-dormant activity. Battery voltage gradually decreases as power is consumed; excessively low voltage may prevent the vehicle from starting. Continuously monitoring the battery voltage within the non-dormant network segment and recording the minimum value reflects the battery's minimum power supply capacity within that segment. Since the frequent occurrence of each non-dormant cause increases the cumulative effect of the risk of battery depletion, it is also necessary to retrieve historical non-dormant data for a preset period (e.g., the past month) and count the cumulative occurrences of each cause. A higher frequency indicates a more persistent problem and a higher probability of long-term battery depletion. Introducing historical data reflects the frequency of the problem, avoiding focusing solely on the impact of a single non-dormant event, and judging the risk of battery depletion from a long-term trend perspective, thus improving the foresight of the assessment.

[0172] Then, multiple indicators are comprehensively analyzed to determine whether the target vehicle is at risk of battery depletion. A risk of battery depletion is determined if any of the following conditions are met:

[0173] 1. The battery discharge exceeds the preset threshold;

[0174] 2. The minimum battery voltage is less than the preset voltage threshold;

[0175] 3. The cumulative number of occurrences exceeds the preset threshold.

[0176] The aforementioned implementation scheme in this application comprehensively assesses the battery discharge amount, minimum voltage, and historical frequency of corresponding non-dormant segments in the network, judging the vehicle's battery drain risk from multiple dimensions, including current energy consumption, voltage status, and historical trends. This avoids the limitations of a single indicator, ensures consistent evaluation standards across different scenarios, provides early warnings for users, and offers after-sales support for automakers, effectively reducing the risk of vehicle battery drain.

[0177] The overall implementation process of the embodiments of this application is described below, such as... Figure 2 As shown, it includes:

[0178] Step 201: After the vehicle is powered off, periodically acquire bus data and determine device information. Determining device information involves identifying aftermarket and diagnostic device messages. Specifically, the diagnostic message ID or aftermarket device ID signal is acquired and processed. Based on the data acquisition cycle, multiple diagnostic message IDs (0x7XX) or multiple aftermarket device ID signal messages are uniformly categorized into a single message within the diagnostic ID or aftermarket device ID signal. If no diagnostic message or aftermarket device message is found, it is represented by 0x00. The aftermarket device ID data collection method is as follows: An existing vehicle network ID list (array A) is formed by reading all message ID values ​​within the non-dormant segment of the vehicle network. An original vehicle design message ID list (array B) is read from the data storage module. AB represents elements in A but not in B. When AB is greater than 0, it indicates that there are messages on the vehicle network that are not in the original vehicle design message ID list, and also indicates that an aftermarket device is sending messages to the vehicle network within this segment. The ID values ​​of messages not in the original vehicle design are collected according to the collection cycle to form the aftermarket device message ID. When AB is less than or equal to 0, it indicates that there are no aftermarket device message IDs on the vehicle network, and 0x00 is used to fill the gap.

[0179] Step 202: Data Preprocessing. Data preprocessing includes data cleaning, missing value imputation, and outlier handling to ensure data integrity and accuracy. Specifically, data preprocessing includes: 1. Outlier Filtering: Identifying and processing outliers (also known as missing values) in the data. These values ​​may be caused by measurement errors, insufficient measurement accuracy, or data entry errors. Methods for handling outliers include deleting them, treating them as missing values, or using statistical methods (such as box plots) for transformation. 2. Missing Value Interpolation: Identifying and processing missing values ​​in the data. For missing values, appropriate interpolation or prediction methods are used to impute them to reduce data loss. Methods include using window functions to fill missing values ​​with the mean, median, mode, or predicted values. 3. Window Function Processing: Used to access the data of the row (or rows preceding) the current row.

[0180] Step 203: Determine if a non-sleep network segment exists. If yes, proceed to step 204; otherwise, end. Specifically, the timer starts from time0 when the vehicle state (VehicleStates = 0) is powered off, and ends at the last data message (time0) before the next power-on time (VehicleStates = 1). n-1 That is, in [time0, time n-1 If, within a given time segment, the vehicle remains in a powered-off state, the battery current remains below 0 for an extended period exceeding a certain threshold (3600 seconds, which can be adjusted), and the data collection count N exceeds 3600, this constitutes a non-dormant data segment of the vehicle network. If this segment is determined to be caused by the non-dormant nature of the vehicle network, the process for determining the cause of the non-dormant status begins; otherwise, the process ends.

[0181] The process for determining the cause of non-hibernation includes steps 204 to 210.

[0182] Before making a judgment, various parameters need to be calculated.

[0183] Specifically, after data preprocessing, a non-sleep data segment of the vehicle network is obtained. The original data within the segment is represented by Data[X, Y], where X ranges from [0, n-1] to indicate that there are N data points, and Y represents that each acquisition cycle consists of m signals, denoted by [Y0, Y...]. m-1 The data includes signals such as [vin, acquisition time, vehicle status, aftermarket device ID, diagnostic ID, door status, hood status, trunk lid status, air conditioning status, seat status, light status, ECU1 ID and its wake-up or sustaining source 1, ECU2 ID and its wake-up or sustaining source 2...ECUR ID and its wake-up or sustaining source, battery voltage, battery SOC, and battery current]. i The numerical values ​​of the column operating status signals are composed of [V1, V2, ..., V]. L ], where V1 indicates a non-working signal state and will not wake up the vehicle network, V2, ... V L The value represents different working states, which will continuously wake up or maintain the vehicle network. R represents the number of ECUs in the vehicle design. When no ECUID appears on the bus line, it is filled with 0x000000.

[0184] Based on the original data Data[X, Y] within the non-sleep segment, the calculated non-sleep characteristic data is represented by Z[vin, start time, end time, after-installation device identifier, diagnostic message D, after-installation message P, human error M, ECU wake-up source and sustaining source W, minimum voltage, SOC drop]. Then, based on the characteristic data of the non-sleep segment, the results of non-sleep, power depletion, and power depletion risk are judged [vin, start time, end time, non-sleep reason, minimum voltage, power depletion risk].

[0185] Within a non-sleep interval N, there are two main scenarios: one is that the vehicle network is continuously active, and the other is that the vehicle network wakes up periodically without sleeping. A window function is applied to the collected time signal column to form Y. i+1 Columns are used to access the signal value from the previous time step, when the same row Y... i Subtract Y from the list of times i+1 When the time difference between the columns is greater than 1 second, it is marked as 1. Then, the number of times it is marked as 1 is recorded as WC. When WC = 0, the number of times the network wake-up is in this cycle is 0, and it is marked as a continuous non-sleep segment of the vehicle network. Otherwise, the proportion of the number of times the network wake-up is in this cycle is WW = WC / N*100, and it is judged as a periodic wake-up non-sleep segment of the vehicle network.

[0186] Based on the vehicle's original data Data[X, Y], which consists of application message signals from everyday electrical appliances (four doors, four door locks, engine hood, trunk lid, vehicle lights, air conditioning), one or more of these signals are always in a working state, thus causing the vehicle network to never go into sleep mode. The total count percentage is represented by MK. In the entire non-sleep interval N, the count percentage is: MK = 100 - Mi / N*100, where: Mi is the row count sum of all signals from everyday electrical appliances that are simultaneously in a non-working state.

[0187] Frequent switching on or off of one or more signals leads to frequent vehicle network wake-ups; the percentage of frequent wake-ups is denoted by MW. A window function is applied to each signal in the signal group to form Y. i+1 A column is used to access the signal value at the previous time step, when the Y value of the same signal is... i Column and Y i+1 When the signal operating state changes, it is marked as 1; otherwise, it is marked as 0. Then, MW = 100 - Mi / N * 100 is calculated, where Mi is the count of all signal operating state change markers in the signal group being 0.

[0188] Based on the diagnostic device messages in the vehicle's original data Data[X, Y], using [DD0, DD1, DD... i …DD n-1The value is represented by ], and then the number of occurrences of each non-0x00 value is counted. The value with the most occurrences is taken as the main reason for not sleeping this time (DD). The percentage of working time of the diagnostic message D is represented by DK, DK = 100 - DDi / N * 100, where DDi = 0x00.

[0189] Based on the aftermarket device ID in the vehicle's original data Data[X, Y], use [PD0, PD2, PD3, ..., PD4] i …, PD n-1 The process involves counting the occurrences of each non-0x00 unique value in the data, and then selecting the value with the highest occurrence as the primary reason for not sleeping in this instance (PD). The percentage of aftermarket device operating time is represented by PK, where PK = 100 - PDi / N * 100, and PDi = 0x00. When a non-0x00 value exists, it is determined that the vehicle has aftermarket devices sending messages to the vehicle bus, indicated by a 1; otherwise, it is indicated by a 0.

[0190] When a vehicle's ECU network malfunctions and causes the vehicle network to not sleep, an abnormal non-sleep ECU will appear on the vehicle network. The NM message in the abnormal non-sleep ECU will contain a sustain source or wake-up source other than 0x0001. Sometimes, an NM management message of a passively woken-up ECU will also appear. The passively woken-up ECU will send a 0x0001 passively woken-up sustain source or wake-up source.

[0191] The number of ECUs in the vehicle design is denoted as L. Based on the original vehicle data Data[X,Y], for the L ECUs, we filter the nodes with ECU ID 0x00 and ECUs with a wake-up or wake-up source of 0x0001. Simultaneously, we extract the ECU IDs whose wake-up or wake-up source is not 0x0001. Then, we calculate the percentage of working time WK for each extracted single wake-up / wake-up source. ECUi =Mi / N*100, where: Mi is the row count sum of non-0x0001 and 0x0000 values. Then, for the sustain source or wake-up source, count the number of occurrences of each non-0x0000 and non-0x0001 value.

[0192] When WW is greater than or equal to 1, select WK. ECUi ECUi with a value greater than 5 (the threshold can be adjusted according to the normal sleep time of the vehicle network) is selected as the ECU ID of the main reason for not sleeping this time. At the same time, the value with the most trips of the maintenance source or wake-up source of this ECU is selected as the wake-up source or maintenance source of this ECU.

[0193] When = 0, select WK ECUiECUs with a value greater than 50 are selected as the primary ECU IDs for the non-sleep condition. At the same time, the ECU with the highest number of trips for its sustain or wake-up source is selected as the wake-up or sustain source for that ECU.

[0194] Step 204: Determine if the cause is human error. If yes, proceed to step 211; otherwise, proceed to step 205.

[0195] Specifically, within a non-sleep cycle, if MK > 50 (the threshold is adjusted according to the actual situation) or MW > 10 (the threshold can be adjusted according to the actual situation) in the calculated non-sleep characteristic data, it can be determined that the vehicle network is not sleeping due to human reasons, and then proceed to step 211; otherwise, proceed to step 205.

[0196] Step 205: Determine if the problem is caused by a diagnostic device. If yes, proceed to step 211; otherwise, proceed to step 206.

[0197] Specifically, within a non-sleep cycle, if DK > 50 threshold (the threshold is adjusted according to the actual situation) in the calculated non-sleep characteristic data, it can be determined that the vehicle network is not sleeping due to diagnostic reasons, and proceed to step 211; otherwise, proceed to step 206.

[0198] Step 206: Determine if the issue is due to ECU design. If yes, proceed to step 211; otherwise, proceed to step 207.

[0199] Step 207: Determine if only vehicles with the rear equipment have been involved in the incident within the past month. If yes, proceed to step 208; otherwise, proceed to step 211.

[0200] Step 208: Mark as a design ECU malfunction and aftermarket equipment causing the network to not sleep.

[0201] Specifically, within a non-sleep cycle, based on the calculated non-sleep characteristic data, if any value > 50 (the threshold can be adjusted according to actual conditions) or CW > 10 (the threshold can be adjusted according to actual conditions), it is determined that the vehicle network non-sleep is caused by an electrical malfunction in the vehicle design. To further determine whether the malfunction is caused by aftermarket equipment (for example, aftermarket equipment may occasionally send messages to the vehicle network, but the vehicle network shows that the non-sleep is caused by the electrical malfunction in the vehicle design, such as when installing electric pedals, the original vehicle's wiring harness may be modified, which may cause poor contact on the original vehicle's wires, triggering the original vehicle ECU network non-sleep, etc.), based on the current and historical vehicle network non-sleep data of this model in Table 2, historical data for a period of time (more than 1 month) is collected. If the main cause of the current non-sleep has only occurred in aftermarket vehicles and has not occurred in any non-aftermarket equipment vehicles, the vehicle network non-sleep may be caused by aftermarket equipment. In this case, it is marked that the current non-sleep is caused by both vehicle design ECU malfunction and aftermarket equipment, and then proceed to step 209; otherwise, proceed directly to step 209.

[0202] Step 209: Determine if the problem is caused by an aftermarket device. If yes, proceed to step 211; otherwise, proceed to step 210.

[0203] Specifically, within a non-sleep cycle, if PK > 50 in the calculated non-sleep characteristic data (the threshold can be adjusted according to actual conditions), it is determined that the vehicle network is not sleeping due to aftermarket equipment, and proceed to step 211; otherwise, proceed to step 210.

[0204] Step 210: Select the reason for not hibernating as the one with the highest percentage of working time.

[0205] Specifically, within a non-dormant cycle, the cause with the highest percentage of working time (human factors, diagnostic reasons, vehicle design ECU malfunctions, and aftermarket equipment) is selected as the primary cause of the non-dormant period.

[0206] Step 211: Determine if there is a risk of power loss. If yes, proceed to step 212; otherwise, end the process.

[0207] Specifically, within a non-dormant interval N, the minimum value of the battery voltage signal is calculated as: Battvolt min =min(Y) 蓄电池电压 ).

[0208] The change in SOC (State of Charge) is calculated as follows: ΔSOC = Data[N-1, Y] (where N is a non-dormant interval N, and Y is a non-dormant interval N). SOC ]-Data[0,Y SOC ].

[0209] When △SOC>70 or Battvolt min If the voltage is less than 11V, or if the number of times a vehicle that does not go into sleep mode accumulates to more than a certain threshold (3 times) within a certain period (one week), an alarm will be triggered to indicate that the vehicle is running out of power or is at risk of running out of power.

[0210] Step 212: Output early warning information.

[0211] Specifically, when a message is received indicating that the battery is not in sleep mode or is at risk of running out of power, a push notification service is triggered. This notification can then be sent to the vehicle owner, dealership, or other relevant parties via SMS, app messages, or phone calls, enabling timely troubleshooting and resolution of the issue.

[0212] At the same time, information such as the vehicle's failure to sleep and the reasons for this incident, including VIN, occurrence time, end time, reason for failure to sleep, minimum voltage, and risk of power loss, will be updated in the database.

[0213] It should be noted that the above-mentioned end refers to the end of this network non-sleep judgment. After receiving new bus data, execution will continue from the beginning until the vehicle is powered on.

[0214] The above-described implementation scheme, specifically the embodiment of this application, comprehensively monitors network activity and device status after the vehicle is powered off, identifies various reasons that cause the network to not sleep, assesses the risk of battery depletion, and ultimately outputs targeted early warning information. This achieves proactive prevention and control of vehicle battery depletion risks, overcoming the limitations of traditional methods in identifying non-original equipment and locating causes, preventing the vehicle from failing to start due to battery depletion, ensuring normal vehicle operation, and improving user experience.

[0215] The power loss risk monitoring method provided in this application embodiment is applied to a power loss risk monitoring system, such as... Figure 3 As shown, the power loss risk monitoring system 30 includes: a data acquisition module 301, an equipment identification module 302, a data storage module 303, an algorithm identification module 304, an alarm push module 305, and a power loss processing knowledge base 306.

[0216] Specifically, the data acquisition module is responsible for periodically acquiring bus data from the vehicle network. The device identification module is responsible for identifying whether aftermarket devices and diagnostic devices are installed on the vehicle. The data storage module is responsible for storing bus messages, raw data, feature data, reasons for non-sleep status, and other data. The algorithm identification module is responsible for implementing algorithms such as data preprocessing, data statistics, and rules. This includes: filtering outliers, interpolating missing values ​​and handling window functions, calculating feature values ​​within non-sleep segments, vehicle network non-sleep identification algorithms, identifying human-caused non-sleep issues, identifying diagnostic reasons for non-sleep issues, identifying reasons related to vehicle-side ECUs, and identifying vehicle battery depletion and potential battery depletion risks. This functionality can be implemented by the vehicle ECU controller, the cloud, or a combination of both. The alarm push module is responsible for pushing processing results, alarm information, or notification messages to users, other systems, or devices. This ensures that information is delivered to relevant personnel or systems in a timely and accurate manner so that they can take appropriate actions. This functionality is implemented using components such as TBOX, IoT platforms, message queues (e.g., RabbitMQ, Kafka), push notification services (e.g., FCM, SMS), and email services. The battery drain handling knowledge base is responsible for providing different vehicle handling opinions and methods based on expert experience and methods, according to different causes of battery drain in various vehicles. This includes information such as vehicle model, cause of battery drain, solution, and handling suggestions.

[0217] Example 2

[0218] This application also provides a battery drain risk monitoring device, applied to a battery drain risk monitoring system. The battery drain risk monitoring system is used to monitor the battery drain risk of multiple vehicles. Please refer to [reference needed]. Figure 4The power loss risk monitoring device 40 includes:

[0219] The first acquisition module 410 is used to periodically acquire the bus data of the target vehicle after the target vehicle is powered off, and determine the device information based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose the faults of the target vehicle;

[0220] The detection module 420 is used to detect whether the target vehicle has a network non-sleep segment based on the periodically acquired bus data;

[0221] The first determining module 430 is used to determine the cause of the non-sleep segment based on the device information and the bus data corresponding to the non-sleep segment when the target vehicle is detected to have the network non-sleep segment, and to determine whether the target vehicle is at risk of losing power.

[0222] The early warning module 440 is used to output early warning information based on the reason for not going into sleep mode when the target vehicle is at risk of losing power.

[0223] Optionally, the first acquisition module includes:

[0224] The first determining submodule is used to determine the actual message identifier set based on the bus data;

[0225] The second determining submodule is used to determine the design message identifier set based on the design message library corresponding to the target vehicle;

[0226] The third determining submodule is used to compare the actual message identifier set with the designed message identifier set to determine the device information.

[0227] Optionally, the bus data includes the battery current of the target vehicle; the detection module includes:

[0228] The monitoring submodule is used to monitor the battery current of the target vehicle based on the periodically acquired bus data;

[0229] The fourth determining submodule is used to determine the period when the battery current is less than the preset current threshold as the target period when the duration of the battery current being less than the preset current threshold is greater than the preset discharge duration.

[0230] The fifth determining submodule is used to determine the amount of bus data acquired during the target time period;

[0231] The sixth determining submodule is used to determine that the target vehicle has a network non-sleep segment when the number is greater than a preset number threshold, wherein the network non-sleep segment corresponds to the target time period.

[0232] Optionally, the first determining module includes:

[0233] The seventh determining submodule is used to determine the original data corresponding to the network non-sleep segment based on the device information, the bus data corresponding to the network non-sleep segment, and a preset field set; wherein, the network non-sleep segment corresponds to N bus data, the preset field set corresponds to M fields, the original data includes N sets of signals, and each set of signals includes M signals; the preset field set includes a diagnostic device identifier field and a target device identifier field; the diagnostic device identifier and target device identifier in the original data are determined based on the device information;

[0234] The eighth determination submodule is used to extract features from the raw data and determine the feature data; wherein, the feature data includes human feature data, diagnostic equipment feature data, target equipment feature data, and design electronic control unit feature data;

[0235] The ninth determining submodule is used to determine the reason for not sleeping based on the feature data.

[0236] Optionally, the ninth determination submodule includes:

[0237] The first judgment unit is used to determine whether the human feature data meets the first preset condition;

[0238] The first determining unit is configured to determine that the reason for not sleeping is a human-caused reason when the human-feature data meets the first preset condition;

[0239] The second judgment unit is used to determine whether the diagnostic device feature data meets the second preset condition when the human feature data does not meet the first preset condition.

[0240] The second determining unit is configured to determine the reason for non-dormancy as a diagnostic device reason when the diagnostic device feature data meets the second preset condition, and to determine the main diagnostic device based on the diagnostic device feature data.

[0241] The third judgment unit is used to determine whether the design electronic control unit feature data meets the third preset condition when the diagnostic device feature data does not meet the second preset condition.

[0242] The third determining unit is used to determine that the reason for not sleeping is a reason for the design electronic control unit when the characteristic data of the design electronic control unit meets the third preset condition, and to determine the main design electronic control unit based on the characteristic data of the design electronic control unit.

[0243] The fourth judgment unit is used to determine whether the target device feature data meets the fourth preset condition when the design electronic control unit feature data does not meet the third preset condition.

[0244] The fourth determining unit is configured to determine the non-sleep reason as a target device reason when the target device feature data meets the fourth preset condition, and to determine the main target device based on the target device feature data;

[0245] The fifth determining unit is used to determine the target electronic control unit with the highest non-sleep ratio based on the feature data when the target device feature data does not meet the fourth preset condition, and to determine the reason for non-sleep as the target electronic control unit.

[0246] Optionally, the human characteristic data includes first human characteristic data and second human characteristic data, and the eighth determining submodule includes:

[0247] The first extraction unit is used to extract N sets of application message signals corresponding to everyday electrical appliances from the raw data;

[0248] The first selection unit is used to select a first target application message signal from the N groups of application message signals, and to determine the number of the target application message signals as M1; wherein, the first target application message signal is an application message signal in which at least one of the human daily use electrical appliances is in working state;

[0249] The second selection unit is used to select a second target application message signal from the N groups of application message signals, and to determine the number of the target application message signals as M2; wherein, the second target application message signal is an application message signal in which at least one of the electrical appliances used by people in daily life shows a change in working status;

[0250] The sixth determining unit is used to determine the ratio of M1 to N as the first human feature data and the ratio of M2 to N as the second human feature data.

[0251] The first preset condition is that the first human feature data is greater than the first preset threshold or the second human feature data is greater than the second preset threshold.

[0252] Optionally, the eighth determination submodule includes:

[0253] The second extraction unit is used to extract N diagnostic device identifiers from the raw data;

[0254] The seventh determining unit is used to determine the number of diagnostic device identifiers among the N diagnostic device identifiers that are not the first value as D; wherein, when the device information indicates that the target vehicle does not include a diagnostic device, the diagnostic device identifier in the original data is the first value;

[0255] The eighth determining unit is used to determine the ratio of D to N as the characteristic data of the diagnostic device;

[0256] The second preset condition is that the feature data of the diagnostic device is greater than the third preset threshold.

[0257] The primary diagnostic device is the diagnostic device corresponding to the diagnostic device identifier that appears most frequently among the D diagnostic device identifiers.

[0258] Optionally, the eighth determination submodule includes:

[0259] The third extraction unit is used to extract N target device identifiers from the original data;

[0260] The ninth determining unit is used to determine the number of target device identifiers among the N target device identifiers that are not the second value as P; wherein, when the device information indicates that the target vehicle does not include the target device, the diagnostic device identifier in the original data is the second value;

[0261] The tenth determining unit is used to determine the ratio of P to N as the characteristic data of the target device;

[0262] The fourth preset condition is that the target device feature data is greater than the fourth preset threshold.

[0263] The primary target device is the target device corresponding to the target device identifier that appears most frequently among the P target device identifiers.

[0264] Optionally, the design electronic control unit feature data includes non-sleep type and wake-up feature data corresponding to each design electronic control unit in the set of design electronic control units corresponding to the target vehicle; the eighth determining submodule includes:

[0265] The type determination unit is used to determine the non-sleep type corresponding to the non-sleep segment based on the time interval between each adjacent acquisition time in the original data; wherein, when the time interval between each adjacent acquisition time is equal to the acquisition period of the bus data, the non-sleep type is determined to be a continuous non-sleep type; when at least one time interval between each adjacent acquisition time is greater than the acquisition period, the non-sleep type is determined to be a periodic wake-up non-sleep type, and the number of time intervals greater than the acquisition period is determined as the periodic wake-up count;

[0266] The fourth extraction unit is used to extract N wake-up sustaining source signals corresponding to each design electronic control unit in the set of design electronic control units from the original data;

[0267] The eleventh determining unit is used to determine the number of wake-up sustaining source signals that are not the third value and are not the fourth value among the N wake-up sustaining source signals as S;

[0268] The twelfth determining unit is used to determine the ratio of S to N as the wake-up feature data corresponding to the designed electronic control unit;

[0269] The third preset condition is that the wake-up feature data corresponding to any design electronic control unit in the set of design electronic control units is greater than the fifth preset threshold, or the number of periodic wake-ups is greater than the sixth preset threshold.

[0270] When the non-sleep type is the continuous non-sleep type, the design electronic control unit whose wake-up feature data is greater than the seventh preset threshold in the set of design electronic control units is determined as the main design electronic control unit;

[0271] When the non-sleep type is the periodic wake-up non-sleep type, the design electronic control unit whose wake-up feature data is greater than the eighth preset threshold in the set of design electronic control units is determined as the main design electronic control unit.

[0272] Optionally, the target design electronic control unit is any electronic control unit in the set of design electronic control units corresponding to the target vehicle. If the main design electronic control unit is the target design electronic control unit, after determining the reason for not going into sleep mode, the device further includes:

[0273] The second acquisition module is used to acquire historical non-dormant data of the target vehicle's model within a preset time period when the device information corresponding to the target vehicle indicates that the target vehicle is equipped with a target device.

[0274] The second determining module is used to determine, based on the historical non-sleep data records, the number of times the target-designed electronic control unit is identified as a cause of non-sleep within a preset time period;

[0275] The judgment module is used to determine, when the number of times is greater than zero, whether the target device is installed on each vehicle for which the target electronic control unit is determined to be a reason for not sleeping.

[0276] The third determining module is used to determine, if so, the reason for not sleeping as a design electronic control unit reason or a target device reason.

[0277] Optionally, the first determining module includes:

[0278] The first acquisition submodule is used to acquire the first battery capacity corresponding to the start time and the second battery capacity corresponding to the end time of the non-dormant segment of the network, and determine the battery discharge amount based on the first battery capacity and the second battery capacity.

[0279] The second acquisition submodule is used to acquire the minimum battery voltage corresponding to the non-dormant segment of the network.

[0280] The tenth determination submodule is used to determine the cumulative number of occurrences of the cause of non-sleep within a preset time period based on historical non-sleep data;

[0281] The battery depletion determination submodule is used to determine that the target vehicle is at risk of battery depletion when the battery discharge exceeds a preset threshold, or the minimum battery voltage is less than a preset voltage threshold, or the cumulative occurrence count exceeds a preset number of occurrences threshold.

[0282] The battery drain risk monitoring device provided in this application embodiment achieves the following technical effects: This application embodiment comprehensively monitors network activity and device status after the vehicle is powered off, identifies various reasons causing the network to not sleep, assesses the risk of battery drain, and finally outputs targeted early warning information. It achieves proactive prevention and control of vehicle battery drain risk, overcoming the limitations of traditional methods in identifying non-original equipment and locating causes, preventing the vehicle from failing to start due to battery depletion, ensuring normal vehicle operation, and improving user experience.

[0283] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0284] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0285] Example 3

[0286] This application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described power loss risk monitoring method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0287] For example, Figure 5 A schematic diagram of the physical structure of an electronic device is shown. (For example...) Figure 5 As shown, the electronic device 50 may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 440, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 can call logic instructions in the memory 530. The processor 510 is used to perform the following steps: after the target vehicle is powered off, periodically acquire the bus data of the target vehicle, and determine the device information based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose the target vehicle's faults; based on the periodically acquired bus data, detect whether the target vehicle has a network non-sleep segment; when the target vehicle is detected to have a network non-sleep segment, determine the cause of the non-sleep segment based on the device information and the bus data corresponding to the network non-sleep segment, and determine whether the target vehicle is at risk of losing power; when the target vehicle is at risk of losing power, output warning information based on the cause of the non-sleep segment. The processor 510 can also execute other schemes in the embodiments of this application, which will not be further described here.

[0288] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0289] Example 4

[0290] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described power loss risk monitoring method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0291] In this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0292] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0293] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0294] In this application, "multiple" refers to two or more.

[0295] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0296] The terms “first,” “second,” “third,” “fourth,” etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0297] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0298] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0299] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for monitoring power outage risk, applied to a power outage risk monitoring system, characterized in that, The power loss risk monitoring system is used to monitor the power loss risk of multiple vehicles, and the method includes: After the target vehicle is powered off, the bus data of the target vehicle is periodically acquired, and the device information is determined based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose faults in the target vehicle; Based on the periodically acquired bus data, detect whether the target vehicle experiences network non-sleep segments; When the target vehicle is detected to have a network non-sleep segment, the cause of the non-sleep segment is determined based on the device information and the bus data corresponding to the network non-sleep segment, and it is determined whether the target vehicle is at risk of losing power. When the target vehicle is at risk of battery depletion, a warning message is output based on the reason for not going into sleep mode.

2. The power loss risk monitoring method according to claim 1, characterized in that, Device information is determined based on the bus data, including: Based on the bus data, determine the actual message identifier set; Based on the design message library corresponding to the target vehicle, determine the set of design message identifiers; The device information is determined by comparing the actual message identifier set with the designed message identifier set.

3. The power loss risk monitoring method according to claim 1, characterized in that, The bus data includes the battery current of the target vehicle; Based on the periodically acquired bus data, detect whether the target vehicle experiences network non-sleep segments, including: Based on the periodically acquired bus data, the battery current of the target vehicle is monitored; When the duration during which the battery current is less than a preset current threshold is greater than a preset discharge duration, the duration during which the battery current is less than the preset current threshold is determined as the target period. Determine the amount of bus data acquired during the target time period; When the number exceeds a preset threshold, it is determined that the target vehicle has a network non-sleep segment, wherein the network non-sleep segment corresponds to the target time period.

4. The power loss risk monitoring method according to claim 1, characterized in that, Based on the device information and the bus data corresponding to the non-sleep segment of the network, the reason for non-sleep is determined, including: Based on the device information, the bus data corresponding to the non-sleep network segment, and a preset field set, the original data corresponding to the non-sleep network segment is determined; wherein, the non-sleep network segment corresponds to N bus data, the preset field set corresponds to M fields, and the original data includes N sets of signals, each set of signals including M signals; the preset field set includes a diagnostic device identifier field and a target device identifier field; the diagnostic device identifier and target device identifier in the original data are determined based on the device information; Feature extraction is performed on the raw data to determine the feature data; wherein, the feature data includes human feature data, diagnostic equipment feature data, target equipment feature data, and design electronic control unit feature data; Based on the aforementioned feature data, the reason for not going into hibernation is determined.

5. The power loss risk monitoring method according to claim 4, characterized in that, Based on the aforementioned feature data, the reasons for not hibernating are determined, including: Determine whether the human feature data meets the first preset condition; When the human-related characteristic data meets the first preset condition, the reason for not sleeping is determined to be human-related. When the human characteristic data does not meet the first preset condition, it is determined whether the diagnostic device characteristic data meets the second preset condition; When the diagnostic device feature data meets the second preset condition, the reason for not going into sleep mode is determined to be a diagnostic device reason, and the main diagnostic device is determined based on the diagnostic device feature data; When the diagnostic device feature data does not meet the second preset condition, it is determined whether the design electronic control unit feature data meets the third preset condition. When the design electronic control unit feature data meets the third preset condition, the reason for not sleeping is determined to be a design electronic control unit reason, and the main design electronic control unit is determined according to the design electronic control unit feature data; When the design electronic control unit feature data does not meet the third preset condition, it is determined whether the target device feature data meets the fourth preset condition; When the target device feature data meets the fourth preset condition, the reason for not sleeping is determined to be a target device reason, and the main target device is determined based on the target device feature data; When the target device feature data does not meet the fourth preset condition, the target electronic control unit with the highest non-sleep ratio is determined based on the feature data, and the reason for non-sleep is determined to be the target electronic control unit.

6. The power loss risk monitoring method according to claim 5, characterized in that, The human feature data includes first human feature data and second human feature data. Feature extraction is performed on the original data to determine the feature data, including: Extract N sets of application message signals corresponding to everyday electrical appliances from the raw data; A first target application message signal is selected from the N groups of application message signals, and the number of the target application message signals is determined to be M1; wherein, the first target application message signal is an application message signal in which at least one of the everyday electrical appliances is in working condition; A second target application message signal is selected from the N groups of application message signals, and the number of the target application message signals is determined to be M2; wherein, the second target application message signal is an application message signal in which at least one of the electrical appliances used by people in daily life shows a change in working status; The ratio of M1 to N is determined as the first human characteristic data, and the ratio of M2 to N is determined as the second human characteristic data. The first preset condition is that the first human feature data is greater than the first preset threshold or the second human feature data is greater than the second preset threshold.

7. The power loss risk monitoring method according to claim 5, characterized in that, Feature extraction is performed on the raw data to determine the feature data, including: Extract N diagnostic device identifiers from the raw data; The number of diagnostic device identifiers among the N diagnostic device identifiers that are not the first value is determined as D; wherein, when the device information indicates that the target vehicle does not include a diagnostic device, the diagnostic device identifier in the original data is the first value; The ratio of D to N is determined as the characteristic data of the diagnostic device; The second preset condition is that the feature data of the diagnostic device is greater than the third preset threshold. The primary diagnostic device is the diagnostic device corresponding to the diagnostic device identifier that appears most frequently among the D diagnostic device identifiers.

8. The power loss risk monitoring method according to claim 5, characterized in that, Feature extraction is performed on the raw data to determine the feature data, including: Extract N target device identifiers from the raw data; The number of target device identifiers among the N target device identifiers that are not the second value is determined as P; wherein, when the device information indicates that the target vehicle does not include the target device, the diagnostic device identifier in the original data is the second value; The ratio of P to N is determined as the characteristic data of the target device; The fourth preset condition is that the target device feature data is greater than the fourth preset threshold. The primary target device is the target device corresponding to the target device identifier that appears most frequently among the P target device identifiers.

9. The power loss risk monitoring method according to claim 5, characterized in that, The design electronic control unit feature data includes the non-sleep type and the wake-up feature data corresponding to each design electronic control unit in the set of design electronic control units corresponding to the target vehicle; Feature extraction is performed on the raw data to determine the feature data, including: Based on the time interval between each adjacent acquisition time in the original data, the non-sleep type corresponding to the non-sleep segment is determined; wherein, when the time interval between each adjacent acquisition time is equal to the acquisition cycle of the bus data, the non-sleep type is determined to be a continuous non-sleep type; when at least one time interval between each adjacent acquisition time is greater than the acquisition cycle, the non-sleep type is determined to be a periodic wake-up non-sleep type, and the number of time intervals greater than the acquisition cycle is determined as the periodic wake-up count. For each design electronic control unit in the set of design electronic control units, extract N wake-up sustaining source signals corresponding to the design electronic control unit from the original data; The number of wake-up sustaining source signals that are neither the third nor the fourth value among the N wake-up sustaining source signals is determined as S; The ratio of S to N is determined as the wake-up characteristic data corresponding to the designed electronic control unit; The third preset condition is that the wake-up feature data corresponding to any design electronic control unit in the set of design electronic control units is greater than the fifth preset threshold, or the number of periodic wake-ups is greater than the sixth preset threshold. When the non-sleep type is the continuous non-sleep type, the design electronic control unit whose wake-up feature data is greater than the seventh preset threshold in the set of design electronic control units is determined as the main design electronic control unit; When the non-sleep type is the periodic wake-up non-sleep type, the design electronic control unit whose wake-up feature data is greater than the eighth preset threshold in the set of design electronic control units is determined as the main design electronic control unit.

10. The power loss risk monitoring method according to claim 5, characterized in that, The target electronic control unit is any electronic control unit in the set of design electronic control units corresponding to the target vehicle. When the main design electronic control unit is the target electronic control unit, after determining the reason for not going into sleep mode, the method further includes: When the device information corresponding to the target vehicle indicates that the target vehicle is equipped with a target device, the historical non-dormant data of the target vehicle model to which the target vehicle belongs within a preset time period is obtained. Based on the historical non-sleep data records, determine the number of times the target-designed electronic control unit was identified as a cause of non-sleep within a preset time period; When the number of times is greater than zero, it is determined whether the target device is installed on each vehicle for which the target electronic control unit is identified as not sleeping. If so, the reason for not going into sleep mode will be determined to be due to the design of the electronic control unit or the target device.

11. The power loss risk monitoring method according to claim 1, characterized in that, Determining whether the target vehicle is at risk of battery depletion includes: Obtain the first battery capacity corresponding to the start time and the second battery capacity corresponding to the end time of the non-dormant segment of the network, and determine the battery discharge amount based on the first battery capacity and the second battery capacity; Obtain the minimum battery voltage corresponding to the non-dormant segment of the network; Based on historical non-dormant data, determine the cumulative number of occurrences of the non-dormant cause within a preset time period; When the battery discharge exceeds a preset threshold, or the minimum battery voltage is less than a preset voltage threshold, or the cumulative number of occurrences exceeds a preset number of occurrences threshold, it is determined that the target vehicle is at risk of battery depletion.

12. A power outage risk monitoring device, applied to a power outage risk monitoring system, characterized in that, The power loss risk monitoring system is used to monitor the power loss risk of multiple vehicles, and the device includes: The first acquisition module is used to periodically acquire the bus data of the target vehicle after the target vehicle is powered off, and determine the device information based on the bus data; wherein, the target vehicle is any one of the multiple vehicles, the device information is used to indicate whether the target vehicle is equipped with a target device and a diagnostic device, the target device and the diagnostic device are different from the original equipment of the target vehicle, the target device is a device added after the target vehicle leaves the factory, and the diagnostic device is used to diagnose the faults of the target vehicle; The detection module is used to detect whether the target vehicle has a network non-sleep segment based on the periodically acquired bus data; The first determining module is used to determine the cause of the non-sleep segment based on the device information and the bus data corresponding to the non-sleep segment when the target vehicle is detected to have the network non-sleep segment, and to determine whether the target vehicle is at risk of losing power. The early warning module is used to output early warning information based on the reason for not going into sleep mode when the target vehicle is at risk of battery depletion.

13. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the power loss risk monitoring method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the power loss risk monitoring method as described in any one of claims 1 to 11.

Images