Vehicle-mounted remote communication terminal T-Box state switching method and device, vehicle, storage medium and product

Abstract

The embodiment of the invention provides a vehicle-mounted remote communication terminal T-Box state switching method and device, a vehicle, a storage medium and a product. The T-Box comprises an MPU and an MCU, and the method comprises the following steps: when the MPU is in a wake-up state and receives a sleep signal, monitoring first communication data of the MCU through the MPU, judging whether a state jump condition is met or not, when the state jump condition is met, controlling the T-Box to be switched to a sleep condition judgment state, monitoring second communication data of the MCU through the MPU, and switching the first communication data to the sleep condition judgment state based on the second communication data. And judging whether a dormancy condition is met or not, controlling the T-Box to be switched to a dormancy preparation state under the condition that the dormancy condition is met, and controlling the T-Box to be switched to the dormancy state after the dormancy preparation operation is completed through the MPU. According to the method provided by the invention, the risk of unstable T-Box state switching can be reduced.

Description

Technical Field

[0001] This application belongs to the field of vehicle-mounted communication technology, and in particular relates to a method, device, vehicle, storage medium and product for switching the status of a vehicle-mounted remote communication terminal T-Box. Background Technology

[0002] As a core connected component of intelligent connected vehicles, the in-vehicle telematics box (T-Box) is responsible for data exchange, remote control, and status monitoring between the vehicle and the cloud service platform. Such systems typically employ a dual-core architecture consisting of a microprocessor unit (MPU) and a microcontroller unit (MCU). The MPU handles high-performance computing and complex communication tasks, while the MCU provides real-time control and low-power monitoring.

[0003] In existing technologies, power management of such T-Boxes often adopts a simplified state machine model, which typically includes only three basic operating states: running, suspended, and powered off.

[0004] However, existing technologies are prone to unstable state transitions. Summary of the Invention

[0005] This application provides a method, device, vehicle, storage medium, and product for switching the state of a vehicle-mounted remote communication terminal T-Box, which can reduce the risk of unstable T-Box state switching.

[0006] In a first aspect, embodiments of this application provide a method for switching the state of a vehicle-mounted remote communication terminal T-Box. The vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU). The method includes: When the MPU is in wake-up state and receives a sleep signal, the first communication data of the MCU is monitored through the MPU; Based on the first communication data, determine whether the state transition condition is met; When the state transition conditions are met, control the T-Box to switch to the sleep condition judgment state and monitor the second communication data of the MCU through the MPU; Based on the second communication data, determine whether the sleep conditions are met; When the hibernation conditions are met, control the T-Box to switch to hibernation preparation mode and perform hibernation preparation operation through the MPU; Once the hibernation preparation operation is complete, control the T-Box to switch to hibernation mode.

[0007] In one feasible implementation, the method further includes: Monitor the operating status of the MCU; If the operating status is detected as an emergency, switch the current operating status of the T-Box to emergency response status; Continuously monitor the operating status of the MCU; If the system detects that the operating status has exited the emergency state, the current operating status of the T-Box will be exited the emergency response state.

[0008] In one feasible implementation, The T-Box is equipped with hardware monitoring devices; after controlling the T-Box to switch to sleep mode, the method also includes: Utilize hardware monitoring devices to monitor wake-up sources; If the wake-up source is detected to be a non-control type wake-up source of the vehicle control platform, the control T-Box switches the MPU in the control T-Box to the MPU-only wake-up state; If the wake-up source is detected to be a wake-up source other than the non-control wake-up source of the vehicle control platform, the T-Box will be woken up.

[0009] In one feasible implementation, waking up the T-Box includes at least any one of the following: Wake up the MPU and set a software lock to prevent the MPU from sleeping; Wake up the MCU; Send exit sleep notifications to each functional module and sensor; Send an exit hibernation notification to the cloud to synchronize the cloud with the T-Box.

[0010] In one feasible implementation, when the wake-up source is detected to be a wake-up source other than a non-control type wake-up source of the vehicle control platform, the method further includes: If the MCU continuously monitors the serial peripheral interface SPI between the MPU and the MCU and fails within a first preset time period, the MCU will control the MPU to power off. If the power outage lasts for a period of time up to the second duration, the power supply to the MPU is restored via the MCU.

[0011] In one feasible implementation, when the hibernation conditions are met, the T-Box is controlled to switch to a hibernation preparation state, and the MPU performs a hibernation preparation operation, including: The MPU sends sleep requests to each functional module and sensor; Disable the Controller Area Network (CAN) network startup flag; Set the RTC time of the heartbeat packet of the hardware monitoring device according to the IoT connection status and send it to the base station; The MPU sends a sleep confirmation signal to the MCU; The MPU sends a sleep request to the SPI; Release the pin that wakes up the MCU.

[0012] In one feasible implementation, before controlling the T-Box to switch to sleep mode, the method further includes: Record the status of the T-Box's functional modules to enable a response when a wake-up source is detected by the hardware monitoring device.

[0013] In one feasible implementation, the method further includes: If the conditions for the MTS mode of the module test system are met and the system is not in sleep mode, control the T-Box to switch to sleep mode under MTS mode.

[0014] Secondly, embodiments of this application provide a vehicle-mounted remote communication terminal T-Box state switching device. The vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU). The device includes: When the MPU is in wake-up state and receives a sleep signal, the first communication data of the MCU is monitored through the MPU; The first monitoring module is used to monitor the first communication data of the MCU through the MPU when the MPU is in a wake-up state and receives a sleep signal; The first judgment module is used to determine whether the state transition condition is met based on the first communication data. The second monitoring module is used to control the T-Box to switch to the sleep condition judgment state when the state transition conditions are met, and to monitor the second communication data of the MCU through the MPU; The second judgment module is used to determine whether the sleep conditions are met based on the second communication data; The hibernation preparation module is used to control the T-Box to switch to the hibernation preparation state when the hibernation conditions are met, and to perform the hibernation preparation operation through the MPU; The hibernation module is used to control the T-Box to switch to hibernation mode after the hibernation preparation operation is completed.

[0015] Thirdly, this application provides a vehicle for switching vehicle status, the vehicle including: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement any one of the vehicle-mounted remote communication terminal T-Box status switching methods.

[0016] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, wherein any one of the computer program instructions is executed by a processor to implement a method for switching the state of a vehicle-mounted remote communication terminal T-Box.

[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any of the vehicle system state switching methods described in the above embodiments.

[0018] The vehicle-mounted remote communication terminal T-Box state switching method, apparatus, vehicle, storage medium, and product of this application embodiment, after the T-Box receives a sleep signal, the MPU monitors the MCU. After detecting the first communication data of the MCU that meets the state transition condition, it then monitors the second communication data of the MCU that meets the sleep condition. The MPU then initiates a pre-sleep preparation operation, and after the preparation operation is completed, the T-Box switches to the sleep state. That is, in this application embodiment, after the T-Box receives the sleep signal, it does not immediately switch to the sleep state. Instead, the MPU monitors the data information of the MCU and judges whether the state transition condition and the sleep condition are met. Only when both are met is the switch performed. Furthermore, a preparation operation is performed before the sleep operation to ensure that the sleep state is not affected before switching to the sleep state. Therefore, this application improves the stability of T-Box state switching by increasing the decision point and having the MPU monitor the MCU, ensuring dual-core collaboration between the MPU and the MCU, and managing peripherals in an orderly manner. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a method for switching the state of a vehicle-mounted remote communication terminal T-Box provided in an embodiment of this application; Figure 2 This is provided by the embodiments of this application. Figure 1 A schematic diagram illustrating the specific steps of S150 in the diagram; Figure 3 This is a flowchart illustrating an emergency state switching method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a process for performing wake-up based on wake-up source type, provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle-mounted remote communication terminal T-Box state switching device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0021] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0022] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0023] As the background technology indicates, the in-vehicle telematics box (T-Box), as a core connected component of intelligent connected vehicles, undertakes key functions such as data exchange, remote control, and status monitoring between the vehicle and the cloud service platform. The T-Box typically integrates multiple communication interfaces such as 4G / 5G, C-V2X, GNSS, and BLE, and adopts a dual-core architecture including a microprocessor unit (MPU) and a microcontroller unit (MCU). The MPU is responsible for high-performance computing and complex communication tasks, while the MCU focuses on real-time control and low-power monitoring, jointly enabling remote monitoring after the vehicle is turned off, emergency data reporting, and extremely low-power operation during long-term parking.

[0024] Currently, common T-Box power management often employs a simplified state machine model, typically setting only three basic operating modes: RUN, SUSPEND, and OFF, and triggering state transitions through a limited number of wake-up sources. In this approach, the MPU and MCU usually operate or sleep synchronously, lacking intermediate states and fine-grained power consumption hierarchical control mechanisms, and peripheral management often adopts a simultaneous power-on / power-off approach.

[0025] In summary, existing technologies have several technical problems in practical applications: First, power consumption management is poor, resulting in high static power consumption when vehicles are parked for extended periods, which can easily lead to battery depletion. Second, system coordination is insufficient, with a lack of synchronization mechanisms between the MPU and MCU states, chaotic peripheral management, and inadequate anomaly recovery mechanisms. Third, user experience is limited, manifested in issues such as untimely vehicle status updates and slow system response in emergency situations.

[0026] To address the problems in the prior art, this application provides a method, apparatus, vehicle, storage medium, and product for switching the state of a vehicle-mounted remote communication terminal T-Box.

[0027] To address the problems caused by direct switching in existing technologies, the solution provided in this application adds more granular state steps during the wake-up to sleep process of the T-Box system. For example, by adding more decision points and judgment conditions as thresholds for continued operation, the MPU or MCU is prevented from directly entering sleep mode. Simultaneously, to ensure the stability of state switching, pre-sleep operation steps and multiple checks on the wake-up source can be added to the added state steps, enabling the system to enter sleep mode gradually and systematically. The following section first introduces the T-Box state switching method for the vehicle-mounted remote communication terminal provided in this application.

[0028] Figure 1 A flowchart illustrating a method for switching the state of a vehicle-mounted remote communication terminal T-Box according to an embodiment of this application is shown. Figure 1 As shown, this method can be applied to the vehicle controller or executed by the T-Box. The vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU). The method may include the following steps S110-S160: S110, when the T-Box is in a wake-up state and receives a sleep signal, monitors the first communication data of the MCU through the MPU.

[0029] As an example, when the T-Box is in a wake-up state and receives a sleep signal, the MPU monitors the MCU's first communication data. This first communication data may include the MCU's current operating status flag, whether a sleep preparation request has been issued, and the communication link status, etc., which are used to determine whether the conditions for jumping from the normal operating state to the sleep preparation state are met.

[0030] In this way, when the T-Box receives a sleep signal, it does not directly enter sleep mode. Instead, it enables the MPU to actively monitor the first communication data of the MCU while in wake-up mode, achieving real-time synchronization and mutual verification of the dual-core states. This effectively avoids sleep transition conflicts or system hang anomalies caused by inconsistencies between the MPU and MCU states. At the same time, this monitoring mechanism can identify communication anomalies early before entering the sleep process, thereby improving the reliability and robustness of the system during state switching and providing accurate state basis for subsequent refined sleep decisions.

[0031] S120, based on the first communication data, determine whether the state transition condition is met.

[0032] As an example, the MPU parses the first communication data obtained from the MCU and extracts the key status flags and abnormal information. For example, if the parsed "postrun request" flag sent by the MCU is valid and the system currently has no active countdown, or if the continuous error count of SPI communication reaches the preset threshold of 100 frames, then it is determined that the conditions for jumping to the "sleep condition judgment state" are met.

[0033] In this way, by analyzing whether the first communication data sent by the MCU contains status flags and communication error information, the system can accurately identify when the conditions for transitioning from the running state to the sleep preparation state are met. Since the transition can only occur after the transition conditions are met, problems such as state switching conflicts, prolonged ineffective operation, or abnormal suspension caused by missing or delayed condition judgments are avoided. This judgment mechanism enhances the reliability and timeliness of state transitions, provides a key decision node for the orderly execution of subsequent sleep procedures, and improves the determinism and stability of the T-Box in the low-power management process as a whole.

[0034] S130, when the state transition condition is met, controls the T-Box to switch to the sleep condition judgment state, and monitors the second communication data of the MCU through the MPU.

[0035] As an example, after the state transition conditions are met, the control T-Box switches to the sleep condition judgment state. In this state, the MPU continuously monitors the second communication data sent by the MCU through the SPI interface. The second communication data includes the MCU's real-time status word, wake-up source status flag, and SPI link communication quality information, etc. Specifically, the MPU reads the MCU status register cyclically. If any wake-up source is detected to be valid, or if the MCU is found to be running and communicating normally through SPI message parsing, it is determined that the conditions for switching to the sleep preparation state are not met. Conversely, if all wake-up sources are detected to be cleared and the MCU is not running, and the system is not in MTS mode, it is determined that the conditions for transitioning to the sleep preparation state are met, thereby triggering the subsequent sleep preparation process.

[0036] In this way, the MPU continuously monitors the MCU after the state transition conditions are met. Only after detecting the second communication data that satisfies the sleep condition will it execute the next operation. The second communication data includes wake-up source detection and communication interface detection. By confirming the status of these data, dual verification and dynamic awareness of the sleep switching conditions are achieved: on the one hand, it can detect in real time whether the wake-up source has become active again, avoiding loss of response due to external events during sleep preparation; on the other hand, by parsing the MCU status and communication link information, it ensures that the system is only allowed to enter the deep sleep process when the MCU has entered the low-power guard mode and there are no pending tasks. This secondary judgment mechanism based on real-time communication data significantly reduces the risk of accidentally entering sleep or sleep being interrupted, thereby improving the accuracy of the state switching process and the stability of the system in the low-power phase.

[0037] S140, based on the second communication data, determine whether the sleep conditions are met.

[0038] As an example, the MPU continuously parses the second communication data from the MCU when the T-Box switches to the sleep condition judgment state. This data may include a real-time wake-up source status bitmap, the MCU's current status flag, and an SPI communication quality indicator. The system determines that it meets the conditions for switching to the sleep preparation state when the judgment logic simultaneously meets the following three conditions: First, the wake-up source status bitmap is parsed to confirm that all wake-up source flags are cleared; second, the MCU status flag is confirmed to be not currently in working mode; third, the system mode flag is confirmed to be confirmed to be not in MTS mode. If any of the above conditions are not met, the sleep condition is determined not to be met, and the system will remain in the sleep condition judgment state or fall back to the normal operation state to continue monitoring, thereby achieving accurate and reliable control of sleep decision.

[0039] In this way, by constructing a hibernation decision mechanism based on multi-condition parallel verification, the final safety confirmation before the T-Box switches to hibernation is achieved: by simultaneously verifying three key conditions—wake-up source cleared, MCU exited working mode, and system not in special transmission mode—the hibernation transition is ensured to be performed only under the safe condition that there are no pending tasks inside or outside the system and the communication link is stable. This completely avoids problems such as premature hibernation, task loss, or state conflicts caused by misjudgment of a single state. This multi-factor collaborative judgment strategy significantly improves the accuracy of hibernation decision and the robustness of the system during state switching, maintaining the T-Box's reliable response capability to various events while ensuring extremely low power consumption operation.

[0040] S150, when the hibernation conditions are met, controls the T-Box to switch to the hibernation preparation state and performs the hibernation preparation operation through the MPU.

[0041] Specifically, such as Figure 2 As shown, S150 may include steps S1501-S1506: S1501, the MPU sends sleep requests to each functional module and sensor; S1502, disable the Controller Area Network CAN network startup flag; S1503, Set the RTC time of the heartbeat packet of the hardware monitoring device according to the IoT connection status and send it to the base station; S1504, the MPU sends a sleep confirmation signal to the MCU; S1505, the MPU sends a sleep request to the SPI; S1506 is the pin that releases and wakes up the MCU.

[0042] Understandably, in order to reduce the impact of cluttered data, relevant redundant data can also be cleared, such as votes on thread sleep request flags and votes on software locks.

[0043] As an example, after the sleep conditions are met, the control T-Box switches to the sleep preparation state and sequentially performs the following sleep preparation operations: First, the MPU sends sleep requests to various functional modules and sensors such as GPS and communication modules to put them into low-power mode; then, it disables the start flag of the Controller Area Network (CAN) to prevent network activity from preventing sleep; next, based on the current IoT connection status, it configures the heartbeat packet timing of hardware monitoring devices such as the RTC and sends it to the base station to ensure that the cloud can predict the next wake-up time; then, the MPU sends a sleep confirmation signal ACK to the MCU via SPI to notify the MCU that it can enter the cooperative sleep state; at the same time, the MPU sends a sleep request to the SPI controller to close the high-speed communication interface to reduce power consumption; finally, the MPU releases the hardware pin used to wake up the MCU and sets it to a high-impedance state to avoid false wake-ups caused by pin level fluctuations during sleep, thereby completing the entire set of hardware and software coordination and state synchronization before sleep.

[0044] In this way, the hibernation preparation operation is executed step by step. The MPU sends hibernation requests to each functional module and sensor to prevent peripheral chaos. It then disables the CAN network startup flag of the Controller Area Network (CAN) to put the network function into hibernation. Next, it sets the RTC time of the heartbeat packets of the hardware monitoring device according to the IoT connection status and sends it to the base station to ensure that a normal operation signal is sent to the base station during hibernation. This prevents the base station from judging the hardware as faulty and deleting the hardware data from the base station, causing the hardware to become unusable. Subsequently, the MPU sends a hibernation confirmation signal to the MCU in the form of a notification. The MPU sends a hibernation request to the SPI to notify the MCU and SPI that they can also enter hibernation. Finally, it releases the MCU wake-up pin, allowing the system to gradually enter hibernation. Through a multi-module, step-by-step collaborative control process, comprehensive low-power state synchronization from software to hardware and from local to cloud is achieved. The MPU sequentially notifies peripherals to enter hibernation, disables CAN network activity, configures and reports the heartbeat timing, sends a hibernation confirmation to the MCU, closes the SPI communication interface, and finally releases the MCU wake-up pin, forming an orderly and reliable pre-hibernation state convergence mechanism. This process effectively avoids problems such as leakage caused by peripherals not going into sleep mode in time, spontaneous activity of the CAN network preventing the system from sleeping, loss of connection to the cloud, inconsistent dual-core states, residual power consumption of the communication interface, and false wake-up caused by pin interference. Thus, while ensuring the system's wakeability, the overall power consumption is reduced to the minimum, significantly improving the power durability and status controllability of the T-Box in scenarios such as long-term parking and remote monitoring.

[0045] S160, after the hibernation preparation operation is completed, controls the T-Box to switch to hibernation mode.

[0046] Understandably, a waiting-to-sleep state can be inserted before switching to hibernation, which is used for the final wake-up source detection before entering hibernation. If no wake-up source is detected within a preset time, hibernation can be entered.

[0047] As an example, after all hibernation preparation operations are completed, the control T-Box switches to a waiting hibernation state. At this time, the system has shut down unnecessary peripherals, synchronized dual-core state, and completed pin release, maintaining only the minimum wake-up source monitoring function. If no wake-up source is triggered in this state, after a preset time, such as about 10 seconds, the MPU automatically clears the internal software lock and triggers the hardware hibernation command, putting itself into a deep hibernation state. At the same time, after receiving the hibernation confirmation from the MPU, the MCU also switches to the corresponding low-power guard mode. During the entire switching process, the MPU submits a hibernation ready flag to the internal state manager before finally hibernating and saves the current context to non-volatile memory to ensure accurate recovery after wake-up. In addition, if the MCU continuously detects an anomaly while monitoring SPI communication, such as communication failure for 30 consecutive seconds, it will actively shut down the MPU power supply and restore it after a preset time, thereby realizing a safe hibernation and recovery mechanism in abnormal states, ensuring the stability and wakeability of the system in low-power states.

[0048] In this way, once the preparation process is confirmed to be successful, the T-Box can be controlled to switch to sleep mode. Furthermore, through a buffer design for waiting for the sleep state, the system retains a short time window for final wake-up source verification after all hardware and software preparations are completed, effectively preventing sleep and wake-up conflicts caused by new events at the last minute. After confirming there is no interference, the MPU autonomously triggers the hardware sleep process, while the MCU simultaneously activates a low-power monitor mode. This dual-core collaborative mechanism ensures strict synchronization of the two cores' states, avoiding power consumption issues or state inconsistencies caused by one core failing to sleep in time.

[0049] In summary, in this embodiment, after the T-Box receives the sleep signal, the MPU monitors the MCU. After detecting the first communication data that satisfies the MCU's state transition conditions, it then detects the second communication data that satisfies the sleep conditions. The MPU then initiates a pre-sleep preparation operation, and after completing the preparation, the T-Box switches to sleep mode. That is, in this embodiment, after the T-Box receives the sleep signal, it does not immediately switch to sleep mode. Instead, the MPU monitors the MCU's data information and determines whether the state transition conditions and sleep conditions are met. Switching is only performed if both are met. Furthermore, a preparation operation is performed before sleep mode is initiated to ensure that sleep mode is not affected before switching to sleep mode. Therefore, this application improves the stability of T-Box state switching by increasing the decision point and having the MPU monitor the MCU, ensuring dual-core collaboration between the MPU and MCU, and managing peripherals in an organized manner.

[0050] In some embodiments, in order to achieve the purpose of timely response to emergencies, such as Figure 3 As shown, the method may further include steps S310-S340: S310 monitors the operating status of the MCU; S320, upon detecting that the operating status is in an emergency state, switches the current operating status of the T-Box to emergency response state; S330 continuously monitors the operating status of the MCU; S340, if it detects that the operating status is exiting the emergency state, will exit the current operating status of the T-Box from the emergency response state.

[0051] As an example, in any active state of the T-Box operation, such as normal operation, the MPU periodically reads the MCU's configured status register or parses the status frame data actively reported by the MCU via the serial peripheral interface SPI to continuously monitor the MCU's operating status. When a specific emergency status flag bit in the parsed status data is valid, such as when the "URGENT" bit in the status word is set to 1, the MPU immediately triggers an internal state machine switch, jumping its current state to a dedicated emergency response state. In this state, the MPU suspends or suspends regular non-emergency task threads and starts high-priority tasks or interrupt service routines dedicated to handling emergency events, such as vehicle collision signals or severe power undervoltage, while continuing to monitor the MCU's status data. Subsequently, when the MPU detects through continuous monitoring that the emergency flag bit in the MCU status data has been cleared, such as the "URGENT" bit returning to 0, indicating that the MCU has exited the emergency state, the MPU immediately controls its own state machine to exit the emergency state and restores to the original state before the jump or a specified safe state according to the preset strategy, and resumes the previously suspended normal tasks, thereby completing a follow-up response and state synchronization to the MCU emergency event, ensuring the coordination of dual-core behavior and the reliable degradation and recovery of system functions in the event of sudden abnormality.

[0052] In this way, by monitoring the MCU's operating status, when an emergency state is detected, the T-Box's current operating status is switched to emergency response state. Switching to emergency state allows for rapid response to emergencies. After entering emergency state, the MCU's operating status is continuously monitored. When the status indicates an exit from emergency state, the T-Box's current operating status is switched out of emergency response state. After the vehicle's emergency response ends, to ensure normal operation, the MCU status is continuously monitored to promptly exit emergency state and respond to user operations. Through continuous monitoring, this process enables rapid collaborative response and status synchronization of the dual-core system under abnormal events. The MPU can instantly identify the emergency state triggered by the MCU and proactively switch to a high-priority response mode, suspending non-critical tasks to focus on handling emergency matters. Simultaneously, continuous monitoring ensures that the MPU can promptly resume normal operation after the MCU exits emergency state. This mechanism effectively solves problems such as response delays, task conflicts, or functional omissions caused by asynchronous dual-core states in traditional architectures, significantly improving the system's real-time performance, reliability, and self-recovery capabilities under sudden abnormal situations, while ensuring a balance between power management and functional safety.

[0053] In some embodiments, the T-Box also includes a hardware monitoring device; after controlling the T-Box to switch to sleep mode, such as Figure 4 As shown, the method may further include steps S410-S430: The S410 uses hardware monitoring devices to monitor wake-up sources.

[0054] As an example, after the T-Box is switched to sleep mode, a separate low-power hardware monitoring device (such as a chip) continuously monitors various preset wake-up source signals. This hardware monitoring device is configured with multiple monitoring channels, each connected to a corresponding wake-up source input pin or signal line. It monitors the wake-up pin level of the CAN network controller, the interrupt output of the remote vehicle control module, the wake-up request signal of the cellular modem, the RTC timer overflow flag, and the trigger status of each physical button. The hardware monitoring device operates with extremely low power consumption, polling or interrupt-driven monitoring each channel signal according to preset detection logic, such as edge triggering or level holding. Once any channel detects a valid wake-up event, such as the CAN wake-up pin changing from low to high or the RTC timer counter reaching a preset value, the hardware monitoring device generates a corresponding wake-up flag based on the event type and triggers a power restoration and reset release operation to the MPU or MCU. This completes the initial response from deep sleep to wake-up triggering without the need for the main processor's involvement.

[0055] In this way, the system continuously monitors the wake-up source in deep sleep mode by using a dedicated hardware monitoring device independent of the main processor, thereby achieving reliable event perception and rapid wake-up triggering at extremely low power consumption.

[0056] S420, when the wake-up source is detected to be a non-control type wake-up source of the vehicle control platform, controls the MPU in the T-Box to switch to the MPU-only wake-up state.

[0057] As an example, when the hardware monitoring device continuously monitors and identifies a valid wake-up signal and parses its corresponding wake-up source identifier as WAKEUP_4G—that is, a "non-control wake-up source of the vehicle control platform" (usually corresponding to non-real-time control commands from the cloud, such as configuration update queries, log extraction, or OTA metadata distribution)—the device will trigger a dedicated wake-up sequence for the MPU: First, power supply to only the power domain where the MPU resides is restored, while keeping the power supply and clock of the MCU and most peripherals in a powered-off state; then, the hardware monitoring device or its associated power management unit will send a specific wake-up identifier and a reset release signal to the MPU. After the MPU wakes up, its bootloader or underlying driver first reads the wake-up identifier, confirms it as WAKEUP_4G type, and then the control state machine jumps to the "MPU-only wake-up state". In this state, the MPU only initializes its own kernel, necessary memory, 4G communication module and related software stack, and immediately sets the software lock to prevent itself from entering sleep mode too early. Subsequently, the MPU establishes a connection with the vehicle control platform through the 4G network, receives and processes the corresponding non-control service requests. After processing, if no other wake-up source requiring MCU participation is triggered, the MPU re-enters the low-power sleep state according to the conditions.

[0058] In this way, when the system is in sleep mode and receives a wake-up source that only requires MPU execution (i.e., a non-control wake-up source from the vehicle control platform), the optimal balance between system response and power consumption is achieved by waking up only the MPU to handle the non-control wake-up event from the vehicle control platform. On the one hand, for lightweight cloud services that do not require MCU and peripherals (such as configuration queries and OTA metadata retrieval), this mechanism avoids unnecessary static power consumption and startup latency caused by waking up the entire system, significantly reducing the energy consumption of a single service response. On the other hand, the MPU quickly establishes a connection and processes tasks in an independent wake-up state, maintaining the real-time performance and service continuity of cloud communication. At the same time, software locking prevents accidental sleep during processing, ensuring the complete execution of tasks. This intelligent hierarchical wake-up strategy based on wake-up source type effectively solves the power waste problem caused by "over-processing" in traditional solutions, and significantly improves the power endurance of the T-Box in long-term operation scenarios while meeting the needs of cloud interaction.

[0059] S430 wakes up the T-Box when it detects that the wake-up source is a wake-up source other than the non-control wake-up source of the vehicle control platform.

[0060] Specifically, S430 may include at least any one of the following A1-A4: A1: Wake up the MPU and set a software lock to prevent the MPU from sleeping; A2: Wake up the MCU; A3: Send exit sleep notifications to each functional module and sensor; A4: Send an exit hibernation notification to the cloud to synchronize the cloud with the T-Box.

[0061] As an example, when the hardware monitoring device detects a wake-up source other than WAKEUP_4G, such as WAKEUP_REMOTE_CTRL remote vehicle control command, WAKEUP_CAR_RESERV vehicle reservation event, or WAKEUP_CAN network wake-up, the device triggers a system-wide wake-up sequence: First, the power supply and clock of both the MPU and MCU are restored simultaneously, and their reset signals are released. After the MPU wakes up, it immediately sets an internal software lock during the boot phase to prevent it from entering sleep mode before initialization is complete. Subsequently, the MPU sends an exit sleep notification to each functional module (such as GPS, cellular communication module, Bluetooth controller) and sensor (such as accelerometer) through the system bus or dedicated control pins, gradually powering them up and restoring them to working status. At the same time, the MPU sends an exit sleep notification message to the cloud server through the restored communication link (such as 4G), informing the vehicle and T-Box that they have been woken up and are online, so that the cloud platform can synchronize the latest status and prepare for interaction. During this process, the MCU is also woken up and performs self-initialization, and then performs a status handshake with the MPU via SPI to confirm that both cores are ready. After completing the above steps, the system state machine transitions from the sleep state to the wake-up state and begins to process the corresponding wake-up events normally, such as performing remote unlocking, air conditioning control, or responding to CAN network requests.

[0062] In this way, when a wake-up source requiring the coordinated operation of the MCU and MPU is received during hibernation, the T-Box is woken up. Similar to the pre-hibernation preparation, a smooth wake-up is performed step-by-step. The MPU is woken up sequentially and systematically, and a software lock is set to prevent it from going into hibernation. The MCU is then woken up, and hibernation exit notifications are sent to all functional modules and sensors. A hibernation exit notification is also sent to the cloud to synchronize the cloud with the T-Box, ensuring a smooth system wake-up. Thus, this step, by implementing a coordinated wake-up and state synchronization process for full-function wake-up events requiring MCU participation, achieves a rapid and reliable recovery of the system from deep hibernation to full-function operation. Simultaneously waking up both the MPU and MCU and setting a software lock to prevent premature MPU hibernation ensures the real-time performance and stability of dual-core collaboration. Actively notifying functional modules and sensors to exit hibernation ensures the synchronous recovery of peripheral states, avoiding functional deficiencies or response delays due to device insecurity. Immediately sending wake-up notifications to the cloud maintains consistency between the vehicle and cloud states, providing a reliable connection foundation for subsequent remote control, data reporting, and other interactions. This system-wide wake-up mechanism enables low-latency and high-integrity responses when dealing with complex control tasks and emergency events, significantly improving the functional reliability and user experience of the T-Box in scenarios such as remote vehicle control and real-time monitoring.

[0063] In some embodiments, to address the situation where communication anomalies occur between the MCU and MPU during wake-up, the hardware monitoring device may include steps B1-B2 when it detects that the wake-up source is a type of wake-up source other than the non-control type wake-up source of the vehicle control platform: B1: If the MCU continuously monitors the serial peripheral interface SPI between the MPU and the MCU and fails within a first preset time period, the MCU will control the MPU to power off. B2: If the power outage lasts for the second duration, power supply to the MPU is restored via the MCU.

[0064] As an example, when the T-Box is in sleep mode and receives a wake-up signal, it needs to monitor the SPI communication status. If the MCU detects a continuous SPI communication failure (such as a hardware error flag being set, clock synchronization failure, or multiple consecutive frame data verification failures) within a first preset duration (e.g., 3 minutes for the initial monitoring cycle after system startup, and 30 seconds for subsequent monitoring cycles), the MCU determines that the SPI communication is abnormal and triggers the MPU abnormal recovery process: the MCU actively cuts off the power supply to the MPU through its controlled power management pins (e.g., the external PMIC enable signal controlled by GPIO), completely de-energizing it. Afterward, the MCU starts an internal timer to enter a second waiting period (e.g., 10 seconds), during which it continues to operate at low power and continuously monitors the SPI link status. When the second duration is reached, the MCU restores power to the MPU, releases the MPU reset signal, and re-attempts to establish SPI communication synchronization. If communication returns to normal, the system continues to run; if it is still abnormal, the MCU can repeat this power-off recovery process according to a preset strategy, thereby achieving forced MPU reset and system state recoverability in the event of hardware or software communication lockup.

[0065] In this way, if the MCU continuously monitors the SPI serial peripheral interface between the MPU and the MCU and fails within the first preset time period, the MCU controls the MPU to power down. This forces the MPU to restart, and if the power-off time continues into the second preset time period, the MCU restores power to the MPU, completing one round of anomaly recovery. Based on this, this step, through continuous monitoring of the SPI communication link by the MCU and proactive control of the MPU's power supply cycle during faults, constructs a hardware-level, automated communication anomaly recovery and system self-healing mechanism. When a persistent SPI failure is detected within the preset time period, the MCU proactively cuts off the MPU's power supply to achieve a forced hardware reset, completely eliminating persistent communication interruptions caused by MPU software deadlock, communication controller suspension, or clock malfunctions; subsequently, power is restored after the set second preset time period, causing the MPU to restart and attempt to rebuild communication. This process not only solves the problem of hardware anomalies that traditional software resets may not be able to completely clear.

[0066] In some embodiments, before controlling the T-Box to switch to a sleep state, the method may further include: Record the status of the T-Box's functional modules to enable a response when a wake-up source is detected by the hardware monitoring device.

[0067] As an example, before the T-Box switches to sleep mode, the system performs a functional module status recording operation through the MPU: the MPU traverses and queries the current operating status, configuration parameters, and suspended task information of each key functional module, organizes this data along with the collaborative status flags of the MPU and MCU into a structured status snapshot, and saves it to a preset area of ​​non-volatile memory. This status snapshot is updated before each system is about to enter sleep mode to ensure that it always reflects the latest hardware and software context. When a subsequent hardware monitoring device detects a valid wake-up source and triggers the system to wake up, the MPU will first read the stored status snapshot during the initialization process, and quickly restore the functional modules to their accurate operating configuration before sleep mode based on the recorded status and parameters of each module.

[0068] In this way, when preparing to switch the T-Box to sleep mode, the functional module status recording process is simultaneously initiated. The MPU, through its internal state manager or dedicated driver, sequentially collects and serializes the current operating mode, configuration parameters, cached data, and task queue status of each key functional module. Simultaneously, the MPU also records collaborative state information with the MCU, such as software lock flags, sleep voting results, and the remaining value of the wake-up source hold timer. This structured state data is packaged into a complete state context snapshot and saved to non-volatile storage via write operations. This snapshot is updated before each system prepares for sleep mode to ensure its timeliness. When a subsequent hardware monitoring device triggers a wake-up event, the MPU, during the wake-up phase, first reads this state snapshot from the non-volatile memory and, based on the module status and parameters recorded in the snapshot, guides the corresponding driver or middleware to quickly restore each functional module to its precise working state before sleep mode. This avoids the lengthy reinitialization and reconfiguration of all peripherals after wake-up, significantly shortening the overall latency from wake-up to readiness, thus achieving rapid response to user operations.

[0069] In some embodiments, the method may further include: If the conditions for the MTS mode of the module test system are met and the system is not in sleep mode, control the T-Box to switch to sleep mode under MTS mode.

[0070] As an example, when the system detects that the Module Test System (MTS) mode conditions are met—for example, the vehicle is in transport mode, factory testing mode, or a specific diagnostic state—and confirms through querying the state machine that it is not currently in a hibernation or shutdown state, the system will immediately trigger a forced rapid hibernation process: The MPU first suspends or forcibly terminates all running application tasks and network connections, then controls the communication module to enter flight mode and sends an emergency hibernation coordination request to the MCU; upon receiving the request, the MCU synchronously suspends its low-priority tasks and quickly shuts down the power domains of the peripherals it manages. Next, the system state machine directly jumps to the dedicated MTS hibernation state. In this state, the MPU and MCU maintain only minimal hardware monitoring functions and shut down all unnecessary clocks and power supplies; if no wake-up source is triggered for a preset duration of 10 seconds in this state, the T-Box will switch to deep hibernation.

[0071] Thus, among the many modes in automobiles, a forced and rapid low-power sleep mode is designed for specific scenarios such as transportation and factory debugging. In this embodiment, to quickly respond to the corresponding mode in these special scenarios, by judging and responding to the MTS mode conditions, the system can unconditionally suspend tasks, disable wireless communication, and coordinate the dual cores to quickly enter deep sleep when not in use. Its forced and rapid sleep strategy avoids the delays caused by condition judgment and state convergence in traditional sleep processes, ensuring absolute reliability and execution efficiency of power management in specific engineering scenarios.

[0072] Based on the above-described method for switching the state of a vehicle-mounted remote communication terminal T-Box, this application also provides a device for switching the state of a vehicle-mounted remote communication terminal T-Box.

[0073] Figure 5 This is a schematic diagram of the structure of a vehicle-mounted remote communication terminal T-Box state switching device provided in an embodiment of this application. Figure 5 As shown, the vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU), and the device may include: The first monitoring module 510 is used to monitor the first communication data of the MCU through the MPU when the T-Box is in a wake-up state and receives a sleep signal; The first judgment module 520 is used to determine whether the state transition condition is met based on the first communication data; The second monitoring module 530 is used to control the T-Box to switch to the sleep condition judgment state when the state transition condition is met, and to monitor the second communication data of the MCU through the MPU; The second judgment module 540 is used to determine whether the sleep conditions are met based on the second communication data; The hibernation preparation module 550 is used to control the T-Box to switch to the hibernation preparation state when the hibernation conditions are met, and to perform the hibernation preparation operation through the MPU. The hibernation module 560 is used to control the T-Box to switch to hibernation mode after the hibernation preparation operation is completed.

[0074] In this way, the T-Box's state transition from wake-up to sleep is decomposed into multiple standardized modules through modular design, including a first monitoring module 510, a first judgment module 520, a second monitoring module 530, a second judgment module 540, a sleep preparation module 550, and a sleep module 560. This constructs a complete, controllable, and logically clear dual-core collaborative low-power management architecture. Each module has a clear division of labor and is sequentially connected, achieving dual monitoring and conditional judgment of MCU status and communication data. This ensures that each state transition is fully verified, effectively preventing sleep anomalies or wake-up failures due to single misjudgments or state asynchrony. Simultaneously, the device encapsulates complex logic such as MPU and MCU collaborative operation, peripheral management, and cloud synchronization into reusable modules, improving system maintainability and scalability. Overall, this device significantly enhances the reliability, real-time performance, and power consumption control accuracy of T-Box state transitions in various scenarios such as long-term monitoring, remote wake-up, and emergency response, providing a stable and efficient power management foundation for intelligent connected vehicles.

[0075] In some embodiments, the device may further include: The first monitoring module is used to monitor the operating status of the MCU; The emergency state entry module is used to switch the current operating state of the T-Box to emergency response state when an emergency state is detected. The second monitoring module is used to continuously monitor the operating status of the MCU; The emergency exit module is used to exit the emergency response state of the T-Box when the operating status is detected as exiting the emergency state.

[0076] In some embodiments, the device may further include: The hardware monitoring module is used to monitor the wake-up source using hardware monitoring equipment; The first wake-up module is used to control the MPU in the T-Box to switch to the MPU-only wake-up state when the wake-up source is detected to be a non-control wake-up source of the vehicle control platform. The second wake-up module is used to wake up the T-Box when the wake-up source is detected to be a wake-up source other than the non-control type wake-up source of the vehicle control platform.

[0077] In some embodiments, the second wake-up unit can also be used for: Wake up the MPU and set a software lock to prevent the MPU from sleeping; Wake up the MCU; Send exit sleep notifications to each functional module and sensor; Send an exit hibernation notification to the cloud to synchronize the cloud with the T-Box.

[0078] In some embodiments, the device may further include: The power-off module is used by the MCU to control the MPU to power off if the serial peripheral interface SPI between the MPU and the MCU fails within a first preset time period. The power supply module is used to restore power to the MPU via the MCU if the power outage lasts for a second period of time.

[0079] In some embodiments, the hibernation preparation module 550 can also be used for: The MPU sends sleep requests to each functional module and sensor; Disable the Controller Area Network (CAN) network startup flag; Set the RTC time of the heartbeat packet of the hardware monitoring device according to the IoT connection status and send it to the base station; The MPU sends a sleep confirmation signal to the MCU; The MPU sends a sleep request to the SPI; Release the pin that wakes up the MCU.

[0080] In some embodiments, the device may further include: The recording module is used to record the state of the T-Box's functional modules before the T-Box switches to sleep mode, so as to respond when the hardware monitoring device detects a wake-up source.

[0081] In some embodiments, the device may further include: The MTS mode module is used to control the T-Box to switch to the sleep state in MTS mode when it is determined that the conditions of the module test system MTS mode are met and the device is not in sleep mode.

[0082] Based on the above-described method and apparatus for switching the state of the vehicle-mounted remote communication terminal T-Box, this application also provides a vehicle.

[0083] Figure 6 A schematic diagram of the hardware structure of the vehicle provided in an embodiment of this application is shown.

[0084] The vehicle may include a processor 601 and a memory 602 storing computer program instructions.

[0085] Specifically, the processor 601 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.

[0086] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 602 may include removable or non-removable (or fixed) media, or memory 602 may be non-volatile solid-state memory. Memory 602 may be internal or external to the integrated gateway disaster recovery device.

[0087] Memory 602 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0088] The processor 601 reads and executes computer program instructions stored in the memory 602 to achieve... Figure 1 The embodiment shown illustrates the method for switching the state of the vehicle-mounted remote communication terminal T-Box.

[0089] In one example, the vehicle may also include a communication interface 603 and a bus 604. Wherein, as... Figure 3 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 604 and complete communication with each other.

[0090] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0091] Bus 604 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus 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 Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 604 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.

[0092] Furthermore, in conjunction with the vehicle-mounted system state switching method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle-mounted remote communication terminal T-Box state switching methods in the above embodiments.

[0093] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the vehicle-mounted remote communication terminal T-Box state switching methods described in the above embodiments.

[0094] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0095] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0096] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0097] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0098] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0099] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0100] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for switching the state of a vehicle-mounted remote communication terminal T-Box, wherein the vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU), characterized in that, The method includes: When the T-Box is in a wake-up state and receives a sleep signal, the first communication data of the MCU is monitored by the MPU; Based on the first communication data, determine whether the state transition condition is met; When the state transition condition is met, the T-Box is controlled to switch to the sleep condition judgment state, and the second communication data of the MCU is monitored through the MPU; Based on the second communication data, determine whether the sleep conditions are met; When the hibernation conditions are met, the T-Box is controlled to switch to a hibernation preparation state, and the hibernation preparation operation is performed through the MPU; Once the hibernation preparation operation is completed, control the T-Box to switch to hibernation mode.

2. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 1, characterized in that, The method further includes: Monitor the operating status of the MCU; If the operating status is detected to be in an emergency state, the current operating status of the T-Box will be switched to emergency response state; Continuously monitor the operating status of the MCU; If the operating status is detected as exiting the emergency state, the current operating status of the T-Box will be exited from the emergency response state.

3. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 1, characterized in that, The T-Box is equipped with a hardware monitoring device; after controlling the T-Box to switch to sleep mode, the method further includes: The wake-up source is monitored using the aforementioned hardware monitoring device; If the wake-up source is detected to be a non-control type wake-up source of the vehicle control platform, the MPU in the T-Box is controlled to switch to the MPU-only wake-up state. If the wake-up source is detected to be a wake-up source other than the non-control type wake-up source of the vehicle control platform, the T-Box will be woken up.

4. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 3, characterized in that, Controlling the T-Box to switch to the wake-up state includes at least one of the following: Wake up the MPU and set a software lock to prevent the MPU from going to sleep; Wake up the MCU; Send exit sleep notifications to each functional module and sensor; Send an exit hibernation notification to the cloud to synchronize the cloud with the T-Box.

5. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 3, characterized in that, When the wake-up source is detected to be a wake-up source other than the non-control type wake-up source of the vehicle control platform, the method further includes: If the MCU continuously monitors the serial peripheral interface SPI between the MPU and the MCU and fails within a first preset time period, the MCU controls the MPU to power off. If the power outage lasts for a second duration, the power supply to the MPU is restored via the MCU.

6. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 3, characterized in that, When the hibernation conditions are met, the T-Box is controlled to switch to a hibernation preparation state, and the hibernation preparation operation is performed through the MPU, including: The MPU sends sleep requests to each functional module and sensor; Disable the Controller Area Network (CAN) network startup flag; The RTC time of the heartbeat packet of the hardware monitoring device is set according to the IoT connection status and sent to the base station; The MPU sends a sleep confirmation signal to the MCU; The MPU sends a sleep request to the SPI; Release the pin that wakes up the MCU.

7. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to claim 3, characterized in that, Before controlling the T-Box to switch to sleep mode, the method further includes: Record the state of the functional modules of the T-Box so as to respond when the hardware monitoring device detects a wake-up source.

8. The method for switching the state of the vehicle-mounted remote communication terminal T-Box according to any one of claims 1-7, characterized in that, The method further includes: If the conditions for the Module Test System (MTS) mode are met and the system is not in the sleep state, the T-Box is controlled to switch to the sleep state under the MTS mode.

9. A vehicle-mounted remote communication terminal T-Box state switching device, characterized in that, The vehicle-mounted remote communication terminal T-Box includes a microprocessor (MPU) and a microcontroller (MCU), and the device includes: The first monitoring module is used to monitor the first communication data of the MCU through the MPU when the MPU is in a wake-up state and receives a sleep signal; The first judgment module is used to determine whether the state transition condition is met based on the first communication data; The second monitoring module is used to control the T-Box to switch to the sleep condition judgment state when the state transition condition is met, and to monitor the second communication data of the MCU through the MPU; The second judgment module is used to determine whether the sleep conditions are met based on the second communication data; The hibernation preparation module is used to control the T-Box to switch to a hibernation preparation state when the hibernation conditions are met, and to perform hibernation preparation operations through the MPU. A hibernation module is used to control the T-Box to switch to hibernation mode when the hibernation preparation operation is completed.

10. A vehicle, characterized in that, The vehicle includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the vehicle-mounted remote communication terminal T-Box state switching method as described in any one of claims 1-8.

11. A computer storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed by a processor, implement the vehicle-mounted remote communication terminal T-Box state switching method as described in any one of claims 1-8.

12. A computer program product, characterized in that, It includes a computer program, which, when executed by a processor, implements the vehicle-mounted remote communication terminal T-Box state switching method as described in any one of claims 1-8.

Images