A method of controlling a vehicle-mounted communication terminal and a vehicle

Abstract

The application provides a kind of method for controlling vehicle-mounted communication terminal and vehicle, it is related to intelligent network connection technical field.Response to the dormancy trigger request sent by upper layer control unit, select one or more from multiple state information as target state information to formulate dormancy control strategy.Talking state is directly related to whether vehicle-mounted communication terminal can immediately enter dormancy, it is used as preposed screening condition, this can lock the current most critical decision basis from multiple state information, ensure that in high priority scene such as conversation, dormancy control strategy can give priority to guarantee the continuity of communication service.This can avoid the interference of irrelevant state information, so as to formulate safe and reliable and conform to actual business needs dormancy control strategy.That is, the above-mentioned comprehensive control method can break the simple logic of only relying on whether vehicle is powered on in related technology to control TBOX dormancy, can greatly improve the reliability and rationality of TBOX dormancy decision.

Description

Technical Field

[0001] This application relates to the field of TBOX control technology, and more specifically, to a method and vehicle for controlling an in-vehicle communication terminal in the field of intelligent connected vehicle technology. Background Technology

[0002] The Telematics Box (TBOX) is a crucial component of a vehicle-to-everything (V2X) system, specifically serving as the terminal that enables interconnection between the vehicle and other devices. The TBOX can transmit vehicle location and status information to a backend system, which can then push this information to the client, allowing the owner to view the vehicle's real-time status. The TBOX can also send relevant information to the cloud and receive remote control commands to execute corresponding remote operation actions. Furthermore, the TBOX can use the Controller Area Network (CAN) bus to send control information to the vehicle's electronic control unit (ECU) for vehicle control.

[0003] To accurately control the operating status of the TBOX, there is a need to determine its different operating states based on the vehicle's status. Related technologies use whether the vehicle is powered on to switch the TBOX between operating and sleep modes. This control method is relatively simple; it can control the TBOX to enter sleep mode when the vehicle is not powered on. However, the accuracy of this sleep mode decision-making is insufficient.

[0004] Therefore, there is an urgent need for a method to control the vehicle-mounted communication terminal in order to improve the reliability of the TBOX sleep decision and to reasonably control the vehicle-mounted communication terminal. Summary of the Invention

[0005] This application provides a method and vehicle for controlling an in-vehicle communication terminal. The method can improve the reliability of TBOX sleep decision and provide reasonable control over the in-vehicle communication terminal.

[0006] Firstly, a method for controlling a vehicle-mounted communication terminal is provided. This method is executed by the vehicle-mounted communication terminal and includes: responding to a sleep trigger request sent by an upper-layer control unit; acquiring multiple status information, including the call service status of the vehicle-mounted communication terminal, a target list, and a vehicle operating mode; the target list storing identifiers of functional modules currently running and dependent on the vehicle-mounted communication terminal; the sleep trigger request initiating a sleep application for the vehicle-mounted communication terminal and entering a sleep verification process; selecting one or more status information from the multiple status information based on whether the call service status is in a call state to obtain target status information; and determining a sleep control strategy for the vehicle-mounted communication terminal based on the target status information; and performing sleep control on the vehicle-mounted communication terminal based on the sleep control strategy.

[0007] In the above technical solution, in response to the sleep trigger request sent by the upper-level control unit, a sleep verification process for sleep control of the vehicle communication terminal is initiated. Multiple status information is acquired, including call service status to determine if there are any calls requiring continuous persistence; a target list to check if any tasks dependent on the vehicle communication terminal have not yet ended; and vehicle operating mode to distinguish the vehicle's operating scenario. Subsequently, based on whether the call service status is in a call state, one or more status information are selected as the target status information to formulate a sleep control strategy. The call status directly relates to whether the vehicle communication terminal can immediately enter sleep mode; using it as a preliminary screening condition allows for identifying the most critical decision-making basis from multiple status information, ensuring that the sleep control strategy prioritizes the continuity of communication services in high-priority scenarios such as calls. This avoids interference from irrelevant status information, thereby formulating a sleep control strategy that is both safe and reliable and meets actual business needs. Therefore, the above comprehensive control method breaks away from the simplistic logic of relying solely on whether the vehicle is powered on for TBOX sleep control in related technologies, significantly improving the reliability and rationality of TBOX sleep decisions.

[0008] In conjunction with the first aspect, in some possible implementations, based on whether the call service status is a call state, at least one status information is selected from the multiple status information to obtain target status information, including: if the call service status is a call state, determining that the target status information includes the call service status; if the call service status is not a call state, determining that the target status information includes the call service status, the target list, and the vehicle operating mode.

[0009] In the above technical solution, when the call service status is in a call state, the call service status is directly locked as the target status information. This enables a rapid response and blocks hibernation, ensuring the absolute continuity and real-time nature of the call service. In non-call states, the call service status, target list, and vehicle operating mode are comprehensively considered. This ensures that accurate hibernation decisions can be made based on a comprehensive system status when there are no urgent services. The hierarchical filtering mechanism in the above solution avoids the resource consumption and decision delays caused by redundant status detection in non-call states, and prevents hibernation judgment errors due to interference from other states in call states. Therefore, while ensuring the experience of critical services, it improves the accuracy and processing efficiency of hibernation control for in-vehicle communication terminals.

[0010] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the sleep control policy of the vehicle communication terminal is determined based on the target state information, including: if the target state information includes a call service state, the sleep control policy is determined as a first policy that prohibits the vehicle communication terminal from sleeping; if the target state information includes a call service state, a target list, and a vehicle working mode, and if the target list is empty, the sleep control policy is determined based on whether the call service state is a waiting callback state and the vehicle working mode; if the target list is not empty, a request sleep state is obtained, and the sleep control policy is determined based on the request sleep state, wherein the request sleep state is the sleep state that the vehicle communication terminal should enter, carried in the sleep trigger request.

[0011] In the above technical solution, when the target status information includes the call service status, the first strategy is directly set to prohibit the vehicle communication terminal from sleeping. This allows for rapid determination of the sleep control strategy based on core risk conditions, while prioritizing the normal operation of the call service and preventing communication interruption caused by the vehicle communication terminal sleeping during a call. When the target status information includes the call service status, the target list, and the vehicle operating mode, if the target list is empty, the sleep control strategy is determined comprehensively based on whether the call service status is in a waiting callback state and the vehicle operating mode. This can take into account subsequent service needs and the overall vehicle operation scenario, avoiding blind sleep. If the target list is not empty, the sleep control strategy is formulated based on the sleep request status carried in the sleep trigger request. This can align with the instruction requirements of the upper-level control unit and adapt to the actual task scenario of the vehicle communication terminal. The aforementioned solution establishes a layered and scenario-based hibernation decision-making and control mechanism for different service states, task loads, and vehicle operating conditions of in-vehicle communication terminals. Through differentiated branching logic, it adapts to various complex in-vehicle operating scenarios, avoiding the drawbacks of a uniform decision-making method. This ensures the stable operation of core communication services and in-vehicle functional tasks while accurately matching the instruction requirements of the upper-level control unit with the vehicle's operating mode. This effectively improves the accuracy and scenario adaptability of hibernation decisions for in-vehicle communication terminals, enabling reasonable control over the operating status of these terminals.

[0012] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the hibernation control policy is determined based on whether the call service status is a waiting callback status and the vehicle working mode, including: when the call service status is a waiting callback status, the hibernation control policy is determined based on the vehicle working mode; when the call service status is an idle status, the hibernation control policy is determined based on the request hibernation status.

[0013] The above technical solution uses two decision branches to determine the hibernation control strategy. When the call service status is in the waiting callback state, a vehicle operating mode is introduced, which preserves the responsiveness of callback communication while adapting to the vehicle's operational constraints. When the call service status is in the idle state, a hibernation control strategy is generated based on the requested hibernation status carried in the hibernation trigger request. This ensures compliance with the control intentions issued by the upper-level control unit. This solution performs a secondary refined judgment for scenarios with no call tasks and no background mounted tasks, distinguishing between standby and idle call service states. This balances the continuity of communication services with the instruction requirements of the upper-level control unit, reduces the probability of misjudgment in hibernation decisions, and further improves the refinement and rationality of the hibernation decision control mechanism of the vehicle communication terminal.

[0014] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the hibernation control strategy is determined based on the vehicle's operating mode, including: when the vehicle's operating mode is a transportation mode, the hibernation control strategy is determined to allow the vehicle-mounted communication terminal to enter a deep hibernation state, where the transportation mode is when the vehicle is in the storage and transportation phase; when the vehicle's operating mode is not a transportation mode, it is determined whether the first time difference between the current moment and the first moment is greater than a first preset duration, where the first moment is the instant when the call service status is a waiting callback state and the target list is empty, and the first timer starts counting at the first moment, where the first timer is the timer corresponding to the shallow hibernation state; when the first time difference is greater than the first preset duration, the hibernation control strategy is determined to allow the vehicle-mounted communication terminal to enter a shallow hibernation state, where the power consumption level corresponding to the shallow hibernation state is greater than the power consumption level corresponding to the deep hibernation state.

[0015] In the above technical solution, when the vehicle is in transportation mode, the sleep control strategy is set to deep sleep. This reduces the overall power consumption of the vehicle during storage and transportation, preventing battery (such as storage battery) depletion. When the vehicle is in non-transportation mode, a timeout mechanism is set. If the timeout exceeds a first preset duration, shallow sleep is adopted, which preserves basic wake-up and communication capabilities, allowing for rapid response to various vehicle commands. If the timeout does not occur, vehicle commands can be responded to immediately. This solution differentiates sleep power consumption levels based on the vehicle's stage, maximizing power saving in transportation scenarios to protect the battery, while maintaining basic functions and allowing for wake-up at any time during normal use. This solves the problem that a single sleep mode cannot adapt to the entire lifecycle of the vehicle. This solution optimizes the power management of the vehicle communication terminal, balancing power saving and ease of use.

[0016] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the sleep control strategy is determined based on the requested sleep state, including: when the requested sleep state is a deep sleep state, determining whether the second time difference between the current time and the second time is greater than a second preset duration, the second time being the instant when the call service state is idle and the target list is empty, and the second timer starts counting at the second time, the second timer being the timer corresponding to the deep sleep state; when the second time difference is greater than the second preset duration, determining the sleep control strategy to allow the vehicle communication terminal to enter a deep sleep state; when the requested sleep state is a shallow sleep state, sending an inquiry instruction to the functional module, and upon receiving a message from the functional module that there are no pending tasks, determining the sleep control strategy to allow the vehicle communication terminal to enter a shallow sleep state, the inquiry instruction being used to inquire whether the functional module has any pending tasks.

[0017] In the above technical solution, when the target status information includes call service status, target list, and vehicle operating mode, if the call service status is not in a call state (specifically, an idle state) and the target list is empty, the sleep control strategy determination process is completed in two paths. Specifically, when requesting a deep sleep state, a dedicated second timer is started to count (starting from the second moment). If the time interval between the current moment and the second moment reaches a second preset duration, the vehicle communication terminal is allowed to enter a deep sleep state. This can reserve a buffer window period to prevent the vehicle communication terminal from directly entering a deep sleep state when the target list is momentarily idle, thus preventing the inability to quickly respond to temporary task instructions. When requesting a shallow sleep state, an inquiry instruction is issued to confirm that there are no outstanding tasks before executing shallow sleep. This can prevent situations where the target list is empty but there are still tasks dependent on the vehicle communication terminal that have not yet ended (possibly because the corresponding functional module identifier has not yet been written into the target list). The above solution adds a delay de-jitter and task verification mechanism before hibernation, and distinguishes between deep and shallow hibernation pre-verification logic. This can not only avoid erroneous deep hibernation through the delay de-jitter mechanism, but also confirm the task status through query commands, thereby avoiding the error rate of hibernation operation from the source, further optimizing the power consumption management of the vehicle communication terminal, and enhancing the rigor of hibernation decision.

[0018] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the method for determining the first preset duration includes: obtaining the first reference duration corresponding to the second timer, wherein the first reference duration is the minimum timing base for the second timer to perform timing; determining the amplification factor of the first reference duration based on the current state of the backup battery in the vehicle communication terminal and the vehicle model; and determining the product between the first reference duration and the amplification factor as the first preset duration.

[0019] In the above technical solution, the minimum timing base of the second timer is obtained as the first reference duration. Then, combined with the current state of the backup battery and the vehicle model, the amplification factor of the first reference duration is matched. This allows for differentiated setting of the amplification factor, adapting to differences in the power supply status of the backup battery and vehicle model, thus exhibiting strong versatility. Subsequently, the product of the first reference duration and the amplification factor is determined as the second preset duration. This solution enables dynamic adaptive configuration of the sleep delay parameters. When the backup battery is activated, the delay can be appropriately increased, and when it is not activated, the duration can be reduced to save battery power consumption, while also matching the power consumption characteristics of pure electric, fuel, and hybrid vehicles. This improves the compatibility of the sleep control strategy with multiple operating conditions and vehicle model scenarios, enhancing the adaptability of the sleep control strategy.

[0020] In conjunction with the first aspect and the above-described implementation methods, in some possible implementation methods, the amplification factor of the first reference duration is determined based on the current state of the backup battery in the vehicle communication terminal and the vehicle model. This includes: determining the amplification factor as a first amplification factor when the current state is in use and the vehicle model is a pure electric vehicle; or, determining the amplification factor as a second amplification factor when the current state is in use and the vehicle model is a fuel vehicle or a hybrid electric vehicle; or, determining the amplification factor as a third amplification factor when the current state is in unused. The first amplification factor is greater than the third amplification factor, and the third amplification factor is greater than the second amplification factor.

[0021] In the above technical solutions, the maximum amplification factor is selected when the backup battery is in use and the vehicle is a pure electric vehicle. This extends the deep sleep waiting time, during which the vehicle communication terminal can rely on its own backup battery for power, without excessive concern about battery power consumption. The ample window period prevents sudden service interruptions due to sleep. When the backup battery is in use and the vehicle is a gasoline or hybrid vehicle, the minimum amplification factor is selected. These vehicles can start the engine to supplement power, shortening the delay and reducing unnecessary power consumption of the backup battery. When the backup battery is not used, an intermediate amplification factor is used. This avoids the situation of power depletion during long standby periods due to complete reliance on the battery. The above solutions differentiate the delay length based on the power supply capacity of the backup battery, making the sleep timing rules conform to the actual power supply scenario and improving the rationality of overall sleep management in multi-vehicle scenarios.

[0022] Combining the first aspect and the above implementation methods, in some possible implementation methods, the sleep control strategy is determined based on the requested sleep state, including: when the requested sleep state is a shallow sleep state, determining whether the third time difference between the current time and the third time is greater than a first preset duration, where the third time is the instant after the upper-layer control unit sends the sleep trigger request and the target list is not empty, and the first timer starts counting at the third time, where the first timer is the timer corresponding to the shallow sleep state; when the third time difference is greater than the first preset duration, clearing the target list and setting the sleep state... The control strategy is determined to allow the vehicle communication terminal to enter a shallow sleep state. If the requested sleep state is a deep sleep state, it is determined whether the fourth time difference between the current time and the fourth time is greater than the second preset duration. The fourth time is the instant when the target list is not empty after the upper-level control unit sends the sleep trigger request, and the second timer starts counting at the fourth time. The second timer is the timer corresponding to the deep sleep state. If the fourth time difference is greater than the second preset duration, the target list is cleared, and the sleep control strategy is determined to allow the vehicle communication terminal to enter a deep sleep state.

[0023] In the above technical solution, when the target status information includes call service status and target list, if the call service status is not a call status and the target list is not empty, the sleep control strategy determination process is completed in two ways. Specifically, when the requested sleep state is a shallow sleep state, the corresponding first timer is started to count down and waits for a first preset duration. After the timeout, the target list is cleared and the vehicle communication terminal is allowed to enter a shallow sleep state. When the requested sleep state is a deep sleep state, the corresponding second timer is started to count down and waits for a second preset duration. After the timeout, the target list is cleared and the vehicle communication terminal is allowed to enter a deep sleep state. Both of the above processing processes can reserve a processing window for unfinished tasks. The above solution sets a timeout fallback mechanism for scenarios with background tasks, not immediately terminating the associated process (entering a deep / shallow sleep state), but forcibly clearing the background tasks and entering a sleep state after the timeout. This ensures normal business operations as much as possible, while preventing task freezes that could prevent the vehicle communication terminal from entering sleep mode and cause continuous power consumption, thus improving the fault tolerance and stability of the sleep logic.

[0024] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: after the first timer starts timing, detecting whether a functional module identifier is written into the target list within the first preset duration; if a functional module identifier is written into the target list within the first preset duration, controlling the first timer to restart timing; and after the second timer starts timing, detecting whether a functional module identifier is written into the target list within the second preset duration; if a functional module identifier is written into the target list within the second preset duration, preventing the second timer from restarting timing.

[0025] In the above technical solution, differentiated timing reset logic is set for the two types of timers. Specifically, if a new background task is added while the first timer is in the timing phase, the timing is restarted. This ensures that newly added background tasks can continue to be processed. During the timing of the second timer, if a new background task is added, the timing is not reset, and the deep sleep time limit requirement is strictly enforced. The above solution differentiates the timers for deep and shallow sleep. When a task is refreshed, shallow sleep supports timing reset, while deep sleep does not. This ensures that newly added background tasks can be executed normally (during shallow sleep) and prevents power consumption due to long-term non-sleep in scenarios such as storage and transportation (during deep sleep). This makes the sleep timing rules more in line with the design intentions of different sleep levels, improving the overall flexibility and power consumption control of sleep management.

[0026] Secondly, a device for controlling a vehicle-mounted communication terminal is provided. The device is installed on the vehicle-mounted communication terminal and includes: an acquisition module, configured to acquire multiple status information in response to a sleep trigger request sent by an upper-level control unit. The multiple status information includes the call service status of the vehicle-mounted communication terminal, a target list, and a vehicle operating mode. The target list stores identifiers of functional modules that are currently running and depend on the vehicle-mounted communication terminal. The sleep trigger request initiates a sleep application for the vehicle-mounted communication terminal and initiates a sleep verification process; a determination module, configured to select one or more status information from the multiple status information based on whether the call service status is in a call state, obtain target status information, and determine a sleep control strategy for the vehicle-mounted communication terminal based on the target status information; and a control module, configured to perform sleep control on the vehicle-mounted communication terminal based on the sleep control strategy.

[0027] In conjunction with the second aspect, in some possible implementations, the determining module is specifically used to: determine that the target status information includes the call service status when the call service status is a call state; and determine that the target status information includes the call service status, the target list, and the vehicle operating mode when the call service status is not a call state.

[0028] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: determine the sleep control policy as a first policy that prohibits the vehicle communication terminal from sleeping when the target status information includes the call service status; if the target status information includes the call service status, the target list, and the vehicle working mode, and if the target list is empty, determine the sleep control policy based on whether the call service status is a waiting callback status and the vehicle working mode; if the target list is not empty, obtain the requested sleep status, and determine the sleep control policy based on the requested sleep status, wherein the requested sleep status is the sleep status that the vehicle communication terminal should enter as carried in the sleep trigger request.

[0029] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further used to: determine the hibernation control strategy based on the vehicle working mode when the call service status is a waiting callback status; and determine the hibernation control strategy based on the request hibernation status when the call service status is an idle status.

[0030] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: when the vehicle's operating mode is transportation mode, determine the hibernation control strategy to allow the vehicle-mounted communication terminal to enter a deep hibernation state, where the transportation mode is when the vehicle is in the storage and transportation phase; when the vehicle's operating mode is not transportation mode, determine whether the first time difference between the current moment and the first moment is greater than a first preset duration, where the first moment is the instant when the call service status is waiting for callback and the target list is empty, and the first timer starts counting at the first moment, where the first timer is the timer corresponding to the shallow hibernation state; when the first time difference is greater than the first preset duration, determine the hibernation control strategy to allow the vehicle-mounted communication terminal to enter a shallow hibernation state, where the power consumption level corresponding to the shallow hibernation state is greater than the power consumption level corresponding to the deep hibernation state.

[0031] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: determine whether the second time difference between the current moment and the second moment is greater than a second preset duration when the requested sleep state is a deep sleep state, wherein the second moment is the instant when the call service state is idle and the target list is empty, and the second timer starts counting at the second moment, wherein the second timer is the timer corresponding to the deep sleep state; determine the sleep control policy to allow the vehicle communication terminal to enter a deep sleep state when the second time difference is greater than the second preset duration; and send an inquiry instruction to the functional module when the requested sleep state is a shallow sleep state, and determine the sleep control policy to allow the vehicle communication terminal to enter a shallow sleep state when the functional module returns no pending tasks, wherein the inquiry instruction is used to inquire whether the functional module has any pending tasks.

[0032] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the acquisition module is specifically used to acquire the first reference duration corresponding to the second timer, the first reference duration being the minimum timing base for the second timer to perform timing; the determination module is further specifically used to: determine the magnification factor of the first reference duration based on the current state of the backup battery in the vehicle communication terminal and the vehicle model; and determine the product between the first reference duration and the magnification factor as the first preset duration.

[0033] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: determine the magnification factor as a first magnification factor when the current state is a usage state and the vehicle type is a pure electric vehicle; or, determine the magnification factor as a second magnification factor when the current state is a usage state and the vehicle type is a fuel vehicle or a hybrid electric vehicle; or, determine the magnification factor as a third magnification factor when the current state is an unused state, wherein the first magnification factor is greater than the third magnification factor, and the third magnification factor is greater than the second magnification factor.

[0034] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: when the requested sleep state is a shallow sleep state, determine whether the third time difference between the current time and the third time is greater than a first preset duration, where the third time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and at the third time, the first timer starts counting, where the first timer is the timer corresponding to the shallow sleep state; when the third time difference is greater than the first preset duration, clear the target list and determine the sleep control strategy to allow the vehicle communication terminal to enter a shallow sleep state; when the requested sleep state is a deep sleep state, determine whether the fourth time difference between the current time and the fourth time is greater than a second preset duration, where the fourth time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and at the fourth time, the second timer starts counting, where the second timer is the timer corresponding to the deep sleep state; when the fourth time difference is greater than the second preset duration, clear the target list and determine the sleep control strategy to allow the vehicle communication terminal to enter a deep sleep state.

[0035] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the device further includes: a detection module, configured to detect whether a functional module identifier is written into the target list within the first preset duration after the first timer starts timing; the control module, further configured to control the first timer to restart timing if a functional module identifier is written into the target list within the first preset duration; and the detection module, further configured to detect whether a functional module identifier is written into the target list within the second preset duration after the second timer starts timing; the control module, further configured to prevent the second timer from restarting timing if a functional module identifier is written into the target list within the second preset duration.

[0036] Thirdly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0037] Figure 1 This is a schematic flowchart illustrating a method for controlling a vehicle-mounted communication terminal according to an embodiment of this application; Figure 2 This is a schematic diagram of a process for controlling a vehicle-mounted communication terminal according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a device for controlling a vehicle-mounted communication terminal provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a controller provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0039] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0040] In related technologies, the TBOX (Total Bus Optimizer) is switched between working and sleep modes based on whether the vehicle is powered on. Specifically, when the vehicle is powered on, the TBOX exits sleep mode; when the vehicle is powered off, the TBOX directly enters sleep mode. This control method is relatively simple, but the accuracy of the sleep mode decision is insufficient.

[0041] To address the aforementioned issues, this application proposes a method for controlling an in-vehicle communication terminal, thereby improving the reliability of TBOX sleep decisions and enabling reasonable control of the in-vehicle communication terminal. Specific steps can be found in [reference needed]. Figure 1 .

[0042] Figure 1 This is a schematic flowchart illustrating a method for controlling a vehicle-mounted communication terminal according to an embodiment of this application.

[0043] It should be understood that the method for controlling an in-vehicle communication terminal provided in this application embodiment is executed by the in-vehicle communication terminal in the vehicle.

[0044] For example, such as Figure 1 As shown, the method 100 includes the following steps 101 to 103.

[0045] Step 101: In response to the hibernation trigger request sent by the upper-level control unit, obtain multiple status information, including the call service status of the vehicle communication terminal, the target list, and the vehicle working mode. The target list is used to store the identifiers of functional modules that are running and depend on the vehicle communication terminal. The hibernation trigger request is used to initiate a hibernation application for the vehicle communication terminal and enter the hibernation verification process.

[0046] It should be understood that in step 101 above, the upper-level control unit is a main control unit for vehicle power management, which can determine whether the vehicle can enter a low-power sleep state. Optionally, this upper-level control unit is a vehicle control unit, which is a physical hardware unit, but internally has control software programs for power management, etc. burned in. The above-mentioned sleep trigger request is a solicitation instruction, that is, the upper-level control unit only informs the vehicle communication terminal that the vehicle has the conditions for sleep, the vehicle is about to power down and go into sleep mode, and the vehicle communication terminal needs to verify whether its own services allow it to sleep, etc., and the right to determine whether to allow sleep is given to the vehicle communication terminal.

[0047] It should also be understood that in step 101 above, the call service status refers to the call link status being executed by the vehicle communication terminal, which is divided into call status, waiting for callback status, and idle status. The vehicle emergency call (ECALL) status and the information / breakdown call (IBCALL) status both belong to the call status. After a vehicle is collided, the vehicle emergency call is triggered, and the vehicle communication terminal can obtain the vehicle collision signal. Subsequently, the vehicle communication terminal can establish a voice call and feed back the vehicle collision signal to the emergency platform. At this time, the call service status of the vehicle communication terminal is ECALL status. After the in-vehicle button (the button corresponding to the information / breakdown call) is triggered, the information / breakdown call is triggered, and the vehicle communication terminal can obtain the information feedback signal / breakdown feedback signal. Subsequently, the vehicle communication terminal can establish a voice call and feed back the information feedback signal / breakdown feedback signal to the vehicle manufacturer's backend server or the roadside assistance service platform. At this time, the call service status of the vehicle communication terminal is IBCALL status. The "waiting for callback" state refers to the suspended waiting state where a call has been initiated and is waiting for the other party to answer. In this state, the vehicle communication terminal cannot be controlled to enter a deep sleep state (which would cause abnormal interruption of the call link). The "idle state" refers to the state when the call service is completely idle.

[0048] It should also be noted that the target list records the identification information of in-vehicle functional modules that are currently running and require the communication functions of the in-vehicle communication terminal to function properly and cannot be interrupted by sleep mode. In other words, it is a target list associated with the in-vehicle communication terminal. Optionally, these in-vehicle functional modules (hereinafter referred to as functional modules) include vehicle positioning modules, remote unlocking / locking modules, fault data uploading modules, remote upgrade process modules, and vehicle status reporting modules, etc.

[0049] Furthermore, in step 101 above, the vehicle operating mode indicates the current operating scenario of the vehicle. This vehicle operating mode includes transportation mode and non-transportation mode (i.e., not transportation mode). Transportation mode indicates that the vehicle is in the storage and transportation stage, which could be temporary storage within the factory area after the vehicle rolls off the production line, or long-distance transport to dealerships in various locations via flatbed trailers. When the vehicle is in transportation mode, the sleep restriction of the waiting-for-callback state can be canceled, allowing the vehicle communication terminal to directly enter a deep sleep state, maximizing the conservation of the backup battery power in the vehicle communication terminal and preventing backup battery depletion during long-distance transport. Non-transportation mode indicates stages such as vehicle delivery to the user, normal road driving / daily parking and use.

[0050] In some embodiments, the method for determining the transportation mode includes: when the vehicle communication terminal is in a working state, the vehicle communication terminal obtains the vehicle's mode flag bit from the target storage medium via the controller local area network bus; when the mode flag bit is a first flag bit, it is determined that the vehicle is in a transportation mode, wherein the first flag bit is a transportation mode flag bit.

[0051] It should be understood that the target storage medium may be a storage chip inside the upper control unit, and a mode flag bit may be written into the target storage medium when the vehicle rolls off the production line.

[0052] In some embodiments, the method 100 further includes: when a first functional module needs to execute a first pending task, sending a first request to a second functional module, the first request being used to request that the functional module identifier of the first functional module and the corresponding first pending task be written into a target list, the second functional module being used to maintain the target list; and when a second pending task to be executed by a third functional module and a functional module identifier of the third functional module already exist in the target list, if the third functional module cancels the execution of the second pending task, sending a second request to the second functional module, the second request being used to request that the functional module identifier of the third functional module and the corresponding second pending task be deleted from the target list.

[0053] In some embodiments, sending a first request to a second functional module includes: sending a first request to a second functional module through a first interface; and sending a second request to a second functional module includes: sending a second request to a second functional module through a second interface, wherein the second interface is different from the first interface, the first interface is the interface corresponding to prohibiting the vehicle communication terminal from sleeping, and the second interface is the interface corresponding to allowing the vehicle communication terminal to sleep.

[0054] It should be understood that in the above scheme, specifically, the first functional module sends a first request to the second functional module through a first interface. The first interface can be regarded as an interface for requesting disabling sleep, specifically the PmDisableToSleep interface. Conversely, the second functional module sends a second request to the second functional module through a second interface. The second interface can be regarded as an interface for requesting allow sleep, specifically the PmEnableToSleep interface.

[0055] Step 102: Based on whether the call service status is in a call state, select one or more status information from the multiple status information to obtain the target status information, and determine the sleep control strategy of the vehicle communication terminal based on the target status information.

[0056] It should be understood that in step 102 above, the call service status of the vehicle communication terminal, the target list of the vehicle communication terminal (i.e., the target list associated with the vehicle communication terminal), or the vehicle operating mode are all one (or a single) piece of status information among multiple status information. Furthermore, step 102 describes dynamically determining the sleep control strategy of the vehicle communication terminal based on different combinations of information from multiple status information, rather than determining the corresponding sleep control strategy one by one through single status information and then accumulating the various sleep control strategies to obtain the final sleep control strategy of the vehicle communication terminal.

[0057] In one possible implementation, step 102, which selects at least one status information from the multiple status information based on whether the call service status is a call state, to obtain target status information, includes: if the call service status is a call state, determining that the target status information includes the call service status; if the call service status is not a call state, determining that the target status information includes the call service status, the target list, and the vehicle operating mode.

[0058] It should be understood that the above call service status is not the same as the call status, including both the call service status of waiting for callback and the idle status.

[0059] In the above technical solution, when the call service status is in a call state, the call service status is directly locked as the target status information. This enables a rapid response and blocks hibernation, ensuring the absolute continuity and real-time nature of the call service. In non-call states, the call service status, target list, and vehicle operating mode are comprehensively considered. This ensures that accurate hibernation decisions can be made based on a comprehensive system status when there are no urgent services. The hierarchical filtering mechanism in the above solution avoids the resource consumption and decision delays caused by redundant status detection in non-call states, and prevents hibernation judgment errors due to interference from other states in call states. Therefore, while ensuring the experience of critical services, it improves the accuracy and processing efficiency of hibernation control for in-vehicle communication terminals.

[0060] In one possible implementation, step 102, determining the sleep control policy of the vehicle communication terminal based on the target status information, includes: if the target status information includes a call service status, determining the sleep control policy as a first policy that prohibits the vehicle communication terminal from sleeping; if the target status information includes a call service status, a target list, and a vehicle operating mode, and if the target list is empty, determining the sleep control policy based on whether the call service status is a waiting callback status and the vehicle operating mode; if the target list is not empty, obtaining a requested sleep status, and determining the sleep control policy based on the requested sleep status, wherein the requested sleep status is the sleep status that the vehicle communication terminal should enter, carried in the sleep trigger request.

[0061] It should be understood that in the above scheme, if the target status information includes the call service status and the call service status is in a call state, the sleep control policy is directly determined to prohibit the vehicle communication terminal from sleeping (i.e., the first policy). That is, compared with the other two status information, the call service status has the highest priority and has the highest determination authority for the sleep control policy.

[0062] Furthermore, when the call service status is not in a call state, the hibernation control strategy can be determined in two branches. The first branch (target list is empty): the hibernation control strategy is determined based on whether the call service status is in a waiting callback state and the vehicle working mode; the second branch (target list is not empty): the hibernation control strategy is determined based on the request hibernation status.

[0063] In the above technical solution, when the target status information includes the call service status, the first strategy is directly set to prohibit the vehicle communication terminal from sleeping. This allows for rapid determination of the sleep control strategy based on core risk conditions, while prioritizing the normal operation of the call service and preventing communication interruption caused by the vehicle communication terminal sleeping during a call. When the target status information includes the call service status, the target list, and the vehicle operating mode, if the target list is empty, the sleep control strategy is determined comprehensively based on whether the call service status is in a waiting callback state and the vehicle operating mode. This can take into account subsequent service needs and the overall vehicle operation scenario, avoiding blind sleep. If the target list is not empty, the sleep control strategy is formulated based on the sleep request status carried in the sleep trigger request. This can align with the instruction requirements of the upper-level control unit and adapt to the actual task scenario of the vehicle communication terminal. The aforementioned solution establishes a layered and scenario-based hibernation decision-making and control mechanism for different service states, task loads, and vehicle operating conditions of in-vehicle communication terminals. Through differentiated branching logic, it adapts to various complex in-vehicle operating scenarios, avoiding the drawbacks of a uniform decision-making method. This ensures the stable operation of core communication services and in-vehicle functional tasks while accurately matching the instruction requirements of the upper-level control unit with the vehicle's operating mode. This effectively improves the accuracy and scenario adaptability of hibernation decisions for in-vehicle communication terminals, enabling reasonable control over the operating status of these terminals.

[0064] The first branch is explained below. Specifically, the target status information includes the call service status, the target list, and the vehicle working mode. The call service status is not a call status and the target list is empty.

[0065] In one possible implementation, the hibernation control policy is determined based on whether the call service status is a waiting callback status and the vehicle operating mode, including: when the call service status is a waiting callback status, the hibernation control policy is determined based on the vehicle operating mode; when the call service status is an idle status, the hibernation control policy is determined based on the request hibernation status.

[0066] It should be understood that in the above scheme, for the first sub-branch under the first branch (where the call service status is waiting for callback), the sleep control strategy is determined based on the vehicle's operating mode. This is because, in the waiting-for-call-back state, the vehicle communication terminal has potential communication needs. The triggering timing of callback communication is strongly correlated with the vehicle's driving and transportation operating modes; therefore, it is necessary to combine the vehicle's operating mode and match an appropriate sleep control strategy based on the vehicle's current operating condition. For the second sub-branch under the first branch (where the call service status is idle), the sleep control strategy is determined based on the request-to-sleep state. This is because, in the idle state and when the target list is empty, there is no communication task, and the vehicle's operating condition is no longer a sleep constraint. The sleep control strategy can be directly determined based on the request-to-sleep state carried in the sleep trigger request, simplifying the control logic.

[0067] The above technical solution uses two decision branches to determine the hibernation control strategy. When the call service status is in the waiting callback state, a vehicle operating mode is introduced, which preserves the responsiveness of callback communication while adapting to the vehicle's operational constraints. When the call service status is in the idle state, a hibernation control strategy is generated based on the requested hibernation status carried in the hibernation trigger request. This ensures compliance with the control intentions issued by the upper-level control unit. This solution performs a secondary refined judgment for scenarios with no call tasks and no background mounted tasks, distinguishing between standby and idle call service states. This balances the continuity of communication services with the instruction requirements of the upper-level control unit, reduces the probability of misjudgment in hibernation decisions, and further improves the refinement and rationality of the hibernation decision control mechanism of the vehicle communication terminal.

[0068] The following is a detailed description of the first sub-branch under the first branch (the call service status is waiting for callback).

[0069] In one possible implementation, the sleep control strategy is determined based on the vehicle's operating mode, including: when the vehicle's operating mode is transportation mode, the sleep control strategy is determined to allow the vehicle-mounted communication terminal to enter a deep sleep state, where transportation mode refers to the vehicle being in the storage and transportation phase; when the vehicle's operating mode is not transportation mode, it is determined whether a first time difference between the current moment and a first moment is greater than a first preset duration, where the first moment is the instant when the call service status is waiting for callback and the target list is empty, and a first timer starts counting at the first moment, where the first timer is the timer corresponding to the shallow sleep state; when the first time difference is greater than the first preset duration, the sleep control strategy is determined to allow the vehicle-mounted communication terminal to enter a shallow sleep state, where the power consumption level corresponding to the shallow sleep state is greater than the power consumption level corresponding to the deep sleep state.

[0070] It should be understood that in the above scheme, the first timer can be regarded as a shallow sleep timer. Shallow sleep refers to the low-power standby mode of the vehicle communication terminal, where only non-core business peripheral modules are turned off (this does not affect auxiliary peripheral components for basic communication functions such as callback, emergency wake-up, and bus monitoring), including multimedia interaction modules and service modules for high-speed data transmission. These modules can be woken up promptly to respond to various vehicle commands. Deep sleep refers to the lowest power consumption operating mode of the vehicle communication terminal, where only necessary functional modules are retained, such as the emergency call trigger module (used to trigger emergency call services), suitable for storage and transportation scenarios with long-term no communication needs.

[0071] It should also be understood that in the above scheme, when the call service status is in the waiting callback state and the vehicle's operating mode is transportation mode, the vehicle is in the storage and transportation stage such as factory storage and transportation or long-distance sea freight, and there are no drivers or passengers on board. There will be no communication interaction such as phone calls in the short term. Even if the call service status is in the waiting callback state, the restrictions of the waiting callback state do not need to take effect. However, deep sleep mode consumes less power and can reduce the power consumption of the vehicle communication terminal. Therefore, in this scenario, the vehicle communication terminal can be allowed to enter deep sleep mode. When the call service status is in the waiting callback state and the vehicle's operating mode is not transportation mode, there may be drivers or passengers on board with potential communication needs. If the vehicle communication terminal immediately enters shallow sleep mode, it will shorten the response speed of the vehicle communication terminal. Therefore, at the instant when there is no communication need in the waiting callback state, the first timer is started to reserve a buffer period (first preset duration). During the waiting period, the vehicle communication terminal remains awake and can answer pending calls. If no call is answered after the buffer period, it is determined that there is no short-term communication need, and the vehicle communication terminal is allowed to enter a shallow sleep state with lower power consumption. This can balance the timeliness of callback response and the power saving needs of the vehicle communication terminal.

[0072] In other words, the above scheme describes that, when the target status information includes call service status, target list, and vehicle operating mode, if the target list is empty, the call service status is a waiting-for-call-back status, and the vehicle operating mode is a transportation mode, the sleep control policy is determined to allow the vehicle communication terminal to enter deep sleep mode; if the target list is empty, the call service status is a waiting-for-call-back status, and the vehicle operating mode is not a transportation mode, a first timer needs to be started to determine the sleep control policy. If the target list is not empty, a sleep request state is introduced, and the sleep control policy is determined based on the sleep request state.

[0073] In the above technical solution, when the vehicle is in transportation mode, the sleep control strategy is set to deep sleep. This reduces the overall power consumption of the vehicle during storage and transportation, preventing battery (such as storage battery) depletion. When the vehicle is in non-transportation mode, a timeout mechanism is set. If the timeout exceeds a first preset duration, shallow sleep is adopted, which preserves basic wake-up and communication capabilities, allowing for rapid response to various vehicle commands. If the timeout does not occur, vehicle commands can be responded to immediately. This solution differentiates sleep power consumption levels based on the vehicle's stage, maximizing power saving in transportation scenarios to protect the battery, while maintaining basic functions and allowing for wake-up at any time during normal use. This solves the problem that a single sleep mode cannot adapt to the entire lifecycle of the vehicle. This solution optimizes the power management of the vehicle communication terminal, balancing power saving and ease of use.

[0074] In some embodiments, the method 100 further includes: when the first time difference is less than or equal to the first preset duration, determining the hibernation control strategy to prohibit the vehicle communication terminal from entering a shallow hibernation state.

[0075] It should be understood that when the first time difference does not exceed the first preset duration, the vehicle communication terminal maintains a normal wake-up state (prohibiting the vehicle communication terminal from entering a shallow sleep state), neither entering a shallow sleep state nor a deep sleep state, and can monitor the callback communication needs of the rescue platform in real time. Once a callback call instruction is received, a call link can be established immediately and communication services can be responded to in a timely manner.

[0076] The following is an explanation of the second sub-branch under the first branch (the call service status is idle).

[0077] In one possible implementation, the sleep control strategy is determined based on the requested sleep state, including: if the requested sleep state is a deep sleep state, determining whether a second time difference between the current time and a second time is greater than a second preset duration, where the second time is the instant when the call service state is idle and the target list is empty, and at the second time, a second timer starts counting, where the second timer is the timer corresponding to the deep sleep state; if the second time difference is greater than the second preset duration, determining the sleep control strategy to allow the vehicle communication terminal to enter a deep sleep state; if the requested sleep state is a shallow sleep state, sending an inquiry command to the functional module, and upon receiving a message from the functional module indicating no pending tasks, determining the sleep control strategy to allow the vehicle communication terminal to enter a shallow sleep state, where the inquiry command is used to inquire whether the functional module has any pending tasks.

[0078] It should be understood that in the above scheme, the second timer can be regarded as a deep sleep timer.

[0079] It should also be understood that in the above scheme, when the call service status is idle and the target list is empty, if the requested sleep state is deep sleep, it does not immediately enter deep sleep. Instead, a second timer is set with a second preset duration as a buffer waiting period. During the buffer waiting period, the vehicle communication terminal maintains complete communication reception capability, which allows for immediate response when communication needs arise. After the buffer waiting period, it can be determined that there is no communication service in the short term, and entry into deep sleep is allowed. This balances the communication response capability and low power consumption requirements of the vehicle communication terminal. When the call service status is idle and the target list is empty, if the requested sleep state is shallow sleep, to avoid the existence of background tasks, and the functional module identifier corresponding to the background task has not yet been written into the target list, each functional module can be queried to see if there are any unfinished tasks. Only when all functional modules have no pending services can the vehicle communication terminal be confirmed to enter shallow sleep. This can quickly reduce the power consumption of the vehicle communication terminal while ensuring uninterrupted service.

[0080] In the above technical solution, when the target status information includes call service status, target list, and vehicle operating mode, if the call service status is not in a call state (specifically, an idle state) and the target list is empty, the sleep control strategy determination process is completed in two paths. Specifically, when requesting a deep sleep state, a dedicated second timer is started to count (starting from the second moment). If the time interval between the current moment and the second moment reaches a second preset duration, the vehicle communication terminal is allowed to enter a deep sleep state. This can reserve a buffer window period to prevent the vehicle communication terminal from directly entering a deep sleep state when the target list is momentarily idle, thus preventing the inability to quickly respond to temporary task instructions. When requesting a shallow sleep state, an inquiry instruction is issued to confirm that there are no outstanding tasks before executing shallow sleep. This can prevent situations where the target list is empty but there are still tasks dependent on the vehicle communication terminal that have not yet ended (possibly because the corresponding functional module identifier has not yet been written into the target list). The above solution adds a delay de-jitter and task verification mechanism before hibernation, and distinguishes between deep and shallow hibernation pre-verification logic. This can not only avoid erroneous deep hibernation through the delay de-jitter mechanism, but also confirm the task status through query commands, thereby avoiding the error rate of hibernation operation from the source, further optimizing the power consumption management of the vehicle communication terminal, and enhancing the rigor of hibernation decision.

[0081] In some embodiments, the method 100 further includes: if the second time difference is less than or equal to the second preset duration, determining the hibernation control strategy to allow the vehicle communication terminal to enter a shallow hibernation state.

[0082] It should be understood that in the above scheme, the requested sleep state is a deep sleep state, while during the buffer waiting period (after requesting deep sleep), the vehicle communication terminal is allowed to enter a shallow sleep state (i.e., the vehicle communication terminal is prohibited from entering a deep sleep state). This is to ensure an immediate response when a communication request arises. At the same time, it will not deviate too much from the actual requested deep sleep state; both deep and shallow sleep states belong to the sleep state category. Furthermore, after the buffer waiting period, the vehicle communication terminal will be allowed to enter a deep sleep state, further meeting actual needs.

[0083] In some embodiments, the method 100 further includes: upon receiving feedback from the functional module that there is an pending task, determining the hibernation control policy to prohibit the vehicle communication terminal from entering a shallow hibernation state.

[0084] It should be understood that prohibiting the vehicle communication terminal from entering a shallow sleep state can be regarded as the vehicle communication terminal maintaining a normal wake-up state, which can meet the functional modules' reliance on the vehicle communication terminal when they continue to process tasks.

[0085] In one possible implementation, the method for determining the second preset duration includes: obtaining a first reference duration corresponding to the second timer, wherein the first reference duration is the minimum timing base for the second timer to perform timing; determining the magnification factor of the first reference duration based on the current state of the backup battery in the vehicle communication terminal and the vehicle model; and determining the product between the first reference duration and the magnification factor as the second preset duration.

[0086] It should be understood that in the above scheme, the first baseline duration can be 1 minute. The current state of the backup battery specifically refers to whether the backup battery is in use, including both used and unused states. The vehicle model is used to specifically indicate the vehicle's power type, adapting to the power supply capacity of the backup battery in different models, and adjusting the hibernation timer duration (such as the second preset duration mentioned above) and hibernation control intensity differently. The aforementioned power type or vehicle model includes pure electric vehicles, gasoline vehicles, or hybrid electric vehicles.

[0087] In the above technical solution, the minimum timing base of the second timer is obtained as the first reference duration. Then, combined with the current state of the backup battery and the vehicle model, the amplification factor of the first reference duration is matched. This allows for differentiated setting of the amplification factor, adapting to differences in the power supply status of the backup battery and vehicle model, thus exhibiting strong versatility. Subsequently, the product of the first reference duration and the amplification factor is determined as the second preset duration. This solution enables dynamic adaptive configuration of the sleep delay parameters. When the backup battery is activated, the delay can be appropriately increased, and when it is not activated, the duration can be reduced to save battery power consumption, while also matching the power consumption characteristics of pure electric, fuel, and hybrid vehicles. This improves the compatibility of the sleep control strategy with multiple operating conditions and vehicle model scenarios, enhancing the adaptability of the sleep control strategy.

[0088] In one possible implementation, the amplification factor of the first reference duration is determined based on the current state of the backup battery in the vehicle communication terminal and the vehicle model. This includes: determining the amplification factor as a first amplification factor when the current state is in use and the vehicle model is a pure electric vehicle; or determining the amplification factor as a second amplification factor when the current state is in use and the vehicle model is a gasoline vehicle or a hybrid electric vehicle; or determining the amplification factor as a third amplification factor when the current state is in use, wherein the first amplification factor is greater than the third amplification factor, and the third amplification factor is greater than the second amplification factor.

[0089] It should be understood that in the above scheme, after the main power supply of a pure electric vehicle is disconnected, there is no generator circuit for the engine, and the battery charge will only decrease, without any replenishment. If the amplification factor is too small and the second preset duration is too short, the vehicle communication terminal will enter a deep sleep state prematurely. Subsequently, the vehicle communication terminal cannot automatically restore its communication reception capability by relying on its own power supply. It can only be released from the sleep state after manual power-on. If an emergency call is triggered during this period, the vehicle communication terminal will not be able to respond, and the emergency rescue function will be completely disabled. For fuel vehicles or hybrid electric vehicles, the engine can be started to charge the backup battery. That is, even if the vehicle communication terminal enters a deep sleep state prematurely, it can restore communication after restarting the vehicle's power supply, providing a means of battery recovery. Therefore, the amplification factor can be reduced to shorten the waiting time (second preset duration). When the backup battery is not in use, the vehicle communication terminal is powered by the vehicle's power supply, and it will not experience a situation where it is permanently disconnected due to depletion of power. Therefore, the amplification factor can be taken as an intermediate value.

[0090] In the above technical solutions, the maximum amplification factor is selected when the backup battery is in use and the vehicle is a pure electric vehicle. This extends the deep sleep waiting time, during which the vehicle communication terminal can rely on its own backup battery for power, without excessive concern about battery power consumption. The ample window period prevents sudden service interruptions due to sleep. When the backup battery is in use and the vehicle is a gasoline or hybrid vehicle, the minimum amplification factor is selected. These vehicles can start the engine to supplement power, shortening the delay and reducing unnecessary power consumption of the backup battery. When the backup battery is not used, an intermediate amplification factor is used. This avoids the situation of power depletion during long standby periods due to complete reliance on the battery. The above solutions differentiate the delay length based on the power supply capacity of the backup battery, making the sleep timing rules conform to the actual power supply scenario and improving the rationality of overall sleep management in multi-vehicle scenarios.

[0091] Optionally, the first magnification is 12, the second magnification is 1, and the third magnification is 3.

[0092] The second branch is explained below: the call service status is not in a call state and the target list is not empty.

[0093] In one possible implementation, the sleep control strategy is determined based on the requested sleep state, including: if the requested sleep state is a shallow sleep state, determining whether the third time difference between the current time and the third time is greater than a first preset duration, where the third time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and the first timer starts counting at the third time, where the first timer is the timer corresponding to the shallow sleep state; if the third time difference is greater than the first preset duration, clearing the target list and determining the sleep control strategy to allow the vehicle communication terminal to enter a shallow sleep state; if the requested sleep state is a deep sleep state, determining whether the fourth time difference between the current time and the fourth time is greater than a second preset duration, where the fourth time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and the second timer starts counting at the fourth time, where the second timer is the timer corresponding to the deep sleep state; if the fourth time difference is greater than the second preset duration, clearing the target list and determining the sleep control strategy to allow the vehicle communication terminal to enter a deep sleep state.

[0094] It should be understood that in the above scheme, for the second branch, the hibernation control strategy can be determined based on the requested hibernation state. In the above scheme, the target list stores unfinished pending tasks that require the use of the vehicle communication terminal's resources. Under normal circumstances, hibernation should not be initiated directly to prevent tasks from being interrupted midway. However, the upper-level control unit has sent a hibernation trigger request, indicating a clear power-saving requirement at the vehicle level. This requirement should be met as closely as possible, meaning pending tasks cannot be processed indefinitely. Therefore, the corresponding first and second timers are started to set time limit buffers (buffer windows). During the buffer window, the pending tasks in the target list continue to be completed. If the target list is still not cleared after the timeout, the target list can be forcibly cleared, and a hibernation command can be executed (controlling the vehicle communication terminal to enter a shallow hibernation state or a deep hibernation state). This can both avoid the situation where the vehicle communication terminal can never hibernate due to individual dead tasks and the backup battery continues to deplete, and also allow time for normal pending services to be completed.

[0095] In the above technical solution, when the target status information includes call service status and target list, if the call service status is not a call status and the target list is not empty, the sleep control strategy determination process is completed in two ways. Specifically, when the requested sleep state is a shallow sleep state, the corresponding first timer is started to count down and waits for a first preset duration. After the timeout, the target list is cleared and the vehicle communication terminal is allowed to enter a shallow sleep state. When the requested sleep state is a deep sleep state, the corresponding second timer is started to count down and waits for a second preset duration. After the timeout, the target list is cleared and the vehicle communication terminal is allowed to enter a deep sleep state. Both of the above processing processes can reserve a processing window for unfinished tasks. The above solution sets a timeout fallback mechanism for scenarios with background tasks, not immediately terminating the associated process (entering a deep / shallow sleep state), but forcibly clearing the background tasks and entering a sleep state after the timeout. This ensures normal business operations as much as possible, while preventing task freezes that could prevent the vehicle communication terminal from entering sleep mode and cause continuous power consumption, thus improving the fault tolerance and stability of the sleep logic.

[0096] In some embodiments, the method 100 further includes: when the third time difference is less than or equal to the first preset duration, determining the hibernation control strategy to prohibit the vehicle communication terminal from entering a shallow hibernation state; and when the fourth time difference is less than or equal to the second preset duration, determining the hibernation control strategy to allow the vehicle communication terminal to enter a deep hibernation state.

[0097] In one possible implementation, the method 100 further includes: after the first timer starts timing, detecting whether a functional module identifier is written into the target list within the first preset duration; if a functional module identifier is written into the target list within the first preset duration, controlling the first timer to restart timing; and after the second timer starts timing, detecting whether a functional module identifier is written into the target list within the second preset duration; if a functional module identifier is written into the target list within the second preset duration, preventing the second timer from restarting timing.

[0098] It should be understood that in the above scheme, the first timer corresponds to the shallow sleep process. In the shallow sleep state, only non-core business peripheral modules are shut down, while other core modules remain operational. If a new pending task is added to the target list during the buffer window, it indicates that a new pending task has been generated, and the first preset duration needs to be extended, i.e., the first timer needs to be reset. This allows for normal execution and completion time for new tasks, preventing them from being forcibly interrupted and ensuring that all vehicle interaction or reporting services can achieve a complete closed loop. However, the second timer corresponds to the deep sleep process. In the deep sleep state, core modules will eventually be shut down. The vehicle having issued a sleep trigger request (requesting deep sleep state) indicates a strong demand for low-power power-off. Even if a small number of temporary tasks are added during the buffer window, the deep sleep timing cannot be delayed indefinitely to prevent the backup battery from continuously consuming power and causing power depletion. Therefore, the second timer cannot be reset. After the timer expires, the target list is cleared and the vehicle communication terminal is controlled to enter the deep sleep state.

[0099] In the above technical solution, differentiated timing reset logic is set for the two types of timers. Specifically, if a new background task is added while the first timer is in the timing phase, the timing is restarted. This ensures that newly added background tasks can continue to be processed. During the timing of the second timer, if a new background task is added, the timing is not reset, and the deep sleep time limit requirement is strictly enforced. The above solution differentiates the timers for deep and shallow sleep. When a task is refreshed, shallow sleep supports timing reset, while deep sleep does not. This ensures that newly added background tasks can be executed normally (during shallow sleep) and prevents power consumption due to long-term non-sleep in scenarios such as storage and transportation (during deep sleep). This makes the sleep timing rules more in line with the design intentions of different sleep levels, improving the overall flexibility and power consumption control of sleep management.

[0100] In some embodiments, when the requested sleep state is a shallow sleep state, if it is detected that the third functional module sends a first sub-request to the second functional module through the first interface, it is determined whether the second functional module has received the first sub-request. The first sub-request is used to request that the functional module identifier of the third functional module and the corresponding third task to be processed be written into the target list. After the second functional module receives the first sub-request, it stores the functional module identifier of the third functional module and the corresponding third task to be processed into the target list, and the first timer restarts the timing. If the time difference between the current time and the time when the timing starts is greater than the first preset duration, it is determined that the vehicle communication terminal can enter the shallow sleep state, and the vehicle communication terminal is controlled to enter the shallow sleep state.

[0101] In some embodiments, when the requested sleep state is a deep sleep state, if it is detected that the third functional module sends a first sub-request to the second functional module through the first interface, it is determined whether the second functional module has received the first sub-request; after the second functional module receives the first sub-request, the functional module identifier of the third functional module and the corresponding third task to be processed are stored in the target list, and it is determined whether the time difference between the current time and the fourth time is greater than the second preset duration, at which the second timer starts counting; if the time difference between the current time and the fourth time is greater than the second preset duration, it is determined that the vehicle communication terminal can enter the deep sleep state, and the vehicle communication terminal is controlled to enter the deep sleep state.

[0102] In some embodiments, the method 100 further includes: if no functional module identifier is written into the target list within the first preset duration, keeping the first timer running; and if no functional module identifier is written into the target list within the second preset duration, keeping the second timer running.

[0103] It's important to clarify here that when the call service status is in a call state, the system has the highest authority to determine the sleep control policy, meaning it has veto power over sleep trigger requests. When the call service status is in a waiting-for-call-back state, the target list is empty, and the vehicle operating mode is transport mode, the vehicle communication terminal can be allowed to enter a deep sleep state even if the sleep trigger request indicates a shallow sleep state. Furthermore, when determining the sleep control policy, if the target status information includes the call service status, the target list, and the vehicle operating mode, the call service status should be prioritized, followed by the target list; when the target list is empty, the vehicle operating mode should be considered.

[0104] Step 103: Based on the sleep control strategy, perform sleep control on the vehicle communication terminal.

[0105] In some embodiments, step 103 includes: controlling the vehicle communication terminal to remain in a wake-up state when the sleep control policy instructs the vehicle communication terminal to prohibit sleep; or, putting the vehicle communication terminal into sleep mode when the sleep control policy instructs the vehicle communication terminal to sleep.

[0106] In addition, the working states of the vehicle communication terminal include wake-up state (normal working state), shallow sleep state, and deep sleep state.

[0107] Figure 2 This is a schematic diagram of a process for controlling a vehicle-mounted communication terminal provided in an embodiment of this application.

[0108] For example, such as Figure 2As shown, the system receives a sleep trigger request from the upper-level control unit and, in response, acquires multiple status information, including the call service status, target list, and vehicle operating mode of the vehicle communication terminal. When the call service status is in a call state, the sleep control strategy is set to the first strategy of prohibiting the vehicle communication terminal from sleeping. When the call service status is not in a call state, an empty target list is detected. When the target list is empty and the call service status is in a waiting-for-call-back state, the system checks whether the vehicle operating mode is in a transportation mode. When the vehicle operating mode is in a transportation mode, the sleep control strategy is set to allow the vehicle communication terminal to enter a deep sleep state. When the vehicle operating mode is not in a transportation mode, a first timer is started, i.e., it is determined whether the first time difference between the current time and the first time is greater than a first preset duration, and the first timer starts counting at the first time. When the first time difference is greater than the first preset duration, the sleep control strategy is set to allow the vehicle communication terminal to enter a shallow sleep state. When the target list is empty and the call service status is idle, if the requested sleep state is deep sleep, a second timer is started. This involves determining whether the second time difference between the current time and the second time is greater than a second preset duration, and at that second time, the second timer begins counting. If the second time difference is greater than the second preset duration, the sleep control strategy is set to allow the vehicle communication terminal to enter deep sleep. If the requested sleep state is shallow sleep, an inquiry command is sent to the functional module. Upon receiving a message from the functional module indicating no pending tasks, the sleep control strategy is set to allow the vehicle communication terminal to enter shallow sleep. When the target list is not empty, if the requested sleep state is shallow sleep, a first timer is started. This involves determining whether the third time difference between the current time and the third time is greater than a first preset duration, and at that third time, the first timer begins counting. If the third time difference is greater than the first preset duration, the target list is cleared, and the sleep control strategy is set to allow the vehicle communication terminal to enter shallow sleep. If the requested sleep state is deep sleep state, start the second timer, that is, determine whether the fourth time difference between the current time and the fourth time is greater than the second preset duration, and the second timer starts counting at the fourth time; when the fourth time difference is greater than the second preset duration, clear the target list and determine the sleep control policy to allow the vehicle communication terminal to enter deep sleep state.

[0109] Figure 3 This is a schematic diagram of the structure of a device for controlling a vehicle-mounted communication terminal provided in an embodiment of this application.

[0110] For example, the device is installed on the vehicle-mounted communication terminal, such as... Figure 3 As shown, the device 300 includes: The acquisition module 301 is used to respond to the sleep trigger request sent by the upper control unit and acquire multiple status information, including the call service status of the vehicle communication terminal, the target list and the vehicle working mode. The target list is used to store the identifiers of the functional modules that are running and depend on the vehicle communication terminal. The sleep trigger request is used to initiate a sleep application for the vehicle communication terminal and enter the sleep verification process. The determining module 302 is used to select one or more status information from the multiple status information based on whether the call service status is in a call state, to obtain target status information, and to determine the sleep control strategy of the vehicle communication terminal based on the target status information. The control module 303 is used to control the vehicle-mounted communication terminal to go into sleep mode based on the sleep control strategy.

[0111] Optionally, the determining module 302 is specifically used to: determine that the target status information includes the call service status when the call service status is a call state; and determine that the target status information includes the call service status, the target list, and the vehicle operating mode when the call service status is not a call state.

[0112] Optionally, the determining module 302 is further configured to: if the target status information includes a call service status, and the call service status is a call state, determine the sleep control policy as a first policy to prohibit the vehicle communication terminal from sleeping; if the target status information includes a call service status, a target list, and a vehicle operating mode, and the target list is empty, determine the sleep control policy based on whether the call service status is a waiting callback state and the vehicle operating mode; if the target list is not empty, obtain the requested sleep state, and determine the sleep control policy based on the requested sleep state, wherein the requested sleep state is the sleep state that the vehicle communication terminal should enter as carried in the sleep trigger request.

[0113] Optionally, the determining module 302 is further configured to: determine the hibernation control strategy based on the vehicle working mode when the call service status is a waiting callback status; and determine the hibernation control strategy based on the request hibernation status when the call service status is an idle status.

[0114] Optionally, the determining module 302 is further configured to: when the vehicle's operating mode is transportation mode, determine the hibernation control strategy to allow the vehicle-mounted communication terminal to enter a deep hibernation state, where the transportation mode is when the vehicle is in the storage and transportation phase; when the vehicle's operating mode is not transportation mode, determine whether the first time difference between the current moment and the first moment is greater than a first preset duration, where the first moment is the instant when the call service status is waiting for callback and the target list is empty, and at the first moment, the first timer starts counting, where the first timer is the timer corresponding to the shallow hibernation state; when the first time difference is greater than the first preset duration, determine the hibernation control strategy to allow the vehicle-mounted communication terminal to enter a shallow hibernation state, where the power consumption level corresponding to the shallow hibernation state is greater than the power consumption level corresponding to the deep hibernation state.

[0115] Optionally, the determining module 302 is further configured to: when the requested sleep state is a deep sleep state, determine whether the second time difference between the current time and the second time is greater than a second preset duration, the second time being the instant when the call service state is idle and the target list is empty, and when the second time starts counting, the second timer being the timer corresponding to the deep sleep state; when the second time difference is greater than the second preset duration, determine the sleep control policy to allow the vehicle communication terminal to enter a deep sleep state; when the requested sleep state is a shallow sleep state, send an inquiry instruction to the functional module, and when receiving a message from the functional module that there are no pending tasks, determine the sleep control policy to allow the vehicle communication terminal to enter a shallow sleep state, the inquiry instruction being used to inquire whether the functional module has any pending tasks.

[0116] Optionally, the acquisition module 301 is specifically used to acquire the first reference duration corresponding to the second timer, the first reference duration being the minimum timing base for the second timer to perform timing; the determination module 302 is further used to: determine the magnification factor of the first reference duration based on the current state of the backup battery in the vehicle communication terminal and the vehicle model; and determine the product between the first reference duration and the magnification factor as the first preset duration.

[0117] Optionally, the determining module 302 is further configured to: determine the magnification factor as a first magnification factor when the current state is a usage state and the vehicle type is a pure electric vehicle; or, determine the magnification factor as a second magnification factor when the current state is a usage state and the vehicle type is a fuel vehicle or a hybrid electric vehicle; or, determine the magnification factor as a third magnification factor when the current state is an unused state, wherein the first magnification factor is greater than the third magnification factor and the third magnification factor is greater than the second magnification factor.

[0118] Optionally, the determining module 302 is further configured to: when the requested sleep state is a shallow sleep state, determine whether the third time difference between the current time and the third time is greater than a first preset duration, where the third time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and at the third time the first timer starts counting, where the first timer is the timer corresponding to the shallow sleep state; when the third time difference is greater than the first preset duration, clear the target list and determine the sleep control strategy to allow the vehicle communication terminal to enter a shallow sleep state; when the requested sleep state is a deep sleep state, determine whether the fourth time difference between the current time and the fourth time is greater than a second preset duration, where the fourth time is the instant after the upper-level control unit sends the sleep trigger request and the target list is not empty, and at the fourth time the second timer starts counting, where the second timer is the timer corresponding to the deep sleep state; when the fourth time difference is greater than the second preset duration, clear the target list and determine the sleep control strategy to allow the vehicle communication terminal to enter a deep sleep state.

[0119] Optionally, the device 300 further includes: a detection module, configured to detect whether a function module identifier is written into the target list within the first preset duration after the first timer starts timing; the control module 303, configured to control the first timer to restart timing if a function module identifier is written into the target list within the first preset duration; and the detection module, configured to detect whether a function module identifier is written into the target list within the second preset duration after the second timer starts timing; the control module 303, configured to prevent the second timer from restarting timing if a function module identifier is written into the target list within the second preset duration.

[0120] Figure 4 This is a schematic diagram of the structure of a controller provided in an embodiment of this application.

[0121] For example, such as Figure 4 As shown, the controller 400 includes a storage module 401 and a processing module 402. The storage module 401 stores executable program code 403, and the processing module 402 is used to call and execute the executable program code 403 to perform a method for controlling a vehicle-mounted communication terminal.

[0122] Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0123] For example, such as Figure 5As shown, the vehicle 500 includes a memory 501 and a processor 502. The memory 501 stores executable program code 503, and the processor 502 is used to call and execute the executable program code 503 to perform a method for controlling an in-vehicle communication terminal.

[0124] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a method for controlling a vehicle-mounted communication terminal provided in embodiments of this application.

[0125] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0126] When each functional module is divided according to its corresponding function, the device may further include a determining module, an acquiring module, a controlling module, and a detecting module. It should be noted that all relevant content in the above method embodiments can be referenced in the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0127] It should be understood that the apparatus provided in this embodiment is used to execute the above-described method for controlling a vehicle-mounted communication terminal, and therefore can achieve the same effect as the above-described implementation method.

[0128] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant executable program code.

[0129] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0130] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a method for controlling a vehicle communication terminal provided in the above embodiments.

[0131] This embodiment also provides a computer-readable storage medium storing executable program code. When the executable program code is run on a computer, the computer executes the above-described method steps to implement the method for controlling a vehicle-mounted communication terminal provided in the above embodiment.

[0132] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the method for controlling a vehicle-mounted communication terminal provided in the above embodiment.

[0133] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0134] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0135] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for controlling a vehicle-mounted communication terminal, characterized in that, The method is executed by an in-vehicle communication terminal, and the method includes: In response to a sleep trigger request sent by the upper-level control unit, multiple status information is obtained, including the call service status of the vehicle communication terminal, the target list, and the vehicle working mode. The target list is used to store the identifiers of functional modules that are running and depend on the vehicle communication terminal. The sleep trigger request is used to initiate a sleep application for the vehicle communication terminal and enter the sleep verification process. Based on whether the call service status is in a call state, one or more status information are selected from the multiple status information to obtain target status information, and based on the target status information, the sleep control strategy of the vehicle communication terminal is determined. Based on the aforementioned sleep control strategy, sleep control is applied to the vehicle-mounted communication terminal.

2. The method according to claim 1, characterized in that, The step of selecting at least one status information from the plurality of status information based on whether the call service status is in a call state to obtain target status information includes: When the call service status is in a call state, the target status information is determined to include the call service status; If the call service status is not in a call state, the target status information is determined to include the call service status, target list, and vehicle operating mode.

3. The method according to claim 2, characterized in that, The step of determining the sleep control strategy for the vehicle-mounted communication terminal based on the target state information includes: If the target status information includes the call service status, the sleep control policy is determined as the first policy to prohibit the vehicle communication terminal from sleeping; If the target status information includes call service status, target list, and vehicle working mode, and the target list is empty, the hibernation control strategy is determined based on whether the call service status is in a waiting callback state and the vehicle working mode; if the target list is not empty, the requested hibernation state is obtained, and the hibernation control strategy is determined based on the requested hibernation state, wherein the requested hibernation state is the hibernation state that the vehicle communication terminal should enter as carried in the hibernation trigger request.

4. The method according to claim 3, characterized in that, The step of determining the sleep control strategy based on whether the call service status is in a waiting callback state and the vehicle operating mode includes: When the call service status is in the waiting callback state, the sleep control strategy is determined based on the vehicle working mode; When the call service status is idle, the sleep control policy is determined based on the requested sleep status.

5. The method according to claim 4, characterized in that, The step of determining the hibernation control strategy based on the vehicle's operating mode includes: When the vehicle's operating mode is transportation mode, the hibernation control strategy is determined to allow the vehicle-mounted communication terminal to enter deep hibernation state, where the transportation mode is when the vehicle is in the storage and transportation phase. When the vehicle's operating mode is not transportation mode, determine whether the first time difference between the current time and the first time is greater than the first preset duration. The first time is the instant when the call service status is waiting for callback and the target list is empty. The first time is when the first time starts counting down. The first time is the timer corresponding to the shallow sleep state. If the first time difference is greater than the first preset duration, the sleep control strategy is determined to allow the vehicle communication terminal to enter a shallow sleep state, where the power consumption level corresponding to the shallow sleep state is greater than the power consumption level corresponding to the deep sleep state.

6. The method according to claim 4, characterized in that, The step of determining the sleep control strategy based on the requested sleep state includes: When the requested sleep state is a deep sleep state, determine whether the second time difference between the current time and the second time is greater than the second preset duration. The second time is the instant when the call service state is idle and the target list is empty. The second time is when the second time starts counting. The second time is the timer corresponding to the deep sleep state. If the second time difference is greater than the second preset duration, the hibernation control strategy is determined to allow the vehicle communication terminal to enter a deep hibernation state; When the requested sleep state is a shallow sleep state, an inquiry command is sent to the functional module. If the functional module returns that there are no pending tasks, the sleep control policy is determined to allow the vehicle communication terminal to enter a shallow sleep state. The inquiry command is used to inquire whether there are any pending tasks in the functional module.

7. The method according to claim 6, characterized in that, The method for determining the second preset duration includes: Obtain the first reference duration corresponding to the second timer, where the first reference duration is the minimum timing base for the second timer to perform timing. Based on the current state of the backup battery in the vehicle communication terminal and the vehicle model, the magnification factor of the first reference duration is determined. The product of the first reference duration and the magnification is determined as the second preset duration.

8. The method according to claim 7, characterized in that, The step of determining the magnification factor for the first reference duration based on the current state of the backup battery in the vehicle communication terminal and the vehicle model includes: When the current state is a usage state and the vehicle type is a pure electric vehicle, the magnification is determined as the first magnification; or, When the current state is a usage state and the vehicle type is a gasoline vehicle or a hybrid electric vehicle, the magnification is determined as the second magnification; or, When the current state is unused, the magnification is determined to be the third magnification, where the first magnification is greater than the third magnification and the third magnification is greater than the second magnification.

9. The method according to claim 3, characterized in that, The step of determining the sleep control strategy based on the requested sleep state includes: When the requested sleep state is a shallow sleep state, it is determined whether the third time difference between the current time and the third time is greater than the first preset duration. The third time is the instant when the target list is not empty after the upper control unit sends the sleep trigger request, and the first timer starts counting at the third time. The first timer is the timer corresponding to the shallow sleep state. If the third time difference is greater than the first preset duration, the target list will be cleared and the sleep control strategy will be set to allow the vehicle communication terminal to enter a shallow sleep state. When the requested sleep state is a deep sleep state, determine whether the fourth time difference between the current time and the fourth time is greater than the second preset duration. The fourth time is the instant when the target list is not empty after the upper layer control unit sends the sleep trigger request, and the second timer starts counting at the fourth time. The second timer is the timer corresponding to the deep sleep state. If the fourth time difference is greater than the second preset duration, the target list will be cleared and the hibernation control strategy will be set to allow the vehicle communication terminal to enter a deep hibernation state.

10. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 9.

Images