Vehicle dormancy control method and device, vehicle and storage medium
By monitoring vehicle bus messages and using the gateway controller and TBOX to control the vehicle's power-on and power-off states, ECUs that are not in hibernation or have been abnormally awakened are put into hibernation mode, thus solving the power consumption problem when the vehicle is in the OFF position and ensuring that the vehicle can start normally.
Patent Information
- Application Number
- CN202410940530.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-12
- Publication Date
- 2026-01-13
AI Technical Summary
When the vehicle's ignition switch is in the OFF position, some ECUs may not be in sleep mode or may be abnormally awakened, causing other ECUs on the vehicle bus to be awakened and continuously consume power, which may result in insufficient battery power and prevent the vehicle from starting.
By monitoring whether messages are sent on the vehicle bus, the gateway controller and TBOX send monitoring messages to control the vehicle to power on and then power off, so that ECUs that are not in hibernation or abnormally woken up can enter hibernation state, including sending vehicle power-on commands, ECU reset commands and vehicle power-off commands.
This saves the power consumption of the vehicle battery by the ECU, which is not in sleep mode or is abnormally awakened when the ignition switch is in the OFF position, thus avoiding the problem of the vehicle being unable to start due to insufficient power.
Smart Images
Figure CN121325809A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to the field of vehicles, in particular to a vehicle hibernation control method and device, a vehicle and a storage medium. BACKGROUND
[0002] When the ignition switch of a vehicle is in OFF gear, the electronic control units (ECUs) of various systems of the vehicle are usually powered by a constant power supply, such as an anti-theft controller, a gateway controller, an engine controller, an instrument controller, a TBOX controller, etc. In the case of constant power supply of the ignition switch of the vehicle in OFF gear, the ECUs of the vehicle usually enter a hibernation mode, and the ECUs no longer perform main functions. However, in some abnormal situations, some ECUs may not hibernate, or the ECUs may be abnormally awakened after hibernation. The ECUs that do not hibernate or are abnormally awakened may awaken other ECUs on the vehicle bus, resulting in the ECUs of the entire vehicle not hibernating or being awakened. When the ECUs of the vehicle are in a non-hibernation state, the ECUs will continue to consume power, which may cause the battery of the vehicle to be continuously consumed, and thus the vehicle may not be started due to insufficient battery power. SUMMARY
[0003] To overcome the problems in the related art, the present disclosure provides a vehicle hibernation control method and device, a vehicle and a storage medium.
[0004] According to a first aspect of an embodiment of the present disclosure, a vehicle hibernation control method is provided, applied to a vehicle, and the method comprises:
[0005] When the ignition switch of the vehicle is in OFF gear, it is monitored whether there is a message sent on the bus of the vehicle;
[0006] When there is a message sent on the bus of the vehicle, a monitoring message is sent to the TBOX of the vehicle through the gateway controller of the vehicle;
[0007] After the TBOX receives the monitoring message, the TBOX controls the vehicle to be powered on and then powered off, so that the non-hibernation ECU corresponding to the monitoring message enters a hibernation state.
[0008] Optionally, after the TBOX receives the monitoring message, the TBOX controls the vehicle to be powered on and then powered off, so that the non-hibernation ECU that sent the message enters a hibernation state, comprising:
[0009] After the TBOX receives the monitoring message, the TBOX sends a vehicle power-on instruction to the BCM controller of the vehicle to control the vehicle to be powered on;
[0010] After the vehicle is powered on, the TBOX sends an ECU reset command to the non-dormant ECU, which is used to control the non-dormant ECU to reset.
[0011] After the non-dormant ECU is reset, the TBOX sends a vehicle power-down command to the BCM controller to control the vehicle to power down.
[0012] Optionally, when a message is sent on the vehicle's bus, sending a monitoring message to the vehicle's TBOX via the vehicle's gateway controller includes:
[0013] When a message is sent on the vehicle's bus, the bus address that sent the message is obtained through the vehicle's gateway controller;
[0014] The gateway controller sends a forced sleep message to the non-sleep ECU corresponding to the bus address. The forced sleep message is used to instruct the non-sleep ECU to stop sending messages and go into sleep mode.
[0015] If the non-sleep ECU fails to sleep, the gateway controller sends the monitoring message to the TBOX, wherein the monitoring message contains the bus address.
[0016] Optionally, when a message is sent on the vehicle's bus, obtaining the bus address that sent the message through the vehicle's gateway controller includes:
[0017] When a message is sent from the vehicle's bus and the gateway controller is in a wake-up state, the bus address that sent the message is obtained through the gateway controller.
[0018] or,
[0019] When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, wake up the gateway controller;
[0020] The gateway controller obtains the bus address for sending the message.
[0021] Optionally, when a message is sent on the vehicle's bus, sending a monitoring message to the vehicle's TBOX via the vehicle's gateway controller includes:
[0022] When a message is sent on the vehicle's bus and the gateway controller is in a wake-up state, a monitoring message containing a first non-sleep event flag is generated by the gateway controller.
[0023] The gateway controller sends the monitoring message containing the first non-sleep event flag to the TBOX;
[0024] or,
[0025] When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, after waking up the gateway controller, a monitoring message containing a second non-sleep event flag is generated by the gateway controller.
[0026] The gateway controller sends the monitoring message containing the second non-sleep event flag to the TBOX.
[0027] Optionally, in the case that the non-dormant ECU fails to go into hibernation, sending the monitoring message to the TBOX through the gateway controller includes:
[0028] When a message is detected on the vehicle's bus within a first set time range, it is determined that the non-dormant ECU has not successfully gone into hibernation.
[0029] The gateway controller generates a monitoring message containing a third non-sleep event flag;
[0030] The gateway controller sends the monitoring message containing the third non-sleep event flag to the TBOX.
[0031] Optionally, the method further includes:
[0032] After receiving the monitoring message, the TBOX reports the monitoring message to the vehicle network system through the TBOX, so that the vehicle network system can monitor the vehicle's non-dormant events based on the monitoring message.
[0033] According to a second aspect of the present disclosure, a vehicle sleep control device is provided, applied to a vehicle, the device comprising:
[0034] The monitoring module is used to monitor whether any messages are being sent from the vehicle's bus when the vehicle's ignition switch is in the OFF position.
[0035] The sending module is used to send a monitoring message to the vehicle's TBOX through the vehicle's gateway controller when a message is sent from the vehicle's bus.
[0036] The control module is used to control the vehicle to power on and then power off the vehicle via the vehicle's TBOX after the TBOX receives the monitoring message, so that the non-dormant ECU corresponding to the monitoring message enters a dormant state.
[0037] According to a third aspect of the present disclosure, a vehicle is provided that includes the vehicle sleep control device provided in the second aspect of the present disclosure.
[0038] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the vehicle sleep control method provided in the first aspect above.
[0039] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:
[0040] In the above technical solution, when the vehicle's ignition switch is in the OFF position, the system monitors whether any messages are being sent on the vehicle's bus. When a message is sent on the vehicle's bus, a monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller. After receiving the monitoring message, the TBOX controls the vehicle to power on and then off, causing the non-dormant ECU corresponding to the monitoring message to enter a dormant state. By controlling the vehicle to power on and then off, the non-dormant ECU or an abnormally awakened ECU is reawakened and put back into dormant mode. This saves power consumption on the vehicle's battery when the ignition switch is in the OFF position, thus avoiding the problem of the vehicle failing to start due to insufficient battery power.
[0041] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description
[0042] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings:
[0043] Figure 1 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0044] Figure 2 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0045] Figure 3 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0046] Figure 4 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0047] Figure 5 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0048] Figure 6 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0049] Figure 7 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0050] Figure 8 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0051] Figure 9 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment.
[0052] Figure 10 This is a block diagram illustrating a vehicle sleep control device 1000 according to an exemplary embodiment.
[0053] Figure 11 This is a block diagram illustrating an electronic device 1100 according to an exemplary embodiment. Detailed Implementation
[0054] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.
[0055] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.
[0056] Figure 1 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 1 As shown, applied to vehicles, the method includes the following steps:
[0057] In step S11, when the vehicle's ignition switch is in the OFF position, the system monitors whether any messages are being sent from the vehicle's bus.
[0058] For example, when the vehicle's ignition switch is in the ON position or the vehicle is running, the various Electronic Control Units (ECUs) of the vehicle can exchange data and communicate with each other through the vehicle's bus, enabling the ECUs of different systems to communicate with each other and coordinate their functions and operations. When the vehicle's ignition switch is in the OFF position, the vehicle's engine has stopped running, and the various ECUs of the vehicle system usually enter a sleep mode, thereby ceasing to send messages to reduce the energy consumption of the vehicle's battery when the ignition switch is in the OFF position, thus extending the battery's lifespan. However, when the vehicle's ignition switch is in the OFF position, there may be issues such as ECUs not entering a sleep mode or ECUs that have entered a sleep mode being abnormally awakened, thus consuming the vehicle's battery energy. Therefore, it is possible to determine whether there are any ECUs that are not in sleep mode by monitoring whether messages are being sent through the vehicle's bus. These ECUs that are not in sleep mode can include ECUs that have not entered a sleep mode after the ignition switch is in the OFF position, or ECUs that have entered a sleep mode after the ignition switch is in the OFF position being abnormally awakened.
[0059] In step S12, when a message is sent from the vehicle’s bus, a monitoring message is sent to the vehicle’s TBOX through the vehicle’s gateway controller.
[0060] For example, the vehicle's gateway controller is the hub node of the vehicle's electronic system. Within the vehicle system, the gateway controller can connect to different bus systems, enabling ECUs using different protocols to communicate with each other. For instance, one ECU might be on a CAN bus, while another is on a LIN bus. The gateway controller can receive information from a CAN bus, convert the protocol, and then send it to the LIN bus to achieve data transmission. In summary, each ECU of the vehicle can be connected to the gateway controller via a bus, forming a complex communication network. When a message is sent from a bus connected to any ECU of the vehicle, it must be transmitted through the vehicle's gateway controller. Therefore, when a message is sent from a vehicle bus, a monitoring message can be sent from the vehicle's TBOX (Telematics Box, vehicle-to-everything intelligent terminal) through the vehicle's gateway controller. This monitoring message can include the ECU that sent the message, the time of sending the message, and the bus from which the message was sent.
[0061] In step S13, after the TBOX receives the monitoring message, it controls the vehicle to power on and then power off through the vehicle's TBOX, so that the non-dormant ECU corresponding to the monitoring message enters a dormant state.
[0062] For example, the TBOX is an important component in a vehicle networking system. It is typically connected to a gateway controller and can communicate with the ECUs (Electronic Control Units) through the gateway controller to obtain vehicle status information. It also communicates with the vehicle networking system, external devices, and various ECUs within the vehicle via wireless technologies such as cellular networks (e.g., 4G, 5G) or Wi-Fi. After the vehicle's TBOX receives the monitoring message, to prevent non-dormant ECUs from remaining in a wake-up state and consuming vehicle battery power, the TBOX can control the vehicle to power on and then off, causing the non-dormant ECUs to enter a dormant state. It is understood that after the vehicle is powered on, all ECUs in the vehicle will be reawakened, and after the vehicle is powered off, all ECUs can be put back into a dormant state.
[0063] In the above technical solution, when the vehicle's ignition switch is in the OFF position, the system monitors whether any messages are being sent on the vehicle's bus. When a message is sent on the vehicle's bus, a monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller. After receiving the monitoring message, the TBOX controls the vehicle to power on and then off, causing the non-dormant ECU corresponding to the monitoring message to enter a dormant state. By controlling the vehicle to power on and then off, the non-dormant ECU or an abnormally awakened ECU is reawakened and put back into dormant mode. This saves power consumption on the vehicle's battery when the ignition switch is in the OFF position, thus avoiding the problem of the vehicle failing to start due to insufficient battery power.
[0064] Figure 2 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 2 As shown, step S13 includes the following steps:
[0065] In step S131, after the TBOX receives the monitoring message, it sends a vehicle power-on command to the vehicle's BCM controller through the TBOX to control the vehicle to power on.
[0066] For example, the BCM controller (Body Control Module) is an important component of the vehicle's electronic system, capable of controlling the vehicle's doors, windows, rearview mirrors, lights, windshield wipers, etc. The BCM controller can also communicate with other ECUs to achieve more complex control and functions. Therefore, after receiving the monitoring message, the TBOX can send a vehicle power-on command to the vehicle's BCM controller. Upon receiving the command, the BCM controller can power on the vehicle by controlling its relays. Furthermore, if the BCM controller is in sleep mode when the TBOX sends the power-on command, it can be woken up first.
[0067] In step S132, after the vehicle is powered on, an ECU reset command is sent to the non-dormant ECU through the TBOX. The ECU reset command is used to control the non-dormant ECU to reset.
[0068] For example, after the vehicle is powered on, the TBOX can send an ECU reset command to the non-dormant ECU corresponding to the monitoring message based on the information in the monitoring message, instructing the non-dormant ECU that receives the ECU reset command to reset. The ECU reset command is used to instruct the non-dormant ECU to reset or restart. By sending the ECU reset command, the ECU can be reset to its initial state, which can resolve some electronic system problems or malfunctions. Furthermore, it is understood that the TBOX and each ECU of the vehicle are connected to the vehicle's gateway controller. When the TBOX sends an ECU reset command to a non-dormant ECU, it can first send the ECU reset command to the vehicle's gateway controller. After receiving the ECU reset command, the gateway controller then sends the ECU reset command to the corresponding non-dormant ECU.
[0069] In step S133, after the non-dormant ECU is reset, a vehicle power-down command is sent to the BCM controller via the TBOX to control the vehicle to power down.
[0070] For example, after the non-dormant ECU has been reset according to the ECU reset command, the TBOX can send a vehicle power-down command to the vehicle's BCM controller. After the BCM controller receives the vehicle power-down command, it can control the vehicle's relays to power down the vehicle, so that the reset non-dormant ECU can go back to dormancy.
[0071] Figure 3 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 3 As shown, step S12 includes the following steps:
[0072] In step S121, when a message is sent from the vehicle's bus, the bus address that sent the message is obtained through the vehicle's gateway controller.
[0073] For example, in a vehicle's electronic systems, a bus address (bus ID) typically refers to an identifier for a specific communication bus. Each bus can have one or more addresses to distinguish different networks or communication channels. For instance, in a CAN bus, each ECU connected to the CAN bus has a unique CAN ID used to identify the device sending and receiving data. Furthermore, bus addresses can be in numeric or hexadecimal form, used to manage and organize data transmission within the bus system.
[0074] When an ECU sends a message via the bus, the message typically contains the following information: Message ID (used to identify the message type and recipient, determining which ECUs will respond to a specific message); Bus ID (primarily used to identify and distinguish different communication buses or networks, ensuring data packets can be transmitted on the correct network channel); Data field (the actual data in the message, which can be sensor readings, control commands, status information, etc.); Data length code (indicating the number of bytes contained in the data field); Timestamp (time information for sending the message, used for synchronization or data recording), etc. Furthermore, it's understood that the message structure will vary depending on the different bus protocols. In summary, when any ECU sends a message via the bus, the gateway controller can obtain the bus ID corresponding to that ECU based on the message information on the bus.
[0075] In step S122, the gateway controller sends a forced hibernation message to the non-hibernation ECU corresponding to the bus address. The forced hibernation message is used to instruct the non-hibernation ECU to stop sending messages and go into hibernation.
[0076] For example, when the vehicle's ignition switch is in the OFF position, if the gateway controller obtains the bus ID of the transmitted message, it indicates that the ECU corresponding to that bus ID is in an active state. In this case, the gateway controller can send a forced sleep message to the active ECU corresponding to that bus ID, causing the active ECU to stop sending messages and enter sleep mode upon receiving the forced sleep message. The forced sleep message typically contains one or more pieces of information as shown in Table 1 below. In Table 1, different message definitions represent different message contents. The forced sleep content includes: message ID, bus ID, control commands (such as "force sleep," "enter low-power mode," etc.), enable parameters (such as sleep duration, wake-up trigger conditions, etc.), and a checksum (used to verify whether the message has been transmitted correctly). It is understood that the actual format and information contained in the forced sleep message may vary depending on different communication protocols and specific application scenarios.
[0077] Table 1: Forced Hibernation Message Information
[0078]
[0079] In step S123, if the non-sleep ECU fails to sleep, the monitoring message is sent to the TBOX through the gateway controller, wherein the monitoring message contains the bus address.
[0080] For example, if the non-sleep ECU successfully enters sleep mode according to the forced sleep message, the gateway controller can send information to the TBOX indicating that the non-sleep ECU has entered sleep mode. When the TBOX receives the information indicating that the non-sleep ECU has entered sleep mode, the TBOX can stop executing step S13 and control the gateway controller to enter sleep mode. If the non-sleep ECU fails to enter sleep mode according to the forced sleep message, the gateway controller can send information to the TBOX indicating that the non-sleep ECU has not entered sleep mode. When the TBOX receives the information indicating that the non-sleep ECU has not entered sleep mode, step S13 is executed.
[0081] Figure 4 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 4 As shown, step S121 includes the following steps:
[0082] In step S1211, when a message is sent from the vehicle's bus and the gateway controller is in a wake-up state, the bus address that sent the message is obtained through the gateway controller.
[0083] Figure 5This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 5 As shown, step S121 includes the following steps:
[0084] In step S1212, if a message is sent on the vehicle's bus and the gateway controller is in a sleep state, the gateway controller is woken up.
[0085] In step S1213, the bus address for sending the message is obtained through the gateway controller.
[0086] For example, in such Figure 4 and Figure 5 In the steps shown, under normal circumstances, when the vehicle's ignition switch is in the OFF position, all ECUs and gateway controllers of the vehicle should be in a sleep state. Therefore, when any ECU of the vehicle sends a message through the bus, it is necessary to determine whether the gateway controller is in a wake-up state. If the gateway controller is in a wake-up state, it can obtain the bus ID that sent the message; if the gateway controller is in a sleep state, it is necessary to first wake up the gateway controller and then obtain the bus ID that sent the message through the gateway controller.
[0087] Figure 6 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 6 As shown, step S12 includes the following steps:
[0088] In step S124, when a message is sent from the vehicle's bus and the gateway controller is in a wake-up state, a monitoring message containing a first non-sleep event flag is generated by the gateway controller.
[0089] For example, in order to better collect ECU non-sleep time information of different types of vehicles in the vehicle networking system, the vehicle can mark different types of non-sleep time information reported to the vehicle networking system. For example, when a message is sent on the vehicle's bus and the gateway controller is in a wake-up state, the gateway controller can generate a first non-sleep event mark and generate a monitoring message containing the first non-sleep event mark.
[0090] In step S125, the monitoring message containing the first non-sleep event flag is sent to the TBOX through the gateway controller.
[0091] Figure 7 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 7 As shown, step S12 includes the following steps:
[0092] In step S126, when a message is sent on the vehicle's bus and the gateway controller is in a sleep state, after waking up the gateway controller, a monitoring message containing a non-sleep event flag is generated through the gateway controller.
[0093] For example, if a message is sent on the vehicle's bus and the gateway controller is in a sleep state, a second non-sleep event flag can be generated by the gateway controller after it is woken up, and a monitoring message containing the second non-sleep event flag can be generated.
[0094] In step S127, the monitoring message containing the second non-sleep event flag is sent to the TBOX through the gateway controller.
[0095] Figure 8 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 8 As shown, step S123 includes the following steps:
[0096] In step S1231, when a message is detected to be sent on the vehicle's bus within a first set time range, it is determined that the non-dormant ECU has not successfully gone into hibernation.
[0097] In step S1232, a monitoring message containing a third non-sleep event flag is generated by the gateway controller.
[0098] For example, after the gateway controller sends a forced sleep message to the non-sleep ECU to put it into sleep mode, to prevent the non-sleep ECU from failing to sleep, the method may further include monitoring whether there are still messages being sent on the vehicle's bus within a first predetermined time range. If there are messages being sent on the vehicle's bus, it can be determined that the non-sleep ECU has not successfully gone into sleep mode. Then, the gateway controller can generate a third non-sleep event flag and generate a monitoring message containing the third non-sleep event flag. It is understood that this disclosure does not limit the size of the first predetermined time range; for example, the first predetermined time range can be 5 minutes. Furthermore, the method may also include controlling the gateway controller to enter sleep mode when no messages are detected being sent on the vehicle's bus within the first predetermined time range. As shown in Table 2, the monitoring message information may include: VIN (Vehicle Identification Number); time (the time when the TBOX receives the monitoring message (or the time when the non-dormant ECU sends the message)); latitude and longitude (the latitude and longitude of the vehicle's GPS when the TBOX receives the monitoring message, or the latitude and longitude of the vehicle's GPS when the non-dormant ECU sends the message); event type (non-dormant or abnormal wake-up); event flag (first non-dormant event flag, second non-dormant event flag, or third non-dormant event flag); and one or more of the following: ECU_bus ID (the bus ID corresponding to the non-dormant ECU).
[0099] Table 2: Monitoring Message Information
[0100]
[0101] In step S1233, the monitoring message containing the third non-sleep event flag is sent to the TBOX through the gateway controller.
[0102] Figure 9 This is a flowchart illustrating a vehicle sleep control method according to an exemplary embodiment, such as... Figure 9 As shown, the method also includes the following steps:
[0103] In step S14, after the TBOX receives the monitoring message, it reports the monitoring message to the vehicle network system through the TBOX, so that the vehicle network system can monitor the vehicle's non-dormant events based on the monitoring message.
[0104] For example, the TBOX is an important component in a vehicle networking system. It is typically connected to a gateway controller and can communicate with the ECU (Electronic Control Unit) through the gateway controller to obtain vehicle status information. It can also communicate with the vehicle networking system or external devices via wireless technologies such as cellular networks (e.g., 4G, 5G) or Wi-Fi. Therefore, when the vehicle's ignition switch is in the OFF position, if any non-dormant ECU sends a message via the bus, the gateway controller can generate a monitoring message (which may include the message information sent by the non-dormant ECU, vehicle information, etc.) and send it to the vehicle's TBOX. Upon receiving the monitoring message, the TBOX can forward it to the vehicle networking system. The vehicle networking system, upon receiving the monitoring message, can store the data contained in the message and provide event data query and statistical functions; for example, it can extract non-dormant event data for a vehicle within a certain time range based on the vehicle's VIN information, and statistically analyze the wake-up source ratio and bus ID ratio of all non-dormant events.
[0105] For example, in one possible embodiment, the TBOX can report any monitoring message received to the vehicle network system. In another possible embodiment, multiple monitoring messages can be stored in the TBOX and reported to the vehicle network system at a specified time. For example, the TBOX can store multiple monitoring messages received each day and report them to the vehicle network system at 0:00 the next day. Furthermore, according to the above embodiments, each monitoring message can include a first non-sleep event flag, a second non-sleep event flag, or a third non-sleep event flag. Therefore, in the vehicle system, the non-sleep time of the vehicle's ECU can be managed and analyzed based on different non-sleep event flags.
[0106] In the above technical solution, when the vehicle's ignition switch is in the OFF position, the system monitors whether any messages are being sent on the vehicle's bus. When a message is sent on the vehicle's bus, a monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller. After receiving the monitoring message, the TBOX controls the vehicle to power on and then off, causing the non-dormant ECU corresponding to the monitoring message to enter a dormant state. By controlling the vehicle to power on and then off, the non-dormant ECU or an abnormally awakened ECU is reawakened and put back into dormant mode. This saves power consumption on the vehicle's battery when the ignition switch is in the OFF position, thus avoiding the problem of the vehicle failing to start due to insufficient battery power.
[0107] Figure 10 This is a block diagram illustrating a vehicle sleep control device 900 according to an exemplary embodiment. Figure 10As shown, the device 1000 is applied to a vehicle, and the device 1000 includes: a monitoring module 1010, a transmitting module 1020, and a control module 1030;
[0108] The monitoring module 1010 is used to monitor whether any messages are being sent from the vehicle's bus when the vehicle's ignition switch is in the OFF position.
[0109] The sending module 1020 is used to send a monitoring message to the vehicle's TBOX through the vehicle's gateway controller when a message is sent from the vehicle's bus.
[0110] The control module 1030 is used to control the vehicle to power on and then power off the vehicle through the vehicle's TBOX after the TBOX receives the monitoring message, so that the non-dormant ECU corresponding to the monitoring message enters a dormant state.
[0111] Optionally, the control module 1030 is used for:
[0112] After receiving the monitoring message, the TBOX sends a vehicle power-on command to the vehicle's BCM controller to control the vehicle to power on.
[0113] After the vehicle is powered on, the TBOX sends an ECU reset command to the non-dormant ECU. The ECU reset command is used to control the non-dormant ECU to reset.
[0114] After the non-dormant ECU is reset, a vehicle power-down command is sent to the BCM controller via the TBOX to control the vehicle to power down.
[0115] Optionally, the sending module 1020 includes: an acquisition submodule, a first sending submodule, and a second sending submodule;
[0116] This acquisition submodule is used to obtain the bus address that sent the message through the vehicle's gateway controller when a message is sent on the vehicle's bus.
[0117] The first transmitting submodule is used to send a forced sleep message to the non-sleep ECU corresponding to the bus address through the gateway controller. The forced sleep message is used to instruct the non-sleep ECU to stop sending messages and go into sleep mode.
[0118] The second transmitting submodule is used to send the monitoring message to the TBOX through the gateway controller when the non-dormant ECU fails to go into hibernation. The monitoring message contains the bus address.
[0119] Optionally, this acquisition submodule is also used for:
[0120] When a message is sent from the vehicle's bus and the gateway controller is in a wake-up state, the bus address that sent the message is obtained through the gateway controller.
[0121] or,
[0122] When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, wake up the gateway controller.
[0123] The gateway controller obtains the bus address that sent the message.
[0124] Optionally, the transmitting module 1020 is also used for:
[0125] When a message is sent on the vehicle's bus and the gateway controller is in a wake-up state, a monitoring message containing a first non-sleep event flag is generated through the gateway controller.
[0126] The gateway controller sends the monitoring message containing the first non-sleep event flag to the TBOX;
[0127] or,
[0128] When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, after waking up the gateway controller, a monitoring message containing a second non-sleep event flag is generated through the gateway controller.
[0129] The gateway controller sends the monitoring message containing the second non-sleep event flag to the TBOX.
[0130] Optionally, the second transmitting submodule is also used for:
[0131] When a message is detected on the vehicle's bus within a first set time range, it is determined that the non-dormant ECU has not successfully gone into hibernation.
[0132] The gateway controller generates a monitoring message containing a third non-sleep event flag;
[0133] The gateway controller sends the monitoring message containing the third non-sleep event flag to the TBOX.
[0134] Optionally, the device 1000 further includes: a data transmission module;
[0135] The data transmission module is used to report the monitoring message to the vehicle networking system through the TBOX after the TBOX receives the monitoring message, so that the vehicle networking system can monitor the vehicle's non-dormant events based on the monitoring message.
[0136] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0137] In the above technical solution, when the vehicle's ignition switch is in the OFF position, the system monitors whether any messages are being sent on the vehicle's bus. When a message is sent on the vehicle's bus, a monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller. After receiving the monitoring message, the TBOX controls the vehicle to power on and then off, causing the non-dormant ECU corresponding to the monitoring message to enter a dormant state. By controlling the vehicle to power on and then off, the non-dormant ECU or an abnormally awakened ECU is reawakened and put back into dormant mode. This saves power consumption on the vehicle's battery when the ignition switch is in the OFF position, thus avoiding the problem of the vehicle failing to start due to insufficient battery power.
[0138] Figure 11 This is a block diagram illustrating an electronic device 1100 according to an exemplary embodiment. For example... Figure 11 As shown, the electronic device 1100 may include: a processor 1101 and a memory 1102. The electronic device 1100 may also include one or more of a multimedia component 1103, an input / output (I / O) interface 1104, and a communication component 1105.
[0139] The processor 1101 controls the overall operation of the electronic device 1100 to complete all or part of the steps in the vehicle sleep control method described above. The memory 1102 stores various types of data to support the operation of the electronic device 1100. This data may include, for example, instructions for any application or method operating on the electronic device 1100, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 1102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 1103 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 1102 or transmitted via communication component 1105. The audio component also includes at least one speaker for outputting audio signals. I / O interface 1104 provides an interface between processor 1101 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 1105 is used for wired or wireless communication between the electronic device 1100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 1105 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.
[0140] In one exemplary embodiment, the electronic device 1100 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the vehicle sleep control method described above.
[0141] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the vehicle sleep control method described above. For example, the computer-readable storage medium may be the memory 1102 including program instructions, which may be executed by the processor 1101 of the electronic device 1100 to complete the vehicle sleep control method described above.
[0142] In another exemplary embodiment, a vehicle is also provided that includes the vehicle sleep control device described in the above embodiments.
[0143] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the above-described vehicle sleep control method when executed by the programmable device.
[0144] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.
[0145] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.
[0146] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.
Claims
1. A vehicle sleep control method, characterized in that, Applied to vehicles, the method includes: With the vehicle's ignition switch in the OFF position, monitor whether any messages are being sent from the vehicle's bus. When a message is sent from the vehicle's bus, a monitoring message is sent to the vehicle's TBOX through the vehicle's gateway controller; After the TBOX receives the monitoring message, it controls the vehicle to power on and then power off through the vehicle's TBOX, so that the non-dormant ECU corresponding to the monitoring message enters a dormant state.
2. The method according to claim 1, characterized in that, The step of controlling the vehicle to power on and then power off via the vehicle's TBOX after the TBOX receives the monitoring message, so that the non-dormant ECU that sent the message enters a dormant state, includes: After receiving the monitoring message, the TBOX sends a vehicle power-on command to the vehicle's BCM controller to control the vehicle to power on. After the vehicle is powered on, the TBOX sends an ECU reset command to the non-dormant ECU, which is used to control the non-dormant ECU to reset. After the non-dormant ECU is reset, the TBOX sends a vehicle power-down command to the BCM controller to control the vehicle to power down.
3. The method according to claim 1, characterized in that, When a message is sent on the vehicle's bus, the monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller, including: When a message is sent on the vehicle's bus, the bus address that sent the message is obtained through the vehicle's gateway controller; The gateway controller sends a forced sleep message to the non-sleep ECU corresponding to the bus address. The forced sleep message is used to instruct the non-sleep ECU to stop sending messages and go into sleep mode. If the non-sleep ECU fails to sleep, the gateway controller sends the monitoring message to the TBOX, wherein the monitoring message contains the bus address.
4. The method according to claim 3, characterized in that, When a message is sent on the vehicle's bus, obtaining the bus address that sent the message through the vehicle's gateway controller includes: When a message is sent from the vehicle's bus and the gateway controller is in a wake-up state, the bus address that sent the message is obtained through the gateway controller. or, When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, wake up the gateway controller; The gateway controller obtains the bus address for sending the message.
5. The method according to claim 1, characterized in that, When a message is sent on the vehicle's bus, the monitoring message is sent to the vehicle's TBOX via the vehicle's gateway controller, including: When a message is sent on the vehicle's bus and the gateway controller is in a wake-up state, a monitoring message containing a first non-sleep event flag is generated by the gateway controller. The gateway controller sends the monitoring message containing the first non-sleep event flag to the TBOX; or, When a message is sent on the vehicle's bus and the gateway controller is in a sleep state, after waking up the gateway controller, a monitoring message containing a second non-sleep event flag is generated by the gateway controller. The gateway controller sends the monitoring message containing the second non-sleep event flag to the TBOX.
6. The method according to claim 3, characterized in that, In the event that the non-dormant ECU fails to hibernate, the monitoring message is sent to the TBOX via the gateway controller, including: When a message is detected on the vehicle's bus within a first set time range, it is determined that the non-dormant ECU has not successfully gone into hibernation. The gateway controller generates a monitoring message containing a third non-sleep event flag; The gateway controller sends the monitoring message containing the third non-sleep event flag to the TBOX.
7. The method according to claim 1, characterized in that, The method further includes: After receiving the monitoring message, the TBOX reports the monitoring message to the vehicle network system through the TBOX, so that the vehicle network system can monitor the vehicle's non-dormant events based on the monitoring message.
8. A vehicle sleep control device, characterized in that, The device includes: The monitoring module is used to monitor whether any messages are being sent from the vehicle's bus when the vehicle's ignition switch is in the OFF position. The sending module is used to send a monitoring message to the vehicle's TBOX through the vehicle's gateway controller when a message is sent from the vehicle's bus. The control module is used to control the vehicle to power on and then power off the vehicle via the vehicle's TBOX after the TBOX receives the monitoring message, so that the non-dormant ECU corresponding to the monitoring message enters a dormant state.
9. A vehicle, characterized in that, The vehicle includes the vehicle sleep control device as described in claim 8.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.