Vehicle control method, vehicle and electronic equipment

Abstract

The invention relates to a vehicle control method, a vehicle and electronic equipment, and belongs to the technical field of vehicle power management, and the vehicle control method comprises the steps that when it is detected that the vehicle meets a preset sleep condition, a telematics box is switched from a normal mode to a shallow sleep mode, a shallow sleep timer is started, and a wake-up event is monitored during the shallow sleep mode; in the shallow sleep mode, if the shallow sleep timer is overtime and a wake-up event is not detected, the remote information processing box and the remote information service provider cloud platform execute state synchronization, and a synchronous timer is started; and if the state synchronization execution is finished before the synchronization timer is overtime, or the synchronization timer is overtime, the telematics box enters a deep sleep mode.

Description

Technical Field

[0001] This application relates to the technical field of vehicle power management, and more particularly to a vehicle control method, a vehicle, and electronic equipment. Background Technology

[0002] With the development of vehicle connectivity, the Telematics Box (T-BOX), as a core device for information interaction between the vehicle and the cloud, is widely used in business scenarios such as remote control, emergency calls, and vehicle status monitoring. Telematics Boxes typically have multiple power modes, including normal mode, shallow sleep mode, and deep sleep mode, to reduce overall vehicle power consumption while ensuring functional availability.

[0003] In existing technologies, telematics boxes typically employ a tiered sleep strategy after the vehicle is turned off. This involves switching from a normal mode to a shallow sleep mode to reduce power consumption, and then, if no wake-up event occurs after a period of time, switching to a deep sleep mode. However, these technologies have the following drawbacks: First, the state switching process lacks a transition mechanism, leading to data transmission interruptions and service connection anomalies, impacting user experience. Second, the state is not synchronized with the cloud platform before entering deep sleep, causing the cloud to misjudge the device status, resulting in failed remote operations by the user. Furthermore, the timing parameters for sleep transitions are fixed and cannot be dynamically adjusted according to usage scenarios, making it difficult to balance power consumption optimization and functional availability. Summary of the Invention

[0004] This application addresses, to at least some extent, one of the technical problems in the related art.

[0005] Therefore, this application aims to provide a vehicle control method, a vehicle, and an electronic device.

[0006] To achieve the above objectives, in a first aspect, this application provides a vehicle control method, comprising: When the vehicle is detected to meet the preset sleep conditions, the telematics box switches from normal mode to shallow sleep mode, starts the shallow sleep timer, and monitors wake-up events during the shallow sleep mode. In the shallow sleep mode, if the shallow sleep timer times out and no wake-up event is detected, the remote information processing box synchronizes its execution status with the remote information service provider's cloud platform and starts a synchronization timer. If the state synchronization is completed before the synchronization timer expires, or if the synchronization timer expires, the remote information processing box enters deep sleep mode.

[0007] In the technical solution, after the shallow sleep timer expires, the system first synchronizes with the cloud platform's execution status and starts a synchronization timer to ensure that the cloud accurately knows that the device is about to enter a deep sleep state. This avoids the cloud misjudging and issuing instructions, which could lead to user operation failures. After synchronization is completed or the timer expires, the system enters deep sleep, which not only ensures the consistency between the vehicle and cloud states but also prevents system deadlock caused by network anomalies.

[0008] In some embodiments of this application, before switching from normal mode to shallow hibernation mode, the method further includes: When the vehicle is detected to meet the preset sleep conditions, the remote information processing box switches from normal mode to extended mode, starts the extended timer, and monitors wake-up events during the extended mode. In the extended mode, if the extended timer times out and no wake-up event is detected, the system enters the shallow sleep mode. In the extended mode, the remote information processing box performs uplink data transmission and shuts down the service-oriented scalable IP middleware service.

[0009] In the technical solution, an extended mode is introduced as a buffer phase between the normal mode and the shallow sleep mode. The shallow sleep mode is only entered when the extended timer expires and there is no wake-up event. By performing data uploading and service shutdown operations in parallel in the extended mode, it is ensured that the preparation work before power-down can be completed in an orderly manner during the buffer period, avoiding data loss and service abnormalities caused by directly entering the shallow sleep mode, and further improving the smoothness and reliability of the state transition process.

[0010] In some embodiments of this application, in the extended mode, if the extended timer times out and no wake-up event is detected, the remote information processing box enters a shallow sleep mode, including: During the operation of the extended timer, the telematics box continuously monitors wake-up events; If a wake-up event is detected, immediately revert to the normal mode; If the extended timer times out and no wake-up event is detected, the remote information processing box enters the shallow sleep mode.

[0011] In the technical solution, by continuously monitoring wake-up events in extended mode and immediately reverting to normal mode when a wake-up is detected, the service can be quickly restored when the user initiates an operation during the buffer period, avoiding experience interruption caused by the irreversibility of the hibernation process; at the same time, shallow hibernation is only entered when the extended timer expires and there is no wake-up event, ensuring the accuracy and orderliness of state transition.

[0012] In some embodiments of this application, the pre-configured duration of the shallow sleep timer is remotely configured by the cloud platform of the remote information service provider and sent to the remote information processing box through configuration management instructions. After receiving the configuration management instructions, the remote information processing box immediately updates the pre-configured duration without restarting the device.

[0013] In this technical solution, the duration of the shallow sleep timer is configured remotely via the cloud, allowing the sleep strategy to be dynamically adjusted according to vehicle usage scenarios. This ensures functional availability while minimizing power consumption, overcoming the shortcomings of traditional fixed parameters that cannot accommodate diverse needs. Configuration commands take effect immediately upon issuance without requiring a device restart, ensuring not only real-time and convenient configuration updates but also avoiding service interruptions or functional degradation caused by restarts. This is particularly suitable for scenarios requiring long-term stable operation.

[0014] In some embodiments of this application, in the shallow sleep mode, if a wake-up event is detected, the remote information processing box resets the shallow sleep timer and restarts the timing.

[0015] In the technical solution, a wake-up reset mechanism is set up so that when the device detects user operation or other wake-up events during shallow sleep, it can restart the timer. This avoids being forced into deep sleep due to the expiration of a single timer, thereby ensuring that the device can remain responsive when there is continuous demand, improving user experience and system flexibility.

[0016] In some embodiments of this application, the synchronization of the remote information processing box with the cloud platform of the remote information service provider includes: The remote information processing box sends a deep hibernation notification to the cloud platform of the remote information service provider. The deep hibernation notification carries a logout reason code and a status code to inform the cloud platform of the remote information service provider that the remote information processing box is about to enter a deep hibernation state that does not support remote control. The remote information processing box receives a confirmation response from the cloud platform of the remote information service provider.

[0017] In the technical solution, the deep hibernation notification carries the logout reason code and status code, enabling the cloud platform to accurately identify the reason for the device status change and the target status, thereby achieving accurate status updates and avoiding invalid command issuance and user operation failures caused by status misjudgment. By receiving the confirmation response returned by the cloud, the reliable completion of the status synchronization process is ensured, laying the foundation for subsequent deep hibernation. At the same time, the logout reason code can also be used to provide users with detailed device status prompts, improving interactive transparency and system reliability.

[0018] In some embodiments of this application, the cloud platform of the remote information service provider, in response to receiving the deep hibernation notification, sets a remote control unsupported flag to prohibit the user terminal from sending remote control commands to the remote information processing box.

[0019] In the technical solution, a remote control-unsupported identifier is set through the cloud platform. The device status is marked and managed from the platform side to ensure that the device no longer receives or processes remote control commands after entering deep sleep. This avoids the problem of user operation failure due to cloud misjudgment and improves the accuracy of vehicle-cloud collaboration and user experience.

[0020] In some embodiments of this application, the step of the remote information processing box entering deep sleep mode if the state synchronization is completed before the synchronization timer expires, or if the synchronization timer expires, includes: If the state synchronization is completed before the synchronization timer expires, the remote information processing box immediately enters deep sleep mode; If the synchronization timer times out, the remote information processing box is forced into deep sleep mode and the remote information service provider's cloud platform is notified.

[0021] The technical solution employs two paths for entering deep sleep: successful synchronization and synchronization timeout. This achieves comprehensive coverage of both normal and abnormal scenarios. In the case of successful synchronization, the device immediately enters deep sleep, ensuring real-time consistency between the vehicle and cloud states and preventing the cloud from misinterpreting and issuing commands. In the case of synchronization timeout, the device is forced into deep sleep, and a subsequent notification mechanism ensures the cloud ultimately learns the device's status, effectively preventing system deadlocks caused by network latency or packet loss. This mechanism significantly enhances the system's robustness and reliability while maintaining consistency between vehicle and cloud states.

[0022] In a second aspect, this application provides a vehicle including a controller for implementing the vehicle control method as described in the first aspect.

[0023] In a third aspect, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the vehicle control method as described in the first aspect.

[0024] As can be seen from the above technical solutions, additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall process of the vehicle control method according to the embodiments of this application; Figure 2 This is a schematic diagram of the extended mode state transition process according to the embodiments of this application; Figure 3 This is a timing diagram of the timing management mechanism according to the embodiments of this application; Figure 4 This is a flowchart of the state synchronization during the deep hibernation preparation phase according to the embodiments of this application; Figure 5 This is a schematic diagram of a computer device according to an embodiment of this application.

[0026] In the above figures: 40. Bus; 41. Processor; 42. Memory; 43. Communication interface. Detailed Implementation

[0027] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0028] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments. In the automotive industry, with the rapid development of connected technologies, information interaction between vehicles and the cloud is becoming increasingly frequent. Intelligent applications such as remote control, emergency calls, and vehicle status monitoring have become standard features in modern cars. The Telematics Box (T-BOX), as the core device for communication between vehicles and the cloud, undertakes key tasks such as data acquisition, command forwarding, and status reporting, and is an important hardware foundation for realizing vehicle connectivity.

[0029] The telematics box typically connects to the vehicle's electronic and electrical systems, including the body control module, powertrain, and entertainment system, via a Controller Area Network (CAN) bus to collect in-vehicle data and issue control commands. Simultaneously, it interacts with the cloud platform of a Telematics Service Provider (TSP) through a mobile communication network, uploading vehicle status information to the cloud and receiving remote control commands from the cloud or user terminals, thereby enabling remote monitoring and control of the vehicle.

[0030] To balance functional availability with overall vehicle power consumption, telematics boxes are typically designed with multiple power modes to adapt to the power consumption requirements of different usage scenarios. These mainly include the following modes: Normal Mode, Sleep Mode, and Deep Sleep Mode.

[0031] Normal mode is the full-function operating state, where all communication modules, data processing units and peripheral interfaces are active, supporting all services such as remote control, data upload, and emergency calls.

[0032] Shallow sleep mode, also known as low power consumption mode, is a mode in which the remote information processing box shuts down non-core functional modules, such as some communication links and data processing units, and retains only the necessary wake-up detection circuits so that it can quickly resume normal mode when a wake-up event is detected.

[0033] Deep sleep mode, also known as ultra-low power mode, disables most functional modules of the remote information processing box in this mode, retaining only the most basic wake-up capabilities, such as hardware pin wake-up, to achieve the lowest static power consumption.

[0034] After the vehicle is turned off, the telematics box can switch between the above modes according to the preset sleep strategy, so as to extend the vehicle battery's range as much as possible while ensuring the availability of necessary functions.

[0035] In existing technologies, telematics boxes typically employ a tiered sleep strategy after the vehicle is turned off. First, they switch directly from normal mode to shallow sleep mode, disabling some non-core functions to reduce power consumption. After maintaining shallow sleep mode for a period, if there are no wake-up events, they further switch to deep sleep mode to achieve even lower power consumption. This tiered sleep mechanism balances functional availability and overall vehicle power consumption to some extent, but its process design is relatively simple, mainly relying on preset fixed parameters and one-way state transitions, lacking adaptability to dynamic scenarios and interaction requirements.

[0036] Specifically, the aforementioned prior art has the following disadvantages: First, the process of directly switching from normal mode to shallow sleep mode lacks a buffer, causing ongoing uplink data transmission to be forcibly interrupted. For example, when the vehicle is turned off, the telematics box may still be uploading driving logs, location information, or diagnostic data to the cloud. If it switches directly to shallow sleep mode, this data will not be transmitted completely, resulting in data loss. Simultaneously, the Scalable service-Oriented Middleware over IP (SOME / IP) service is forcibly terminated without completing shutdown preparations, causing abnormal service connection drops. For users, the intuitive experience is that the remote operation they are using suddenly fails, requiring them to re-initiate the request, severely impacting user experience and service reliability.

[0037] Secondly, the remote information processing box failed to synchronize its status with the remote information service provider's cloud platform before entering deep sleep mode, leading to a discrepancy between the vehicle's and the cloud's perception of the device's status. Even after the device had actually entered deep sleep mode, the cloud platform still misjudged it as being remotely controllable and continued to send remote control commands to the device. Since the device could no longer respond to these commands, users often received operation failure or unresponsive device messages when operating through the mobile application, while the platform still displayed the device status as online or normal. This inconsistency in status information not only reduced user trust in the system but also increased the communication burden of invalid commands sent by the cloud.

[0038] Furthermore, the timing parameters for transitioning from shallow to deep sleep are fixed and cannot be remotely adjusted based on different vehicle usage modes and scenarios. For example, in long-distance transportation, vehicles may be parked for extended periods but need to maintain a certain level of responsiveness; a fixed, short shallow sleep duration may cause the device to enter deep sleep prematurely, affecting functional availability. Conversely, in daily commuting scenarios, a fixed, long shallow sleep duration may result in insufficient power consumption optimization, accelerating battery depletion. This makes it difficult for the system to achieve a dynamic balance between power consumption optimization and functional availability, hindering its ability to adapt to diverse user needs and usage environments.

[0039] Based on this, an extended mode is introduced between normal mode and shallow sleep mode to provide the device with orderly power-down preparation time, ensuring complete data transmission and smooth service shutdown. During the shallow sleep phase, a configurable wait timer is set and wake-up events are continuously monitored to dynamically adjust the sleep duration. Before entering deep sleep, the device synchronizes its state with the cloud platform and starts a synchronization timer. Through a dual mechanism of synchronization confirmation and timeout protection, real-time consistency between the vehicle-side and cloud states is ensured. This method solves the problem of data interruption and service anomalies caused by abrupt state transitions in existing technologies, avoids remote operation failures caused by cloud state misjudgments, and prevents system deadlocks caused by network anomalies through the timeout protection mechanism, thus improving user experience and system reliability.

[0040] In the following, embodiments of this application will be described in detail with reference to the accompanying drawings.

[0041] As attached Figures 1 to 5 As shown, in one illustrative embodiment of the vehicle control method, vehicle, and electronic device of this application, the vehicle control method includes the following steps S1-S3.

[0042] When the vehicle is detected to meet the preset sleep conditions, the telematics box switches from normal mode to extended mode, starts the extended timer, and monitors wake-up events during extended mode.

[0043] Preferably, as shown in the appendix Figure 2 As shown, in an illustrative embodiment of the vehicle control method of this application, the Telematics Box (T-BOX) includes a Microcontroller Unit (MCU), a State Manager, a Data Service Module, and a Scalable service-Oriented Middleware over IP (SOME / IP) module.

[0044] The aforementioned modules are interconnected via an internal bus and work together to realize the state transitions and control of the remote information processing box in extended mode. Specifically, the microcontroller unit is responsible for low-level hardware control and communication interface management, receiving vehicle status information such as CAN bus sleep signals from the Controller Area Network (CAN) bus; the state manager, as the core control module, is responsible for extended mode entry decisions, timer management, wake-up event monitoring, and state transition control; the data service module is responsible for uplink data transmission and management; and the service-oriented, scalable IP middleware service module is responsible for establishing and closing service communication with the in-vehicle electronic control unit.

[0045] Specifically, as shown in the attached document Figure 2 As shown, when the vehicle meets the preset sleep conditions, such as when the vehicle is turned off, the controller LAN bus sends a controller LAN bus sleep signal. The microcontroller unit of the telematics box receives the signal through the controller LAN bus and immediately sends a request to the status manager to enter the extended mode.

[0046] Preferably, the preset sleep condition is not limited to the controller area network bus sleep signal, but can also be other signals indicating that the vehicle has entered a non-operating state. For example, the microcontroller unit of the telematics box can detect the vehicle's ignition status through the ignition signal terminal. When the ignition signal changes from high level to low level and remains low for a preset duration, it determines that the vehicle has been turned off, thus satisfying the preset sleep condition. Alternatively, the telematics box can detect the activity status of the vehicle bus network. When no bus communication activity is detected within a preset time window, it determines that the vehicle has entered an idle state, thus satisfying the preset sleep condition. By setting multiple preset sleep conditions, this embodiment can adapt to different vehicle models and different user habits, improving the accuracy and flexibility of sleep triggering.

[0047] Upon receiving the extended mode command, the state manager first checks the current system state to confirm whether there are any wake-up conditions, such as ongoing services or pending data. If no conditions prevent hibernation, the state manager controls the remote information processing box to switch from normal mode to extended mode, simultaneously starting an extended timer and continuously monitoring wake-up events from multiple wake-up sources throughout the extended mode period.

[0048] Wake-up sources include, but are not limited to, controller area network bus wake-up, emergency call button wake-up, SMS wake-up, ringing wake-up, and remote information service provider command wake-up.

[0049] The aforementioned wake-up events can be categorized into two types based on their triggering source: local wake-up and remote wake-up.

[0050] Local wake-up events include the following categories: Controller Area Network (CAN) bus wake-up means that when other electronic control units in the vehicle initiate communication via the CAN bus, the telematics box is woken up to respond to in-vehicle service requests. Emergency call button wake-up means that when the user presses the emergency call button in the vehicle, the telematics box is immediately activated and an emergency communication link is established with the cloud platform. Timed wake-up refers to a periodic wake-up triggered by the internal real-time clock at a preset time point, used to perform timed tasks such as vehicle status reporting and remote diagnostics.

[0051] Remote wake-up events include the following categories: SMS wake-up means that the wireless communication module of the remote information processing box periodically checks whether a new SMS has arrived in power-saving mode, and triggers wake-up when it receives a wake-up SMS in a specific format; Ring wake-up means that the cloud platform or user terminal wakes up the device by making a phone call; remote information service provider command wake-up means that the cloud platform sends a special wake-up command through the mobile communication network.

[0052] By distinguishing the source and type of different wake-up events, the telematics box can execute differentiated processing procedures after wake-up. For example, after local wake-up, it can prioritize responding to in-vehicle service requests, and after remote wake-up, it can prioritize establishing a communication connection with the cloud platform.

[0053] Furthermore, the preset buffer duration of the extended timer can be dynamically adjusted according to vehicle configuration or usage scenario.

[0054] For example, when a vehicle leaves the factory, the default buffer duration of the extended timer can be set to 3 minutes. This duration is based on a large amount of experimental data and can ensure the completion of most uplink data transmission and service shutdown operations, while avoiding user experience delays caused by excessively long buffers.

[0055] The cloud platform of the telematics service provider can remotely adjust the buffer duration based on the actual usage of the vehicle.

[0056] For example, when the cloud platform detects frequent large-scale data uploads by a vehicle, it can issue a command to extend the extended timer duration to 5 minutes to ensure complete data transmission. When the vehicle is in a scenario where low-power consumption is prioritized, the duration can be shortened to 1 minute to accelerate the sleep process. The remote information processing box immediately updates the preset duration of the extended timer after receiving the configuration command, without requiring a device restart. Through this dynamic adjustment mechanism, the extended mode can better adapt to data upload needs and service shutdown time requirements in different scenarios, further optimizing the balance between user experience and power consumption.

[0057] In some embodiments, in extended mode, the telematics box performs uplink data transmission and performs a shutdown operation on the service-oriented scalable IP middleware service.

[0058] Preferably, in extended mode, the state manager triggers the data upload guarantee and service-oriented scalable IP middleware service processing flow in parallel.

[0059] Specifically, the status manager notifies the data service module to start uplink data transmission, ensuring that all data to be uploaded is completely transmitted to the remote information service provider's cloud platform, and returns a data upload completion signal to the status manager after the transmission is completed.

[0060] Simultaneously, the state manager notifies the service-oriented scalable IP middleware service module to perform a graceful shutdown operation, ensuring that ongoing service requests can terminate normally and avoiding connection anomalies caused by sudden service interruptions. After the service shutdown is complete, it returns a service processing completion signal to the state manager. The above operations are executed in parallel with wake-up monitoring, without interference. The state manager continuously tracks the completion progress of each operation, providing a basis for subsequent determination of whether to enter shallow sleep mode after the extended timer times out.

[0061] S1: When the vehicle is detected to meet the preset sleep conditions, the telematics box switches from normal mode to shallow sleep mode, starts the shallow sleep timer, and monitors wake-up events during the shallow sleep mode.

[0062] In some embodiments, in extended mode, if the extended timer times out and no wake-up event is detected, the telematics box enters a shallow sleep mode, including: During the extended timer's operation, the telematics box continuously monitors wake-up events; If a wake-up event is detected, immediately revert to normal mode; If the extended timer times out and no wake-up event is detected, the remote information processing box enters a shallow sleep mode.

[0063] Preferably, as shown in the appendix Figure 2 As shown, during the operation of the extended timer, the state manager continuously monitors wake-up events from multiple wake-up sources.

[0064] If a valid wake-up event is detected before the extended timer expires, such as Controller Area Network bus wake-up, emergency call button wake-up, SMS wake-up, ringing wake-up, or remote information service provider command wake-up, the state manager immediately controls the remote information processing box to fall back to normal mode, interrupting the hibernation process, in order to quickly respond to user operations or external requests and ensure the continuity of user experience.

[0065] If the extended timer times out and no wake-up event is detected during the entire buffer period, the state manager determines that the data upload and service shutdown operations have been completed and controls the remote information processing box to enter a shallow sleep mode.

[0066] After entering shallow sleep mode, the remote information processing box shuts down non-core function modules, retains only the wake-up detection circuit, starts the shallow sleep timer, and continuously monitors wake-up events during shallow sleep mode.

[0067] In some embodiments, the pre-configured duration of the shallow sleep timer is remotely configured by the cloud platform of the remote information service provider and sent to the remote information processing box via configuration management instructions. After receiving the configuration management instructions, the remote information processing box immediately updates the pre-configured duration without restarting the device.

[0068] Preferably, as shown in the appendix Figure 3 As shown, the pre-configured duration of the shallow sleep timer is remotely configured by the telematics service provider's cloud platform. The cloud platform generates configuration management commands based on different vehicle usage modes and distributes them to the telematics box via the mobile communication network. Examples of usage modes include daily commuting, long-distance transportation, and showroom displays.

[0069] Specifically, configuration management commands use a standardized message format to ensure reliable transmission and parsing of commands.

[0070] For example, a command message may include the following fields: The message header contains information such as the protocol version, message type, and message length; the device identifier can be a vehicle identification number or a unique identifier for a telematics box. The parameter identifier indicates the type of parameter configured this time, such as the duration of the shallow sleep timer; the parameter value represents the numerical value of the new duration, in hours or days. Effective Time is an optional field used to specify the exact time when the instruction takes effect. If this field is empty, the instruction takes effect immediately. Digital signatures are used to verify the legitimacy and integrity of the source of instructions.

[0071] After receiving the instruction, the wireless communication module of the remote information processing box first verifies the digital signature to confirm that the instruction comes from a trusted cloud platform, and then forwards the instruction to the status manager.

[0072] The status manager parses the parameter identifier and parameter value, writes the new pre-configured duration into the configuration parameter area in the memory, and returns an acknowledgment message to the cloud platform. The acknowledgment message includes the device identifier, parameter identifier, processing result, and the currently effective duration value. The processing result can indicate success or failure.

[0073] If a command is lost or fails to receive confirmation due to communication anomalies, the cloud platform can employ a retransmission strategy, such as retransmitting it every hour, up to a maximum of three times, or waiting for the device to wake up again to resend the command. This standardized command interaction process ensures the reliability and security of remote configuration.

[0074] Furthermore, the shallow sleep timer has a default pre-configured duration, such as 7 days. This default duration is preset at the vehicle's factory or serves as a baseline value in the absence of specific configuration instructions.

[0075] Furthermore, in practical applications, the pre-configured duration of the shallow sleep timer can be dynamically adjusted within a wide range according to vehicle usage scenarios and user needs.

[0076] For example, in daily commuting scenarios, vehicles are typically used every day, so the shallow sleep duration can be set to 1 to 3 days to ensure normal use the next day while entering deep sleep as soon as possible to reduce power consumption. In long-distance transportation or long-term parking at airports, vehicles may not be used for weeks or even months, so the shallow sleep duration can be extended to 15 days, 30 days or even longer to keep the device responsive to remote query and control commands for a longer period of time.

[0077] The cloud platform can dynamically adjust the pre-configured duration based on vehicle usage history, user calendar information, or the vehicle's current location. For example, when it detects that a vehicle has not been used for several consecutive days, the cloud platform can automatically extend the shallow sleep duration; when it detects that a vehicle has entered transport mode, the cloud platform can set the shallow sleep duration to an extremely short value, allowing the device to quickly enter deep sleep to maximize power saving. Through this dynamically adjustable pre-configured duration setting, a fine balance between power consumption optimization and functional availability is achieved.

[0078] After receiving configuration management commands, the remote information processing box immediately updates the pre-configured duration of local storage, making the new parameters effective without restarting the device. Through this remote configuration mechanism, the hibernation strategy can flexibly adapt to diverse usage scenarios, achieving a dynamic balance between power consumption optimization and functional availability.

[0079] In some embodiments, in shallow sleep mode, if a wake-up event is detected, the telematics box resets the shallow sleep timer and restarts the timing.

[0080] Preferably, in shallow sleep mode, the state manager continuously monitors wake-up events. If a valid wake-up event is detected during the shallow sleep timer's operation, the state manager immediately controls the telematics box to reset the shallow sleep timer, restarting it and restoring it to normal mode to respond to wake-up requests. If the shallow sleep timer times out and no wake-up event is detected, a subsequent deep sleep state synchronization process is triggered. This wake-up reset mechanism ensures that the device remains responsive when there is continuous demand, avoiding forced entry into deep sleep due to a single timeout, further improving user experience and system flexibility.

[0081] Specifically, when the state manager detects a wake-up event, it first determines the type and priority of the event. For high-priority events such as emergency call button wake-up, the state manager immediately aborts the shallow sleep process, controls the remote information processing box to return to normal mode, resets the shallow sleep timer to zero, and starts the service processing flow in normal mode. For low-priority events such as timed wake-up, the state manager can decide whether to respond immediately or with a delay based on factors such as the current system load and remaining battery power.

[0082] For example, when the remaining battery power is low, the state manager can ignore some non-critical timed wake-ups and continue to maintain a shallow sleep state to save power. After resetting the shallow sleep timer, the timer restarts from zero, and the device continues to monitor wake-up events in shallow sleep mode until the next timer expires or is interrupted by a wake-up event. This wake-up reset mechanism avoids the device being forced into deep sleep due to a single timer expiration, effectively balancing power consumption optimization and service response requirements.

[0083] S2: In shallow sleep mode, if the shallow sleep timer times out and no wake-up event is detected, the remote information processing box synchronizes its execution status with the cloud platform of the remote information service provider and starts a synchronization timer.

[0084] Preferably, when the shallow sleep timer reaches the pre-configured duration and no wake-up event is detected during the entire shallow sleep period, the telematics box enters the deep sleep preparation phase.

[0085] As attached Figure 4 As shown, the state manager first activates the communication module to establish a communication link with the cloud platform of the remote information service provider, then starts the synchronization timer and performs state synchronization with the cloud platform.

[0086] In some embodiments, as shown in the appendix Figure 4 As shown, the synchronization of the remote information processing box and the cloud platform of the remote information service provider includes: The remote information processing box sends a deep hibernation notification to the cloud platform of the remote information service provider. The deep hibernation notification carries the logout reason code and status code to inform the cloud platform of the remote information service provider that the remote information processing box is about to enter a deep hibernation state that does not support remote control. The remote information processing box receives a confirmation response from the cloud platform of the remote information service provider.

[0087] Preferably, before sending the deep sleep notification, the telematics box may optionally send a login report to the cloud platform, carrying a wake-up reason code, so that the cloud platform can record the source of the device's wake-up. For example, a wake-up reason code of 0x08 indicates that the device was woken up by a real-time clock.

[0088] Furthermore, in the deep sleep notification sent by the telematics box, the logout reason code is used to identify the specific reason for triggering deep sleep. For example, the logout reason code can be set to 0x06 to indicate that this deep sleep was triggered by the controller area network bus sleep signal; the logout reason code can also be set to other values ​​to correspond to different triggering scenarios, such as 0x05 indicating that it is triggered after the emergency call function is completed, 0x07 indicating that it is triggered by the vehicle being idle for a long time, etc.

[0089] In the deep sleep notification sent by the remote information processing box, the status code is used to identify the target state that the device is about to enter. For example, it can be set to 0x02 to indicate that the device is about to enter deep sleep mode. The status code can also be set to other values ​​to correspond to different low power states, such as 0x01 to enter shallow sleep mode, 0x03 to enter standby mode, etc.

[0090] By combining the logout reason code and status code, the cloud platform can accurately identify the triggering reason and target status of device status changes, thereby achieving precise management and recording of device status and providing accurate device status prompts to user terminals.

[0091] Furthermore, the remote information processing box receives an acknowledgment response from the remote information service provider's cloud platform. This acknowledgment response indicates that the cloud platform has successfully received and processed the deep sleep notification and has updated the device status to a deep sleep state that does not support remote control.

[0092] The confirmation response may include processing result information from the cloud platform, such as a synchronization success indicator, timestamp, or subsequent instructions. After receiving the confirmation response, the remote information processing box acknowledges that the synchronization is complete and prepares to enter deep sleep mode.

[0093] In some embodiments, in response to receiving a deep sleep notification, the cloud platform of the remote information service provider sets a remote control unsupported flag to prohibit the user terminal from sending remote control commands to the remote information processing box.

[0094] Specifically, the following mechanisms are not supported for setting and storing remote control identifiers: After receiving a deep sleep notification and parsing the logout reason code and status code, the cloud platform first searches for the corresponding remote information processing box's device record in the device status database. It then updates the remote control status field in that record to "uncontrollable" and records the timestamp of the status change and the logout reason code. This status field represents the specific implementation of the "remote control not supported" flag. By recording the logout reason code, the cloud platform can accurately identify the triggering reason for the device entering deep sleep, such as being triggered by controller area network bus sleep, being triggered after the emergency call function is completed, or being triggered by the vehicle being stationary for an extended period.

[0095] Preferably, after the cloud platform is set to not support remote control, when the user terminal queries the vehicle status or attempts to issue a remote control command through a mobile application or web page, the service gateway of the cloud platform first queries the device status database. If an uncontrollable flag is detected, the request processing process is immediately terminated, and a response message containing status prompt information is returned to the user terminal.

[0096] The prompts in the response message can be customized based on the logout reason code. For example, when the controller LAN bus enters deep sleep mode, the message "The vehicle entered deep sleep mode at a certain time on a certain day. Remote control is not supported at the moment. Reason: The vehicle has been idle for a long time after being turned off" can be returned. When deep sleep mode is triggered after the emergency call function is completed, the message "Emergency call mode has ended and the vehicle has entered power saving mode" can be returned, thereby improving the user's perception and understanding of the device status.

[0097] Furthermore, the cloud platform maintains an identifier validity period management mechanism. Since the remote information processing box can be woken up and re-entered at any time, remote control identifiers are not permanently valid.

[0098] The cloud platform starts an active timer when setting this identifier. The timer duration is associated with the pre-configured duration of the shallow sleep timer, for example, it is set to 1.2 times the pre-configured duration.

[0099] If no heartbeat information or status report is received from the remote information processing box within the validity period, the identifier will remain in effect; if no device information is received after the validity period expires, the cloud platform may proactively initiate a device status query attempt to wake up the device via out-of-band methods such as SMS or telephone to confirm its actual status.

[0100] Once the remote information processing box is subsequently woken up and successfully sends a login report, the cloud platform, based on the wake-up reason code and device identifier in the login report, re-queries and updates the device record in the device status database, clears the "remote control not supported" identifier, restores the remote control function, and records the wake-up time and reason. Through this dynamic identifier management mechanism, the cloud platform can promptly restore the remote control function after the device is woken up, ensuring the continuity of user experience.

[0101] Furthermore, the cloud platform provides vehicle owner accounts with a status history query function. Users can view the device status change records over a recent period, including the time of entering deep sleep, the wake-up time, and the reason codes for each status change. This helps users understand the vehicle's sleep and wake-up patterns and better comprehend changes in the availability of remote control functions. Through the aforementioned multi-layered remote control-unsupported identifier management mechanism, this application achieves precise control of device status by the cloud platform and user-friendly interaction, significantly improving the reliability of vehicle-cloud collaboration and user experience.

[0102] S3: If the state synchronization is completed before the synchronization timer expires, or if the synchronization timer expires, the remote information processing box enters deep sleep mode.

[0103] In some embodiments, as shown in the appendix Figure 4 As shown, based on the execution result of state synchronization, the remote information processing box enters deep sleep mode through two different paths.

[0104] If the state synchronization is completed before the synchronization timer expires, the remote information processing box immediately enters deep sleep mode.

[0105] Preferably, in this scenario, the remote information processing box performs normal deep sleep operations, including shutting down the communication module, disconnecting the backup battery power supply, retaining only necessary wake-up sources, such as the KL15 ignition signal and controller area network bus wake-up, and waiting for the next wake-up in a state of minimum power consumption. At this time, since the cloud platform has already returned a confirmation response and set the remote control not supported flag during the synchronization process, the vehicle and cloud states are already consistent in real time, requiring no additional notification.

[0106] If the synchronization timer times out, the remote information processing box will be forced into deep sleep mode and the remote information service provider's cloud platform will be notified.

[0107] Preferably, in this scenario, the remote information processing box performs the same deep sleep operation as the normal process, such as shutting down the communication module, disconnecting the backup battery power supply, and retaining the necessary wake-up source. Simultaneously, after entering deep sleep or at a later appropriate time, it re-attempts to send a status update notification to the cloud platform to ensure that the cloud platform can eventually learn the actual status of the device. This forced entry mechanism is used to cope with situations such as network latency, packet loss, or cloud processing anomalies, ensuring that the device does not remain unable to enter deep sleep for extended periods while waiting for confirmation responses, thereby avoiding unnecessary power consumption.

[0108] Furthermore, after being forced into deep sleep mode, the telematics box records the identifier of the current state synchronization failure and, upon the next wake-up, prioritizes sending a state synchronization request to the cloud platform to update the device status. Upon receiving this request, the cloud platform updates the device status to deep sleep and sets a remote control-unsupported identifier based on the logout reason code and status code reported by the telematics box, thereby ensuring the eventual consistency between the vehicle-side and cloud-side status.

[0109] Specifically, during the timeout determination process of the synchronization timer, the status manager of the remote information processing box monitors the running status of the synchronization timer in real time and records the specific time point of the timeout, as well as the current network signal strength, communication module status, and other information, as the basis for subsequent diagnostic analysis.

[0110] When the synchronization timer times out, the state manager immediately terminates the state of waiting for confirmation response and enters the execution process of forcibly entering deep sleep mode.

[0111] Before forcing a deep sleep, the state manager encapsulates the current deep sleep notification content to be sent and the unreceived acknowledgment response information into a synchronization packet, stores it in a specific area of ​​non-volatile memory, and sets the synchronization flag. This synchronization packet includes at least the original content of the deep sleep notification, a sending timestamp, a timeout timestamp, and a retry counter.

[0112] When the remote information processing box subsequently returns to normal mode due to any wake-up event, the state manager first checks the synchronization flag. If there are any incomplete synchronization tasks, the state synchronization retry process is immediately initiated.

[0113] During the retry process, the state manager reads the stored data packets to be synchronized, resends the deep sleep notification to the cloud platform, and starts a new synchronization timer. The timeout duration of this timer can be dynamically adjusted based on the experience value of the previous timeout, for example, it can be set to 1.5 times the previous timeout duration but not exceeding the preset maximum value.

[0114] If a successful retry receives an acknowledgment response, the state manager clears the synchronization flag and the synchronization data packet, completing state synchronization. If the retry times out again, the retry count counter is incremented, and the synchronization data packet is restored, waiting for the next wake-up to retry again, until the number of retries reaches the preset limit.

[0115] When the maximum number of retries is reached, the state manager abandons the synchronization attempt, but records the synchronization failure event in a permanent log for querying during maintenance and diagnosis.

[0116] Furthermore, the cloud platform can proactively detect abnormal device states, such as prolonged periods without heartbeat information or status reports. The cloud platform can query historical synchronization records based on the device identifier. If an unconfirmed deep sleep notification is found, the platform proactively updates the device state to deep sleep and records the abnormal synchronization event, thus achieving eventual consistency of state from the cloud side. Through these multi-layered timeout handling and retry mechanisms, this application can maximize the consistency of state between the vehicle and the cloud when dealing with complex network environments and cloud-based processing anomalies, while avoiding resource waste caused by endless retries.

[0117] Furthermore, regardless of whether it enters deep sleep mode through normal or forced procedures, the remote information processing box maintains minimal power consumption in deep sleep mode, retaining only the necessary wake-up detection capabilities.

[0118] Specifically, in deep sleep mode, the microcontroller unit of the remote information processing box enters stop mode or standby mode, the clock frequency is reduced to the minimum or completely turned off, and only the external interrupt wake-up function is retained; The communication module is completely powered off, and its power supply circuit is cut off by the power management module to achieve static power consumption at the microampere level. The backup battery management circuit enters a high-impedance state, maintaining only basic power monitoring functions; The wake-up detection circuit uses a low-power monitoring unit independent of the main power supply to continuously monitor wake-up sources such as KL15 ignition signal, CAN bus activity, and emergency call button input.

[0119] When any wake-up source is activated, the monitoring unit generates an interrupt signal, triggering the microcontroller unit to exit stop mode, reactivate the main power supply, and power the communication module, restoring the device to normal mode. This refined power management design minimizes static power consumption in deep sleep mode while ensuring necessary wake-up capabilities, significantly extending the vehicle's battery life.

[0120] When a valid wake-up event is detected, such as a KL15 ignition signal, CAN bus wake-up, or emergency call button wake-up, the remote information processing box recovers from deep sleep mode to normal mode, reactivates the communication module, and establishes a connection with the cloud platform. After reconnection, the remote information processing box sends a login report to the cloud platform, carrying a wake-up reason code. The cloud platform responds to this login report by clearing the "remote control not supported" flag and restoring remote control functionality, thus ensuring a continuous user experience. Through this mechanism, reliable entry and flexible wake-up from deep sleep mode are achieved, effectively balancing power consumption optimization and functional availability.

[0121] The second aspect is a vehicle, including a controller for implementing the vehicle control method described above.

[0122] In one embodiment of this application, the telematics box includes a microcontroller unit, an application processor, a memory, a wireless communication module, a controller area network transceiver, a global navigation satellite system receiver, a power management module, and a backup battery. All of these modules are interconnected via an internal bus.

[0123] The microcontroller unit is responsible for low-level hardware control and tasks with high real-time requirements, including wake-up event monitoring, timer management, and power state switching.

[0124] The application processor is responsible for handling upper-layer application protocols, including service-oriented scalable IP middleware protocols, remote control command parsing, and data upload encapsulation.

[0125] The memory includes random access memory and non-volatile memory, used to store program code, configuration parameters and runtime data, where the configuration parameters include the pre-configured duration of the shallow sleep timer.

[0126] The wireless communication module supports 4G or 5G mobile communication networks for data interaction with the cloud platform of remote information service providers.

[0127] The controller area network transceiver connects to the vehicle's controller area network bus to enable communication with the vehicle's electronic control units.

[0128] Global Navigation Satellite System (GNSS) receivers are used to acquire vehicle location information.

[0129] The power management module receives power from the vehicle's main power supply and backup battery, provides stable operating voltage to each functional module according to the control instructions of the microcontroller unit, and cuts off power to non-essential modules in deep sleep mode.

[0130] One embodiment of the vehicle in this application includes a telematics box, multiple electronic control units, a controller area network bus, and a vehicle power system.

[0131] The remote information processing box connects to each electronic control unit via the controller area network bus to realize in-vehicle data acquisition and control command issuance. Each electronic control unit includes the body control module, engine control module, and entertainment system control module.

[0132] The telematics box also connects to the cloud platform of a telematics service provider via a mobile communication network to enable vehicle-to-cloud data interaction.

[0133] The vehicle power system provides operating power to the telematics box and various electronic control units, and is continuously powered by the battery after the vehicle is turned off.

[0134] The power management module of the telematics box controls the telematics box to switch between normal mode, extended mode, shallow sleep mode and deep sleep mode according to the vehicle control method described in the above embodiments of this application, so as to minimize the power consumption of the whole vehicle while ensuring the availability of functions.

[0135] Combination Figure 5 As shown, this embodiment discloses a specific implementation of a computer device. The computer device may include a processor 41 and a memory 42 storing computer program instructions.

[0136] Specifically, the processor 41 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0137] The memory 42 may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory 42 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 42 may include removable or non-removable (or fixed) media. Where appropriate, the memory 42 may be internal or external to the data processing device. In a particular embodiment, the memory 42 is non-volatile. Volatile memory. In a particular embodiment, memory 42 includes read-only memory. ROM (ROM-only memory) and RAM (Random Access Memory). Where appropriate, the ROM can be a mask-programmed ROM or a programmable ROM. Only Memory (PROM) and Erasable Programmable Read-Only Memory (EPRROM) The RAM can be a type of RAM, such as EPROM (Electrically Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), EAROM (Electrically Alterable Read-Only Memory), or FLASH (Flash Memory), or a combination of two or more of these. Where appropriate, the RAM can be a Static Random Access Memory (SRAM). Access Memory (SRAM) or Dynamic Random Access Memory (DRAM) can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0138] The memory 42 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 41.

[0139] The processor 41 implements the vehicle control method in the above embodiments by reading and executing computer program instructions stored in the memory 42.

[0140] In some embodiments, the computer device may further include a communication interface 43 and a bus 40. For example, Figure 5 As shown, the processor 41, memory 42, and communication interface 43 are connected through bus 40 and complete communication with each other.

[0141] Communication interface 43 is used to enable communication between modules, devices, units and / or equipment in the embodiments of this application.

[0142] Communication port 43 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0143] Bus 40 includes hardware, software, or both, that couples components of a computer device together. Bus 40 includes, but is not limited to, at least one of the following: a data bus, an address bus, a control bus, an expansion bus, and a local bus. For example, and not as a limitation, bus 40 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, and a PCI bus. Express (PCI The bus may be an X-bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 40 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0144] Furthermore, in conjunction with the vehicle control methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle control methods in the above embodiments.

[0145] The present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described vehicle control method.

[0146] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described vehicle control method.

[0147] Although embodiments of the invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the invention.

Claims

1. A vehicle control method, characterized in that, It includes: When the vehicle is detected to meet the preset sleep conditions, the telematics box switches from normal mode to shallow sleep mode, starts the shallow sleep timer, and monitors wake-up events during the shallow sleep mode. In the shallow sleep mode, if the shallow sleep timer times out and no wake-up event is detected, the remote information processing box synchronizes its execution status with the remote information service provider's cloud platform and starts a synchronization timer. If the state synchronization is completed before the synchronization timer expires, or if the synchronization timer expires, the remote information processing box enters deep sleep mode.

2. The vehicle control method according to claim 1, characterized in that, Before switching from normal mode to shallow hibernation mode, the following is also included: When the vehicle is detected to meet the preset sleep conditions, the remote information processing box switches from normal mode to extended mode, starts the extended timer, and monitors wake-up events during the extended mode. In the extended mode, if the extended timer times out and no wake-up event is detected, the system enters the shallow sleep mode. In the extended mode, the remote information processing box performs uplink data transmission and shuts down the service-oriented scalable IP middleware service.

3. The vehicle control method according to claim 2, characterized in that, In the extended mode, if the extended timer times out and no wake-up event is detected, the remote information processing box enters a shallow sleep mode, including: During the operation of the extended timer, the telematics box continuously monitors wake-up events; If a wake-up event is detected, immediately revert to the normal mode; If the extended timer times out and no wake-up event is detected, the remote information processing box enters the shallow sleep mode.

4. The vehicle control method according to claim 1, characterized in that, The pre-configured duration of the shallow sleep timer is remotely configured by the cloud platform of the remote information service provider and sent to the remote information processing box through configuration management instructions. After receiving the configuration management instructions, the remote information processing box immediately updates the pre-configured duration without restarting the device.

5. The vehicle control method according to claim 1 or 4, characterized in that, In the shallow sleep mode, if a wake-up event is detected, the remote information processing box resets the shallow sleep timer and restarts the timing.

6. The vehicle control method according to claim 1, characterized in that, The synchronization of the execution status between the remote information processing box and the cloud platform of the remote information service provider includes: The remote information processing box sends a deep hibernation notification to the cloud platform of the remote information service provider. The deep hibernation notification carries a logout reason code and a status code to inform the cloud platform of the remote information service provider that the remote information processing box is about to enter a deep hibernation state that does not support remote control. The remote information processing box receives a confirmation response from the cloud platform of the remote information service provider.

7. The vehicle control method according to claim 6, characterized in that, Upon receiving the deep hibernation notification, the cloud platform of the remote information service provider sets a remote control-unsupported flag to prohibit the user terminal from sending remote control commands to the remote information processing box.

8. The vehicle control method according to claim 1, characterized in that, If the state synchronization is completed before the synchronization timer expires, or if the synchronization timer expires, the remote information processing box enters deep sleep mode, including: If the state synchronization is completed before the synchronization timer expires, the remote information processing box immediately enters deep sleep mode; If the synchronization timer times out, the remote information processing box is forced into deep sleep mode and the remote information service provider's cloud platform is notified.

9. A vehicle, characterized in that, Includes a controller for implementing the vehicle control method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the vehicle control method as described in any one of claims 1 to 8.

Images