Vehicle monitoring method and device, electronic equipment and vehicle

Abstract

The embodiment of the invention provides a vehicle monitoring method and device, electronic equipment and a vehicle, if a bus is in a dormant state, a storage battery and a control unit are monitored, and the remaining electric quantity of the storage battery and self-diagnosis information of the control unit are obtained; if the residual electric quantity is smaller than a preset electric quantity threshold value and the dormancy duration of the bus in the dormancy state is smaller than a preset dormancy duration threshold value, waking up the bus from the dormancy state so as to enable the bus to be in communication connection with a cloud platform; and uploading the abnormal power consumption information of the control unit to a cloud platform. According to the embodiment of the invention, localized and active power consumption monitoring in the bus dormant state is realized, the state recording of the abnormal power consumption control unit can be completed, the control unit with abnormal power consumption can be accurately positioned, and the problem of abnormal power consumption of the vehicle can be more efficiently solved. Based on the embodiment of the invention, the invalid power consumption of the storage battery can be effectively reduced, and the vehicle parking time is prolonged.

Description

Technical Field

[0001] This application relates to the field of equipment management technology, and in particular to a vehicle monitoring method, device, electronic device, and vehicle. Background Technology

[0002] Currently, the main function of vehicle bus power consumption monitoring algorithms is to passively monitor high-energy consumption scenarios caused by abnormal awakening of the bus after it has entered a sleep state. For example, when the entertainment system actively continues to work, or when a control unit (ECU) is unable to enter a preset low-power mode due to a defect, the algorithm can identify the resulting abnormal bus communication activities and associated additional power consumption.

[0003] However, when the bus itself is in a sleep state, this method cannot effectively monitor abnormal power consumption behavior of each control unit on the bus that may occur due to internal logic anomalies (such as continuous communication monitoring or redundant functional modules not being shut down as required). At the same time, the monitoring system deployed on the remote cloud platform also has difficulty obtaining the internal state of each control unit during the bus sleep state, thus making it impossible to locate the specific control unit with abnormal power consumption. Summary of the Invention

[0004] This application provides a vehicle monitoring method, device, electronic device, and vehicle, which aims to solve or partially solve the above-mentioned technical problems.

[0005] To address the aforementioned problems, this application discloses a vehicle monitoring method, wherein the vehicle has a battery, a bus, and a control unit deployed on the bus, the method comprising: If the bus is in a sleep state, the battery and the control unit are monitored to obtain the remaining power of the battery and the self-diagnostic information of the control unit. The self-diagnostic information includes abnormal power consumption information of the control unit. If the remaining power is less than a preset power threshold, and the sleep duration of the bus in the sleep state is less than a preset sleep duration threshold, then the bus will be woken up from the sleep state so that the bus can communicate with the cloud platform. The abnormal power consumption information of the control unit is uploaded to the cloud platform.

[0006] In this embodiment, if the bus is in a sleep state, the battery and control unit are monitored to obtain the remaining battery power and the self-diagnostic information of the control unit, including abnormal power consumption information of the control unit. If the remaining power is less than a preset power threshold and the sleep duration of the bus is less than a preset sleep duration threshold, the bus is woken up from the sleep state to enable communication between the bus and the cloud platform. The abnormal power consumption information of the control unit is uploaded to the cloud platform. This embodiment achieves localized, proactive power consumption monitoring in the bus sleep state by having the control unit continuously monitor its own status and generate self-diagnostic information during bus sleep, and actively waking up the bus to report abnormal power consumption information to the cloud platform when the preset conditions of remaining power and sleep duration are met. Simultaneously, by uploading the abnormal power consumption information obtained by the control unit's self-diagnosis to the cloud platform, the status of the abnormal power consumption control unit can be recorded, which is beneficial for accurately locating the abnormal power consumption control unit and thus more efficiently solving the vehicle's abnormal power consumption problem. Based on this embodiment, ineffective battery power consumption can be effectively reduced, extending vehicle parking time.

[0007] Optionally, the control unit has a low-power mode, a local mode, and a network mode. The low-power mode is a mode in which the control unit is not connected to the network and is not in operation. The local mode is a mode in which the control unit is not connected to the network and is in operation. The network mode is a mode in which the control unit is connected to the network and is in operation. Before monitoring the battery and the control unit, the method includes: In response to a sleep command, the bus is switched to sleep mode; In response to the bus switching to the sleep state, the control unit is controlled to switch from the network mode to the local mode; The control unit is controlled to switch from the local mode to the low-power mode within a preset time.

[0008] In this embodiment, after the bus enters a sleep state, the control unit is switched from network mode to local mode, and further switched from local mode to low power mode, so as to ensure that the control unit is in a low power state for most of the time or during the long-term static period of the vehicle, thus meeting the requirements of long-term vehicle parking.

[0009] Optionally, monitoring the control unit to obtain its self-diagnostic information includes: If the control unit does not switch from the local mode to the low-power mode within a preset time, the non-sleep time of the control unit in the local mode is recorded. If the non-sleep duration reaches a preset abnormal duration threshold, then the non-sleep data of the control unit is obtained; The non-sleep data is used as abnormal power consumption information for the control unit.

[0010] In this embodiment, when the control unit is in local mode for a long time and has not entered low-power mode, it is determined that the control unit has abnormal power consumption. The corresponding abnormal power consumption information is recorded. After waking up the bus, the abnormal power consumption information obtained by the control unit's self-diagnosis is uploaded to the cloud platform, completing the status recording of the control unit with abnormal power consumption. This is beneficial for accurately locating the control unit with abnormal power consumption, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0011] Optionally, monitoring the control unit to obtain its self-diagnostic information includes: If the number of times the control unit switches from the low-power mode to the local mode after switching to the low-power mode reaches a preset abnormal wake-up threshold, then the abnormal wake-up data of the control unit is obtained. The abnormal wake-up data is used as abnormal power consumption information of the control unit.

[0012] In this embodiment, when the control unit is repeatedly woken up after entering low-power mode, it is determined that the control unit has abnormal power consumption. The corresponding abnormal power consumption information is recorded. After waking up the bus, the abnormal power consumption information obtained by the control unit's self-diagnosis is uploaded to the cloud platform, completing the status recording of the abnormal power consumption control unit. This is beneficial for accurately locating the control unit with abnormal power consumption, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0013] Optionally, after switching the bus to a sleep state in response to a sleep command, the method further includes: If a control unit fails to respond to the switching of the sleep state of the bus, then obtain the node information of the unresponsive control unit; The node information of the unresponsive control unit is uploaded to the cloud platform.

[0014] In this embodiment of the application, if the control unit does not respond to the operation of switching from network mode to local mode and then further from local mode to low power mode after the bus enters sleep mode, the unresponsive control unit is determined to be an abnormal control unit. The node information of the unresponsive control unit is uploaded to the cloud platform to complete the status recording of the abnormal control unit. This is beneficial for accurately locating the abnormal control unit, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0015] Optionally, the vehicle includes an onboard telematics processor, and waking the bus from the sleep state includes: In response to the bus waking up from the sleep state, the control unit switches from the low-power mode to the network mode; Uploading the abnormal power consumption information of the control unit to the cloud platform includes: When the control unit is in the network mode, it is controlled to send the abnormal power consumption information to the vehicle telematics processor. The vehicle-mounted remote information processor is controlled to upload the abnormal power consumption information to the cloud platform.

[0016] In this embodiment, while the control unit monitors its own status, the vehicle-mounted telematics processor monitors the abnormal power consumption information issued by the control unit and uploads the abnormal power consumption information to the cloud platform, thus constructing a two-layer monitoring mechanism of the control unit and the vehicle-mounted telematics processor, thereby realizing the accurate location and status recording of the control unit with abnormal power consumption.

[0017] Optionally, the abnormal power consumption information includes an alarm signal, an abnormal wake-up source signal and timestamp information corresponding to the abnormal wake-up source signal, and / or an abnormal sustaining source signal and timestamp information corresponding to the abnormal sustaining source signal.

[0018] In this application embodiment, alarm signals, abnormal wake-up source signals and timestamp information corresponding to abnormal wake-up source signals, and / or abnormal sustaining source signals and timestamp information corresponding to abnormal sustaining source signals are recorded as abnormal power consumption information, which helps in the subsequent fault location of the abnormal power consumption control unit.

[0019] This application also discloses a vehicle monitoring device, the vehicle having a battery, a bus, and a control unit deployed on the bus, the device comprising: The monitoring module is used to monitor the battery and the control unit if the bus is in a sleep state, and obtain the remaining power of the battery and the self-diagnostic information of the control unit, the self-diagnostic information including abnormal power consumption information of the control unit; The wake-up module is used to wake up the bus from the sleep state if the remaining power is less than a preset power threshold and the sleep time of the bus in the sleep state is less than a preset sleep time threshold, so that the bus can communicate with the cloud platform. The reporting module is used to upload the abnormal power consumption information of the control unit to the cloud platform.

[0020] This application also discloses an electronic device, including a processor and a memory, wherein the memory is used to store computer programs; and the processor is used to execute the programs stored in the memory to implement one or more vehicle monitoring methods as described in the embodiments of this application.

[0021] This application also discloses a vehicle that includes electronic devices as described in the embodiments of this application. Attached Figure Description

[0022] Figure 1 This is a flowchart of a vehicle monitoring method provided in one embodiment of this application; Figure 2 This is a schematic diagram of non-dormant data recording in a vehicle monitoring method provided in an embodiment of this application; Figure 3 This is a schematic diagram of abnormal wake-up data recording in a vehicle monitoring method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the system structure of a vehicle monitoring method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the power consumption monitoring method for a vehicle provided in one embodiment of this application. Figure 6 This is a flowchart of an abnormal power consumption handling method for a vehicle monitoring method provided in an embodiment of this application; Figure 7 This is a structural diagram of the vehicle monitoring device provided in the embodiments of this application; Figure 8 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0023] 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.

[0024] Currently, the main function of vehicle bus power consumption monitoring algorithms is to passively monitor high-energy consumption scenarios caused by abnormal awakening of the bus after it has entered a sleep state. For example, when the entertainment system actively continues to work, or when a control unit (ECU) is unable to enter a preset low-power mode due to a defect, the algorithm can identify the resulting abnormal bus communication activities and associated additional power consumption.

[0025] Specifically, existing bus control unit power consumption monitoring schemes generally fall into the following categories, but all have certain drawbacks: some only detect power consumption after all control units have entered sleep mode, failing to identify abnormal power consumption that persists after sleep mode; some rely on intelligent high-side chips to monitor current for power consumption detection, but this only covers a local circuit and is costly; some monitor the operating status of on-board equipment and perform self-reset via heartbeat packets, but do not address power consumption anomalies in bus sleep mode scenarios; and others record control unit state transitions to help locate the cause of non-sleep mode, which is also unsuitable for power consumption issues after bus sleep mode. Therefore, existing methods are all insufficient for comprehensively and cost-effectively monitoring and resolving power consumption anomalies in the entire vehicle during bus sleep mode.

[0026] Therefore, when the bus itself is in a dormant state, existing vehicle bus power consumption monitoring algorithms cannot effectively monitor abnormal power consumption behavior that may occur in each control unit on the bus due to internal logic anomalies (such as continuous communication monitoring or redundant functional modules not being shut down as required). At the same time, monitoring systems deployed on remote cloud platforms also have difficulty obtaining the internal state of each control unit during the bus dormant state, thus making it impossible to locate the specific control unit with abnormal power consumption.

[0027] To this end, some embodiments of this application construct a hierarchical monitoring mechanism, a dual-threshold triggering strategy, a data storage and recovery system, and remotely upload data to the cloud to achieve accurate location and status recording of abnormal power consumption nodes, effectively reducing ineffective power consumption of the battery and extending vehicle parking time.

[0028] Specifically, this application provides a vehicle monitoring method, wherein the vehicle has a battery, a bus, and a control unit deployed on the bus. The method includes: if the bus is in a sleep state, monitoring the battery and the control unit to obtain the remaining power of the battery and the self-diagnostic information of the control unit, the self-diagnostic information including abnormal power consumption information of the control unit; if the remaining power is less than a preset power threshold, and the sleep duration of the bus in the sleep state is less than a preset sleep duration threshold, waking the bus from the sleep state to enable the bus to communicate with the cloud platform; and uploading the abnormal power consumption information of the control unit to the cloud platform.

[0029] This application embodiment achieves localized, proactive power consumption monitoring during bus sleep mode by having the control unit continuously monitor its own status and generate self-diagnostic information. When preset conditions of remaining battery power and sleep duration are met, the control unit actively wakes up the bus to report abnormal power consumption information to the cloud platform. Simultaneously, by uploading the abnormal power consumption information obtained from the control unit's self-diagnosis to the cloud platform, the status of the control unit with abnormal power consumption can be recorded, facilitating accurate location of the control unit with abnormal power consumption and thus more efficiently resolving vehicle power consumption anomalies. Based on this application embodiment, ineffective battery power consumption can be effectively reduced, extending vehicle parking time.

[0030] Example 1 This application provides a vehicle monitoring method, please refer to... Figure 1 This includes the following steps: S110: If the bus is in a sleep state, monitor the battery and the control unit to obtain the remaining power of the battery and the self-diagnostic information of the control unit. The self-diagnostic information includes abnormal power consumption information of the control unit.

[0031] In this embodiment, the vehicle has a bus, which may be a CAN (Controller Area Network) bus. The bus has multiple control unit nodes, each corresponding to a control unit. In one embodiment, the control unit may include an IBCM (Integrated Body Control Module). The control unit has an MCU (Micro-controller Unit), which is the main chip of the control unit, and the code execution of the control unit is performed within the MCU.

[0032] The vehicle also has a battery and a corresponding Electronic Battery Sensor (EBS) to obtain the remaining battery power.

[0033] In this embodiment, when the vehicle is stopped, powered off, and the engine is turned off, the entire vehicle enters a sleep state, and the vehicle's bus also enters a sleep state. Under normal circumstances, when the bus enters a sleep state, all control units on the bus also enter a low-power mode. However, if a fault or other abnormal situation occurs, after the bus enters a sleep state, the control unit experiencing the abnormal situation will not respond by switching to a low-power mode, or it may remain in local mode for a long time without switching to a low-power mode, or it may repeatedly switch between local mode and low-power mode, thereby causing abnormal power consumption and resulting in faster battery depletion.

[0034] In step S110 of this embodiment, after the bus enters sleep mode, the battery and control unit need to be monitored. Specifically, a gateway controller (GWM) can be deployed on the vehicle. The gateway controller receives voltage signals from the battery sensors to monitor the battery voltage status in real time, determine the remaining battery power, and use this information to determine whether the vehicle's power consumption is abnormal. Each control unit monitors whether it is in a normal low-power state. If the control unit is not in a normal low-power state, it generates corresponding abnormal power consumption information as self-diagnostic information for that control unit.

[0035] In one embodiment, the control unit can first store the self-diagnostic information and then upload it when the bus is woken up again, i.e. when the whole vehicle is woken up.

[0036] S120: If the remaining power is less than a preset power threshold, and the sleep duration of the bus in the sleep state is less than a preset sleep duration threshold, then the bus is woken up from the sleep state so that the bus can communicate with the cloud platform.

[0037] In step S120, when the vehicle is stopped and the bus enters a sleep state, if the remaining battery power is less than a preset power threshold and the current sleep time of the bus in the sleep state is less than a preset sleep time threshold, the entire vehicle will be woken up once to wake up the bus from the sleep state so that the bus can communicate with the cloud platform and allow the control units of each node to upload their respective self-diagnostic information.

[0038] In one embodiment, the bus can be woken up from its sleep state by sending a wake-up command through the gateway controller.

[0039] S130: Upload the abnormal power consumption information of the control unit to the cloud platform.

[0040] In step S130, after the bus is woken up, the control unit on the bus switches to network mode. In network mode, the control unit can upload its self-diagnostic information, including abnormal power consumption information, to the cloud platform. The cloud platform then issues abnormal power consumption alarms and notifies abnormal power consumption events. At the same time, the abnormal power consumption information is used by technicians to analyze the cause of abnormal vehicle power consumption.

[0041] In one embodiment, the cloud platform can be a TSP (Telematics Service Provider), which is a cloud platform used to provide vehicle networking service functions, support big data business, and provide support for vehicle research and development, production, sales, and after-sales service.

[0042] This application embodiment achieves localized, proactive power consumption monitoring during bus sleep mode by having the control unit continuously monitor its own status and generate self-diagnostic information. When preset conditions of remaining battery power and sleep duration are met, the control unit actively wakes up the bus to report abnormal power consumption information to the cloud platform. Simultaneously, by uploading the abnormal power consumption information obtained from the control unit's self-diagnosis to the cloud platform, the status of the control unit with abnormal power consumption can be recorded, facilitating accurate location of the control unit with abnormal power consumption and thus more efficiently resolving vehicle power consumption anomalies. Based on this application embodiment, ineffective battery power consumption can be effectively reduced, extending vehicle parking time.

[0043] Optionally, the control unit has a low-power mode, a local mode, and a network mode. The low-power mode is a mode in which the control unit is not connected to the network and is not in operation. The local mode is a mode in which the control unit is not connected to the network and is in operation. The network mode is a mode in which the control unit is connected to the network and is in operation. Before monitoring the battery and the control unit, the method includes: In response to a sleep command, the bus is switched to sleep mode; In response to the bus switching to the sleep state, the control unit is controlled to switch from the network mode to the local mode; The control unit is controlled to switch from the local mode to the low-power mode within a preset time.

[0044] In this embodiment, the control unit includes a low-power mode and a high-power operating mode, wherein the operating mode is further divided into a local mode and a network mode.

[0045] Specifically, low-power mode refers to a mode in which the control unit remains in a low-power state for most of the time during long periods of vehicle inactivity, in order to meet the requirements of long-term vehicle parking. During this period, the control unit is not connected to the network and is not in operation, and the control unit's MCU is also not in operation.

[0046] Local mode is one of the sub-modes of operating modes categorized by the scope of influence of the control unit, corresponding to network mode. When the control unit is in local mode, it can only execute the functions of its own modules and auxiliary devices, and cannot connect to the network, but the MCU is still operational. A significant characteristic of local mode is that the control unit does not send network messages unless it is in a network BUS OFF state (an error state of the control unit).

[0047] Network mode is one of the sub-modes of operating modes categorized by the scope of influence of the control unit, corresponding to local mode. When the control unit is in network mode, at least one control unit on the bus network needs to communicate with the entire vehicle network. The control unit's network is active, and it is also in working condition. A significant characteristic of network mode is that the control unit can send network messages. Even when the network bus is OFF, it should still be determined that the control unit is in network mode.

[0048] In this embodiment, the control unit is in network mode when the bus is active. After the bus enters sleep mode, the control unit first switches from network mode to local mode. At this time, the MCU of the control unit is still active, but the control unit is not connected to the network. The control unit then switches from local mode to low-power mode within a preset time. In this mode, the control unit is neither active nor connected to the network, in order to reduce power consumption during bus sleep. For example, the preset time can be 5 minutes.

[0049] In this embodiment, after the bus enters a sleep state, the control unit is switched from network mode to local mode, and further switched from local mode to low power mode, so as to ensure that the control unit is in a low power state for most of the time or during the long-term static period of the vehicle, thus meeting the requirements of long-term vehicle parking.

[0050] Optionally, monitoring the control unit to obtain its self-diagnostic information includes: If the control unit does not switch from the local mode to the low-power mode within a preset time, the non-sleep time of the control unit in the local mode is recorded. If the non-sleep duration reaches a preset abnormal duration threshold, then the non-sleep data of the control unit is obtained; The non-sleep data is used as abnormal power consumption information for the control unit.

[0051] This application embodiment records abnormal power consumption information of the control unit using a dual-threshold triggering strategy. One of the dual-threshold triggering strategies is to record abnormal power consumption information when the control unit does not enter a low-power mode for an extended period of time.

[0052] Specifically, upon receiving a command to enter sleep mode, the bus enters sleep mode. Under normal circumstances, the control unit should switch from network mode to local mode, and then further switch from local mode to low-power mode within a preset time. If the control unit fails to switch from local mode to low-power mode within the preset time, i.e., the control unit remains in local mode for an extended period, the non-sleep time of the control unit in local mode is recorded. The non-sleep time is the duration during which the control unit fails to switch from local mode to low-power mode after the preset time.

[0053] When the non-sleep duration reaches a preset abnormal duration threshold—that is, after a preset time during which the device has not switched from local mode to low-power mode—the controller triggers local long-term non-sleep data recording. This records the non-sleep data of the control unit as abnormal power consumption information for that control unit and uploads it to the cloud platform the next time the bus is woken up. In one example, the preset abnormal duration threshold can be 60 minutes, which can be set according to actual needs and the normal functioning of the control unit.

[0054] In one example, after recording non-sleep data, the controller's timer can be reset to zero, so that the next time the control unit malfunctions and does not sleep, the timer can be triggered to start from 0.

[0055] Reference Figure 2 This is a schematic diagram of non-dormant data recording in a vehicle monitoring method provided in an embodiment of this application.

[0056] like Figure 2 As shown, the acquired non-sleep data can be uploaded to the cloud platform. The non-sleep data obtained by the user from the cloud platform can be in tabular form. The non-sleep data can include timestamps (year, month, day, hour, minute, second) and maintenance source information of the control unit to maintain local mode (represented in the table by wake-up source under low power).

[0057] In this embodiment, when the control unit is in local mode for a long time and has not entered low-power mode, it is determined that the control unit has abnormal power consumption. The corresponding abnormal power consumption information is recorded. After waking up the bus, the abnormal power consumption information obtained by the control unit's self-diagnosis is uploaded to the cloud platform, completing the status recording of the control unit with abnormal power consumption. This is beneficial for accurately locating the control unit with abnormal power consumption, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0058] Optionally, monitoring the control unit to obtain its self-diagnostic information includes: If the number of times the control unit switches from the low-power mode to the local mode after switching to the low-power mode reaches a preset abnormal wake-up threshold, then the abnormal wake-up data of the control unit is obtained. The abnormal wake-up data is used as abnormal power consumption information of the control unit.

[0059] This application embodiment records abnormal power consumption information of the control unit using a dual-threshold triggering strategy. One of the dual-threshold triggering strategies is to record abnormal power consumption information when the control unit is repeatedly woken up and switched to local mode after being in a low-power mode for a long time.

[0060] Specifically, upon receiving a command to enter sleep mode, the bus enters sleep mode. Under normal circumstances, the control unit should switch from network mode to local mode, and then further switch from local mode to low-power mode within a preset time, thus maintaining its position in low-power mode. If, after switching to low-power mode, the control unit fails to maintain its position in low-power mode as expected and instead switches back to local mode, the number of abnormal wake-ups during this transition is recorded. The abnormal wake-up count is the number of times the control unit is woken up when it fails to maintain its position in low-power mode and instead switches back to local mode.

[0061] When the number of abnormal wake-ups reaches a preset abnormal wake-up threshold—that is, after the bus goes to sleep, the control unit switches to low-power mode, and then the number of abnormal wake-ups from low-power mode to local mode reaches the preset threshold—the controller triggers local abnormal wake-up data recording. This records the abnormal wake-up data of the control unit as abnormal power consumption information for that control unit and uploads it to the cloud platform the next time the bus is woken up. In one example, the preset abnormal wake-up threshold can be 20 times, which can be set according to actual needs and the normal functioning of the control unit.

[0062] In one example, after recording the abnormal wake-up data, the controller's count can be reset to zero, so that the next time the control unit wakes up abnormally, it can trigger a count starting from 0.

[0063] Reference Figure 3 This is a schematic diagram of abnormal wake-up data recording in a vehicle monitoring method provided in an embodiment of this application.

[0064] like Figure 3 As shown, the acquired abnormal wake-up data can be uploaded to the cloud platform. The abnormal wake-up data obtained by the user from the cloud platform can be in tabular form. The abnormal wake-up data can include timestamps (year, month, day, hour, minute, second) and wake-up sources of the control unit that are woken up in low power mode.

[0065] In this embodiment, when the control unit is repeatedly woken up after entering low-power mode, it is determined that the control unit has abnormal power consumption. The corresponding abnormal power consumption information is recorded. After waking up the bus, the abnormal power consumption information obtained by the control unit's self-diagnosis is uploaded to the cloud platform, completing the status recording of the abnormal power consumption control unit. This is beneficial for accurately locating the control unit with abnormal power consumption, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0066] Optionally, the abnormal power consumption information includes an alarm signal, an abnormal wake-up source signal and timestamp information corresponding to the abnormal wake-up source signal, and / or an abnormal sustaining source signal and timestamp information corresponding to the abnormal sustaining source signal.

[0067] In this embodiment, if the abnormal power consumption information is obtained from the non-sleep data, the abnormal power consumption information may include an alarm signal, an abnormal maintenance source signal, and the timestamp information corresponding to the abnormal maintenance source signal. The alarm signal is an alarm prompt for the control unit to abnormally not enter sleep mode, the abnormal maintenance source signal is the maintenance source information collected by the control unit that causes the control unit not to enter the low power mode, and the timestamp information corresponding to the abnormal maintenance source signal is the occurrence time information of the maintenance source.

[0068] If the abnormal power consumption information is obtained from abnormal wake-up data, the abnormal power consumption information may include the abnormal wake-up source signal and the timestamp information corresponding to the abnormal wake-up source signal. The alarm signal is an alarm prompt for the control unit to wake up abnormally frequently. The abnormal wake-up source signal is the wake-up source information collected by the control unit that causes the control unit to be frequently woken up from low-power mode. The timestamp information corresponding to the abnormal wake-up source signal is the occurrence time of the wake-up source.

[0069] In this application embodiment, alarm signals, abnormal wake-up source signals and timestamp information corresponding to abnormal wake-up source signals, and / or abnormal sustaining source signals and timestamp information corresponding to abnormal sustaining source signals are recorded as abnormal power consumption information, which helps in the subsequent fault location of the abnormal power consumption control unit.

[0070] Optionally, after switching the bus to a sleep state in response to a sleep command, the method further includes: If a control unit fails to respond to the switching of the sleep state of the bus, then obtain the node information of the unresponsive control unit; The node information of the unresponsive control unit is uploaded to the cloud platform.

[0071] In this embodiment, in addition to the two abnormal power consumption situations during bus sleep described above, abnormal power consumption may also be caused by the control unit's inability to respond to the bus entering sleep mode and switch modes.

[0072] Specifically, under normal circumstances, when the bus switches to sleep mode, the control unit should respond to the bus state change by switching between network mode and local mode, and then between local mode and low-power mode. If the control unit fails to respond to the bus sleep state change in a timely manner and switch its own mode, it is determined that the control unit is a potentially faulty non-sleep control unit node, and the node information of the unresponsive control unit is obtained. The gateway controller can then upload the node information of the unresponsive control unit to the cloud platform.

[0073] In this embodiment of the application, if the control unit does not respond to the operation of switching from network mode to local mode and then further from local mode to low power mode after the bus enters sleep mode, the unresponsive control unit is determined to be an abnormal control unit. The node information of the unresponsive control unit is uploaded to the cloud platform to complete the status recording of the abnormal control unit. This is beneficial for accurately locating the abnormal control unit, thereby solving the problem of abnormal vehicle power consumption more efficiently.

[0074] Optionally, the vehicle includes an onboard telematics processor, and waking the bus from the sleep state includes: In response to the bus waking up from the sleep state, the control unit switches from the low-power mode to the network mode; Uploading the abnormal power consumption information of the control unit to the cloud platform includes: When the control unit is in the network mode, it is controlled to send the abnormal power consumption information to the vehicle telematics processor. The vehicle-mounted remote information processor is controlled to upload the abnormal power consumption information to the cloud platform.

[0075] In this embodiment of the application, an on-board telematics processor (i.e., an on-board TBOX) may also be deployed on the vehicle.

[0076] After the bus is woken up and the control unit switches from low-power mode to network mode, the vehicle telematics processor reads the vehicle's CAN bus data to detect whether abnormal power consumption occurred during the bus sleep period, i.e., whether the control unit generated abnormal power consumption information during the bus sleep period. If abnormal power consumption information is detected during the bus sleep period, indicating a local control unit failure to sleep during the bus sleep period, the vehicle telematics processor receives the abnormal power consumption information sent by the control unit when the control unit is in network mode and uploads it to the cloud platform. The cloud platform then issues alarms and event notifications, and technicians can analyze the cause of abnormal vehicle power consumption based on the abnormal power consumption information.

[0077] In one example, the triggering logic for alarms and event notifications on the cloud platform is shown in Table 1. If the wake-up source signal and / or sustain source signal issued by the controller ECUx of the x-th controller node after bus wake-up are valid values ​​not equal to 0, i.e., abnormal power consumption information, then TBOX uploads an alarm signal to the cloud platform through an event to trigger alarm and event notifications on the cloud. The cloud platform receives, parses, and records the wake-up source signal and sustain source signal issued by ECUx. For example, the cloud platform records it as: the faulty ECU has not been sleeping locally for a long time, and the sustain source is xx. When the wake-up source signal and sustain source signal issued by ECUx are invalid values ​​or the bus goes into sleep mode, it is considered that normal operation has been restored.

[0078] Table 1. Cloud-based alarm and event notification triggering logic

[0079] In this embodiment, while the control unit monitors its own status, the vehicle-mounted telematics processor monitors the abnormal power consumption information issued by the control unit and uploads the abnormal power consumption information to the cloud platform, thus constructing a two-layer monitoring mechanism of the control unit and the vehicle-mounted telematics processor, thereby realizing the accurate location and status recording of the control unit with abnormal power consumption.

[0080] Example 2 To enable those skilled in the art to more clearly understand the vehicle monitoring method shown in the embodiments of this application, the following describes... Figures 4-6 This application provides an explanation of a vehicle monitoring method illustrated in an embodiment.

[0081] Reference Figure 4 This is a schematic diagram of the system structure of a vehicle monitoring method provided in an embodiment of this application.

[0082] The vehicle in this application embodiment may include a gateway controller (GWM), a battery sensor (EBS), a 4G module (i.e., an on-board telematics processor, Tbox), and a power consumption self-diagnosis control unit (i.e., a control unit ECU, taking IBCM as an example).

[0083] After the bus enters sleep mode, the battery sensor is used to collect the battery voltage signal, so that the remaining battery power can be determined based on the battery voltage signal.

[0084] The gateway controller can collect battery voltage signals from the battery sensor and send them to the 4G module; it can also send a wake-up command to the power consumption self-diagnosis control unit to switch the control unit to network mode, thereby uploading abnormal information to the 4G module. For example, a wake-up command can be sent to the power consumption self-diagnosis control unit when the remaining battery power is less than a preset power threshold and the current bus is in sleep mode for less than a preset sleep duration threshold.

[0085] Reference Figure 5 This is a flowchart illustrating the power consumption monitoring method for a vehicle provided in an embodiment of this application.

[0086] Step 501: Power off and turn off the vehicle.

[0087] Step 502: The entire vehicle enters sleep mode, i.e., the bus enters sleep mode. If there are control units that are not in sleep mode, proceed to step 503; otherwise, proceed to steps 5041 and 5042.

[0088] Step 503: GWM uploads information on non-sleeping nodes (i.e., node information of unresponsive control units).

[0089] Step 5041: The control unit node performs a self-diagnosis to check for abnormal power consumption and stores the self-diagnosis information.

[0090] Step 5042: The GWM checks the battery level every hour to determine if the remaining power is less than 70% and if the bus has been in sleep mode for less than 10 hours. If the conditions are met, proceed to step 5043; otherwise, repeat step 5042.

[0091] Step 5043: Wake up the entire vehicle once. It will only be woken up once in a power-down cycle.

[0092] Step 505: All control unit nodes will send and upload self-diagnostic information to TBOX. Step 506: T-Box uploads all relevant information to the cloud backend (i.e., cloud platform).

[0093] Step 507: After the upload is complete, proceed to step 502, and the vehicle will go into sleep mode again.

[0094] Reference Figure 6 This is a flowchart of an abnormal power consumption handling method for a vehicle monitoring method provided in an embodiment of this application. Figure 6 The diagram illustrates a more detailed self-diagnostic process for the control unit in step 5041 above, using IBCM as an example.

[0095] Step 601: After the vehicle is turned off and the bus network goes into sleep mode, the IBCM records the timestamp information of the last moment before the network goes into sleep mode.

[0096] Step 602: The IBCM monitors whether it has entered a local low-power mode, i.e., there is no repeated wake-up by passive electrical signals or it remains awake. If yes, proceed to step 606; otherwise, proceed to steps 6031 and 6032.

[0097] Step 6031: The IBCM detects that the timer is started. After 1 hour, it re-evaluates and monitors whether it has entered local low-power mode. If yes, it proceeds to step 606; otherwise, it proceeds to step 604.

[0098] Step 6032: When the IBCM detects a local wake-up, the counter starts counting. After being repeatedly woken up 20 times, it determines whether the local system has entered local low-power mode. If yes, proceed to step 606; otherwise, proceed to step 604.

[0099] Step 604: The IBCM records the timestamp information of the last sleep and the wake-up source signal information to maintain local wake-up in the EEPROM (Electrically Erasable Programmable Read-Only Memory).

[0100] Step 605: The IBCM sends a local sustain source signal or a local wake-up source signal during the next Wake-Up call.

[0101] Step 606: IBCM maintains sleep and low-power states.

[0102] This application embodiment achieves localized, proactive power consumption monitoring during bus sleep mode by having the control unit continuously monitor its own status and generate self-diagnostic information. When preset conditions of remaining battery power and sleep duration are met, the control unit actively wakes up the bus to report abnormal power consumption information to the cloud platform. Simultaneously, by uploading the abnormal power consumption information obtained from the control unit's self-diagnosis to the cloud platform, the status of the control unit with abnormal power consumption can be recorded, facilitating accurate location of the control unit with abnormal power consumption and thus more efficiently resolving vehicle power consumption anomalies. Based on this application embodiment, ineffective battery power consumption can be effectively reduced, extending vehicle parking time.

[0103] This application also provides a vehicle monitoring device 70, please refer to... Figure 7 ,include: The monitoring module 710 is used to monitor the battery and the control unit if the bus is in a sleep state, and obtain the remaining power of the battery and the self-diagnostic information of the control unit, wherein the self-diagnostic information includes abnormal power consumption information of the control unit. The wake-up module 720 is used to wake up the bus from the sleep state if the remaining power is less than a preset power threshold and the sleep time of the bus in the sleep state is less than a preset sleep time threshold, so that the bus can communicate with the cloud platform. The reporting module 730 is used to upload the abnormal power consumption information of the control unit to the cloud platform.

[0104] Optionally, the control unit has a low-power mode, a local mode, and a network mode. The low-power mode is a mode in which the control unit is not connected to the network and is not in operation. The local mode is a mode in which the control unit is not connected to the network and is in operation. The network mode is a mode in which the control unit is connected to the network and is in operation. The device includes: A bus sleep module is used to switch the bus to sleep mode in response to a sleep command; The first switching module is configured to control the control unit to switch from the network mode to the local mode in response to the bus switching to the sleep state. The second switching module is used to control the control unit to switch from the local mode to the low-power mode within a preset time.

[0105] Optionally, the monitoring module 710 includes: The non-sleep data recording submodule is used to record the non-sleep duration of the control unit in the local mode if the control unit does not switch from the local mode to the low power mode within a preset time. The non-sleep data acquisition submodule is used to acquire the non-sleep data of the control unit if the non-sleep duration reaches a preset abnormal duration threshold. The first information recording submodule is used to record the non-sleep data as abnormal power consumption information of the control unit.

[0106] Optionally, the monitoring module 710 includes: An abnormal wake-up monitoring submodule is used to acquire abnormal wake-up data of the control unit if the number of times the control unit switches from the low-power mode to the local mode after switching to the low-power mode reaches a preset abnormal wake-up threshold. The second information recording submodule is used to record the abnormal wake-up data as abnormal power consumption information of the control unit.

[0107] Optionally, the device further includes: An abnormal node determination module is used to obtain node information of a non-responsive control unit if the control unit fails to respond to the switching of the sleep state of the bus. The third information recording module is used to upload the node information of the unresponsive control unit to the cloud platform.

[0108] Optionally, the vehicle includes an onboard telematics processor, and the wake-up module 720 includes: The third switching submodule is used to switch the control unit from the low-power mode to the network mode in response to the bus waking up from the sleep state. The reporting module 730 includes: The first reporting submodule is used to control the control unit to send the abnormal power consumption information to the vehicle remote information processor when the control unit is in the network mode. The second reporting submodule is used to control the vehicle-mounted remote information processor to upload the abnormal power consumption information to the cloud platform.

[0109] Optionally, the abnormal power consumption information includes an alarm signal, an abnormal wake-up source signal and timestamp information corresponding to the abnormal wake-up source signal, and / or an abnormal sustaining source signal and timestamp information corresponding to the abnormal sustaining source signal.

[0110] This application also provides an electronic device 80, please refer to... Figure 8 It includes a processor 810 and a memory 820, wherein the memory 810 is used to store computer programs; and the processor 820 is used to execute the programs stored in the memory 810 to implement the vehicle monitoring method described in any embodiment of this application.

[0111] This application also provides a vehicle that includes the electronic equipment described in this application.

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

[0113] 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.

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

[0115] 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 three cases: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0116] 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.

[0117] 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 vehicles, characterized in that, The vehicle has a battery, a bus, and a control unit deployed on the bus, the method comprising: If the bus is in a sleep state, the battery and the control unit are monitored to obtain the remaining power of the battery and the self-diagnostic information of the control unit. The self-diagnostic information includes abnormal power consumption information of the control unit. If the remaining power is less than a preset power threshold, and the sleep duration of the bus in the sleep state is less than a preset sleep duration threshold, then the bus will be woken up from the sleep state so that the bus can communicate with the cloud platform. The abnormal power consumption information of the control unit is uploaded to the cloud platform.

2. The vehicle monitoring method according to claim 1, characterized in that, The control unit has a low-power mode, a local mode, and a network mode. The low-power mode is a mode in which the control unit is not connected to the network and is not in operation. The local mode is a mode in which the control unit is not connected to the network and is in operation. The network mode is a mode in which the control unit is connected to the network and is in operation. Before monitoring the battery and the control unit, the method includes: In response to a sleep command, the bus is switched to sleep mode; In response to the bus switching to the sleep state, the control unit is controlled to switch from the network mode to the local mode; The control unit is controlled to switch from the local mode to the low-power mode within a preset time.

3. The vehicle monitoring method according to claim 2, characterized in that, The monitoring of the control unit obtains the self-diagnostic information of the control unit, including: If the control unit does not switch from the local mode to the low-power mode within a preset time, the non-sleep time of the control unit in the local mode is recorded. If the non-sleep duration reaches a preset abnormal duration threshold, then the non-sleep data of the control unit is obtained; The non-sleep data is used as abnormal power consumption information for the control unit.

4. The vehicle monitoring method according to claim 2, characterized in that, The monitoring of the control unit obtains the self-diagnostic information of the control unit, including: If the number of times the control unit switches from the low-power mode to the local mode after switching to the low-power mode reaches a preset abnormal wake-up threshold, then the abnormal wake-up data of the control unit is obtained. The abnormal wake-up data is used as abnormal power consumption information of the control unit.

5. The vehicle monitoring method according to claim 2, characterized in that, After switching the bus to a sleep state in response to a sleep command, the method further includes: If a control unit fails to respond to the switching of the sleep state of the bus, then obtain the node information of the unresponsive control unit; The node information of the unresponsive control unit is uploaded to the cloud platform.

6. The vehicle monitoring method according to claim 2, characterized in that, The vehicle includes an onboard telematics processor, and waking the bus from the sleep state includes: In response to the bus waking up from the sleep state, the control unit switches from the low-power mode to the network mode; Uploading the abnormal power consumption information of the control unit to the cloud platform includes: When the control unit is in the network mode, it is controlled to send the abnormal power consumption information to the vehicle telematics processor. The vehicle-mounted remote information processor is controlled to upload the abnormal power consumption information to the cloud platform.

7. The vehicle monitoring method according to claim 1, characterized in that, The abnormal power consumption information includes alarm signals, abnormal wake-up source signals and timestamp information corresponding to the abnormal wake-up source signals, and / or abnormal maintenance source signals and timestamp information corresponding to the abnormal maintenance source signals.

8. A vehicle monitoring device, characterized in that, The vehicle has a battery, a bus, and a control unit deployed on the bus, the device including: The monitoring module is used to monitor the battery and the control unit if the bus is in a sleep state, and obtain the remaining power of the battery and the self-diagnostic information of the control unit, the self-diagnostic information including abnormal power consumption information of the control unit; The wake-up module is used to wake up the bus from the sleep state if the remaining power is less than a preset power threshold and the sleep time of the bus in the sleep state is less than a preset sleep time threshold, so that the bus can communicate with the cloud platform. The reporting module is used to upload the abnormal power consumption information of the control unit to the cloud platform.

9. An electronic device, characterized in that, Including processor and memory, among which Memory, used to store computer programs; A processor for executing a program stored in memory to implement the vehicle monitoring method according to any one of claims 1-7.

10. A vehicle, characterized in that, It includes the electronic device as described in claim 9.

Images