Vehicle remote cooperative control method and device, vehicle, equipment and product
By adopting an adaptive reporting strategy, the T-BOX reporting mode is dynamically adjusted according to vehicle status and network conditions, which solves the problems of high power consumption and low network resource utilization of the vehicle terminal, improves the real-time performance and success rate of remote control, and ensures the real-time performance and security of vehicle status information.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHERY AUTOMOBILE CO LTD
- Filing Date
- 2026-03-02
- Publication Date
- 2026-06-23
AI Technical Summary
Existing vehicle-mounted telematics processors (T-BOXs) suffer from high power consumption and low network resource utilization in their status reporting mechanisms due to fixed frequencies or simple triggering. Furthermore, outdated status information during remote control can lead to control failures or security risks.
By constructing an adaptive reporting strategy, feature information is built based on vehicle operating conditions, network environment, and business scenarios. The appropriate reporting mode is dynamically selected, and the current mode is interrupted when a remote control command is received. The target status data is collected and uploaded, and the control process parameters are continuously reported until the end.
It reduces terminal energy consumption and network load, improves the real-time performance and success rate of remote control, realizes deep collaboration between vehicle status reporting and remote control, and improves system efficiency and reliability.
Smart Images

Figure CN122268889A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle networking communication and remote control technology, and in particular to a method, device, vehicle, equipment and product for remote collaborative control of vehicles. Background Technology
[0002] Currently, the vehicle telematics processor (T-BOX), as the core terminal of the vehicle-to-everything (V2X) system, is widely used in vehicle status monitoring and remote control services. The T-BOX periodically collects vehicle status data, such as door lock status, window position, and battery level, through the vehicle network, and reports this data to the cloud platform. At the same time, it responds to remote control commands from the cloud to realize remote operation and management of the vehicle.
[0003] In related technologies, T-BOX status reporting methods are mainly divided into two modes: one is the fixed-frequency reporting mode, which periodically collects and reports vehicle status at preset time intervals (such as every 30 seconds); the other is the event-triggered reporting mode, which triggers a status report only when a specific event occurs (such as locking or unlocking a door). The former is simple to implement, but when the vehicle is stationary for a long time or its status does not change, it will generate a large amount of redundant data, resulting in a waste of vehicle battery power and cellular network resources; the latter, although it has a certain energy-saving effect during the stationary period, cannot be perceived by the cloud, leading to control failure or security risks due to outdated status information during remote control, which urgently needs to be solved. Summary of the Invention
[0004] This application provides a method, device, vehicle, equipment, and product for remote collaborative control of vehicles, which solves the problems of high power consumption and low network resource utilization of vehicle terminals caused by fixed frequency or simple triggering in existing vehicle status reporting mechanisms. It reduces terminal power consumption and network load, and improves the real-time performance and success rate of remote control.
[0005] The first aspect of this application provides a method for remote collaborative control of vehicles, including the following steps:
[0006] Acquire current vehicle operating data and cloud command data, and construct feature information to describe the current vehicle context state; Select a target reporting mode that matches the feature information from a variety of preset reporting modes, and perform status reporting based on the target reporting mode; Upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud. During the execution of the remote control command, the control process parameters of the actuator corresponding to the remote control command are continuously reported until the preset termination condition is met.
[0007] According to one embodiment of this application, the preset multiple reporting modes include: The first mode sends all status data at the first reporting frequency; A second mode in which partial status data is sent at a second reporting frequency, wherein the second reporting frequency is less than the first reporting frequency; The third mode is triggered in response to a preset signal transition in the signal bus; The fourth mode is triggered in response to business events issued from the cloud.
[0008] According to one embodiment of this application, selecting a target reporting mode that matches the feature information from a preset plurality of reporting modes includes: Determine whether the current vehicle speed is greater than the preset vehicle speed and whether the current network signal strength is higher than the preset signal threshold; When the current vehicle speed is greater than the preset vehicle speed and the current network signal strength is higher than the preset signal threshold, the first reporting mode is selected as the target reporting mode.
[0009] According to one embodiment of this application, the step of selecting a target reporting mode that matches the feature information from a preset plurality of reporting modes further includes: Determine whether the current power setting is the off position and whether the duration of the target signal's change frequency being zero is greater than the preset duration; If the current power setting is the off position and the duration of the target signal changing at a frequency of zero is greater than the preset duration, then the second reporting mode is selected as the target reporting mode.
[0010] According to one embodiment of this application, the step of selecting a target reporting mode that matches the feature information from a preset plurality of reporting modes further includes: Determine whether any of the following signals of the current vehicle—door lock signal, window position signal, or tire pressure signal—has undergone a state transition; If any of the current vehicle's door lock signal, window position signal, or tire pressure signal undergoes a state change, the third reporting mode is selected as the target reporting mode.
[0011] According to one embodiment of this application, the feature information includes at least one of the following: vehicle power gear signal, vehicle speed signal, target signal change frequency, network signal strength, and pending instruction queue status sent from the cloud. The control process parameters of the actuator include at least one of the following: drive motor current value, position sensor output value, percentage of travel, and fault code.
[0012] According to the vehicle remote collaborative control method provided in this application embodiment, feature information describing the current vehicle context state is constructed; a target reporting mode matching the feature information is selected from a variety of preset reporting modes, and status reporting is executed; upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud; during the execution of the remote control command, control process parameters of the actuator corresponding to the remote control command are continuously reported until a preset termination condition is met. This solves the problems of high power consumption and low network resource utilization of the vehicle terminal caused by fixed frequency or simple triggering in existing vehicle status reporting mechanisms, reduces terminal energy consumption and network load, and improves the real-time performance and success rate of remote control.
[0013] A second aspect of this application provides a vehicle remote cooperative control device, comprising: The acquisition module is used to acquire the current vehicle's operating data and cloud command data, and to construct feature information to describe the current vehicle's context state. The matching module is used to select a target reporting mode that matches the feature information from a variety of preset reporting modes, and to perform status reporting based on the target reporting mode; The processing module is used to interrupt the target reporting mode that is being executed when a remote control command is received, collect the target status data corresponding to the remote control command, and upload the target status data to the cloud. The control module is used to continuously report the control process parameters of the actuator corresponding to the remote control command during the execution of the remote control command until the preset termination condition is met.
[0014] According to one embodiment of this application, the preset multiple reporting modes include: The first mode sends all status data at the first reporting frequency; A second mode in which partial status data is sent at a second reporting frequency, wherein the second reporting frequency is less than the first reporting frequency; The third mode is triggered in response to a preset signal transition in the signal bus; The fourth mode is triggered in response to business events issued from the cloud.
[0015] According to one embodiment of this application, the matching module is configured to: Determine whether the current vehicle speed is greater than the preset vehicle speed and whether the current network signal strength is higher than the preset signal threshold; When the current vehicle speed is greater than the preset vehicle speed and the current network signal strength is higher than the preset signal threshold, the first reporting mode is selected as the target reporting mode.
[0016] According to one embodiment of this application, the matching module is configured to: Determine whether the current power setting is the off position and whether the duration of the target signal's change frequency being zero is greater than the preset duration; If the current power setting is the off position and the duration of the target signal changing at a frequency of zero is greater than the preset duration, then the second reporting mode is selected as the target reporting mode.
[0017] According to one embodiment of this application, the matching module is configured to: Determine whether any of the following signals of the current vehicle—door lock signal, window position signal, or tire pressure signal—has undergone a state transition; If any of the current vehicle's door lock signal, window position signal, or tire pressure signal undergoes a state change, the third reporting mode is selected as the target reporting mode.
[0018] According to one embodiment of this application, the feature information includes at least one of the following: vehicle power gear signal, vehicle speed signal, target signal change frequency, network signal strength, and pending instruction queue status sent from the cloud. The control process parameters of the actuator include at least one of the following: drive motor current value, position sensor output value, percentage of travel, and fault code.
[0019] According to the vehicle remote collaborative control device provided in this application embodiment, feature information describing the current vehicle context state is constructed; a target reporting mode matching the feature information is selected from a variety of preset reporting modes, and status reporting is executed; upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud; during the execution of the remote control command, control process parameters of the actuator corresponding to the remote control command are continuously reported until a preset termination condition is met. This solves the problems of high power consumption and low network resource utilization of the vehicle terminal caused by fixed frequency or simple triggering in existing vehicle status reporting mechanisms, reduces terminal energy consumption and network load, and improves the real-time performance and success rate of remote control.
[0020] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle remote cooperative control method as described in the above embodiments.
[0021] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to perform the vehicle remote cooperative control method as described in the above embodiments.
[0022] A fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the vehicle remote cooperative control method as described in the above embodiments.
[0023] 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
[0024] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a vehicle remote cooperative control method provided according to an embodiment of this application; Figure 2 This is a schematic diagram of the overall system architecture and core modules according to an embodiment of this application; Figure 3 This is a flowchart illustrating the dynamic decision-making and switching process of an adaptive reporting strategy according to an embodiment of this application; Figure 4 This is a remote control coordination timing diagram according to an embodiment of this application; Figure 5 This is a block diagram of a vehicle remote collaborative control device according to an embodiment of this application; Figure 6 This is a schematic diagram of the vehicle structure provided in an embodiment of this application. Detailed Implementation
[0025] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0026] Those skilled in the art will understand that the fixed-frequency reporting in related technologies generates a large amount of redundant data when the vehicle is stationary or in a stable state, needlessly consuming vehicle battery power and cellular network traffic, especially negatively impacting the driving range of electric vehicles and leading to low resource efficiency. Furthermore, using simple event-triggered reporting, when the cloud receives remote control commands (such as remotely opening windows), the lack of the latest and most accurate real-time vehicle status (such as whether the windows are currently half-open) may lead to control logic errors, execution failures, or even safety hazards (such as remotely opening windows in rainy weather).
[0027] Furthermore, the related technologies lack inter-system coordination. The status reporting module and the remote control module typically operate independently, and the reporting strategy does not dynamically adjust due to upcoming or ongoing remote control, failing to provide real-time, high-fidelity status information support for control decisions. Moreover, the reporting strategies in these technologies are rigid and lack adaptability, failing to adjust in real-time and intelligently based on factors such as vehicle operating conditions (driving / stationary), network environment, and user activity.
[0028] Based on the technical problems existing in the aforementioned related technologies, this application proposes a vehicle remote collaborative control method to solve the problems of low control success rate and potential safety risks caused by the lack of real-time and accurate vehicle status information support for remote control commands. By constructing an intelligent system that enables deep collaboration and adaptive optimization between status reporting and remote control, the overall efficiency and reliability of vehicle networking services are improved.
[0029] The following description, with reference to the accompanying drawings, describes a vehicle remote collaborative control method, apparatus, vehicle, equipment, and product according to embodiments of this application.
[0030] Specifically, Figure 1 This is a flowchart illustrating a vehicle remote collaborative control method provided in an embodiment of this application.
[0031] like Figure 1 As shown, the vehicle remote collaborative control method includes the following steps: In step S101, the current vehicle's operating data and cloud command data are obtained to construct feature information describing the current vehicle's context state.
[0032] In some embodiments, the feature information includes at least one of the following: vehicle power level signal, vehicle speed signal, frequency of change of target signal, network signal strength, and status of pending instruction queue sent from the cloud.
[0033] Specifically, this application embodiment continuously monitors vehicle operating conditions, network environment and business scenarios through T-BOX to construct an adaptive decision context, which specifically includes: vehicle power mode, driving speed, rate of change of key status signals, cellular network signal strength, and cloud active instruction queue.
[0034] In step S102, a target reporting mode that matches the feature information is selected from a variety of preset reporting modes, and status reporting is performed based on the target reporting mode.
[0035] In some embodiments, the preset multiple reporting modes include: a first mode that sends full status data at a first reporting frequency; a second mode that sends partial status data at a second reporting frequency, wherein the second reporting frequency is less than the first reporting frequency; a third mode triggered in response to a preset signal transition in the signal bus; and a fourth mode triggered in response to a business event sent from the cloud.
[0036] Specifically, based on the decision context, the adaptive strategy engine built into the T-BOX dynamically selects and switches reporting strategies in this embodiment. The strategies include at least: high-frequency polling mode, low-power heartbeat mode, change-triggered mode, and event-driven mode. For example, high-frequency polling is used when the vehicle is moving and the network is good; when the vehicle is stationary, it switches to low-power heartbeat mode to maintain only the connection.
[0037] Furthermore, in some embodiments, selecting a target reporting mode that matches the feature information from a set of preset reporting modes includes: determining whether the current vehicle speed is greater than a preset vehicle speed and whether the current network signal strength is higher than a preset signal threshold; if the current vehicle speed is greater than the preset vehicle speed and the current network signal strength is higher than the preset signal threshold, selecting the first reporting mode as the target reporting mode.
[0038] Specifically, the vehicle terminal collects and analyzes the current vehicle speed signal and network signal strength (such as RSRP or SINR values) in real time, comparing them with preset vehicle speed thresholds (e.g., 60 km / h) and signal quality thresholds (e.g., -105 dBm). The core of this logic is to confirm that the vehicle is not only in a state of rapid movement, requiring high-frequency status updates to support navigation, trajectory tracking, or active safety services, but also to confirm that the current cellular network environment has the capacity to carry high-bandwidth, low-latency data transmission, thereby avoiding data packet loss or retransmission energy consumption due to network fluctuations.
[0039] When both of the above conditions are met simultaneously—that is, when the current vehicle speed is greater than the preset speed and the network signal strength is higher than the preset signal threshold—the system will automatically activate and select the first reporting mode as the current target reporting mode. The first reporting mode is defined as a high-fidelity, high-frequency full-data reporting strategy. It sends a full-dataset containing vehicle position, speed, acceleration, heading angle, battery SOC, motor speed, etc., to the cloud at a high first reporting frequency (e.g., once per second or higher, depending on specific business needs). This mode selection is based on the principle of "resource availability matching business needs": when a vehicle is traveling at high speed, its state changes drastically, requiring a high-density data stream to build accurate digital twins or provide real-time risk warnings; while a high-quality network signal ensures that this high-frequency transmission will not cause network congestion, achieving an optimal balance between data timeliness and transmission reliability.
[0040] Furthermore, in some embodiments, selecting a target reporting mode that matches the feature information from a preset variety of reporting modes further includes: determining whether the current power setting is the off position and whether the duration of the target signal changing at zero frequency is greater than a preset duration; if the current power setting is the off position and the duration of the target signal changing at zero frequency is greater than the preset duration, selecting a second reporting mode as the target reporting mode.
[0041] Specifically, firstly, the vehicle's power status signal (such as IGN or KL15 signal) is monitored in real time to confirm whether it has been switched to the off position (i.e., OFF or ACC off). Secondly, to eliminate the possibility of residual power fluctuations, intermittent operation of the anti-theft system, or misjudgments caused by the user's brief absence after the vehicle is turned off, the frequency of change of key target signals (such as door lock status, window position, battery voltage, vehicle tilt angle, etc.) is continuously monitored. Only when the frequency of change of these target signals is zero for a continuous preset period of time (e.g., 30 minutes or 1 hour), that is, when there are no state transitions or numerical fluctuations, is the vehicle determined to be in a completely stable and inactive resting period, and the second reporting mode will be automatically selected as the current target reporting mode.
[0042] The second reporting mode is defined as a highly simplified energy-saving strategy. Its core feature is sending a subset of critical status data at a significantly lower reporting frequency than the first mode (e.g., once every 24 hours or only triggered when the battery level is below a threshold). In this mode, the T-BOX drastically reduces unnecessary sensor acquisition activities and the number of times the communication module is woken up, retaining only a small amount of data crucial to the vehicle's survival status (such as remaining battery power (SOC), vehicle fault code summaries, and geolocation snapshots) for periodic reporting. This prevents the small battery from running out of power and failing to start due to prolonged high-frequency reporting, while also reducing the ineffective use of cellular network traffic, achieving optimal resource allocation during long-term vehicle parking.
[0043] Furthermore, in some embodiments, selecting a target reporting mode that matches the feature information from a variety of preset reporting modes further includes: determining whether any of the current vehicle's door lock signal, window position signal, or tire pressure signal has undergone a state change; if any of the current vehicle's door lock signal, window position signal, or tire pressure signal has undergone a state change, selecting a third reporting mode as the target reporting mode.
[0044] Specifically, the onboard terminal continuously monitors key discrete or analog data such as door lock status signals, window position sensor signals, and tire pressure monitoring signals. By comparing the current sampled value with the stored value from the previous cycle, it accurately identifies whether a state transition has occurred. This transition usually signifies an instantaneous change in the vehicle's physical state, such as a door changing from locked to unlocked, or a window changing from closed to open. Once a state transition is detected in any of these signals, it is determined that the vehicle has entered a special operating condition requiring immediate response. Therefore, the conventional periodic reporting logic is ignored, and the third reporting mode is directly selected and switched to.
[0045] The third reporting mode, a high-priority, instant-triggered reporting strategy, differs from the first mode's full-volume, high-frequency reporting. It is activated only upon detecting a change event, immediately collecting and uploading critical data packets containing the change signal type, state values before and after the change, timestamps, and relevant contextual information (such as current vehicle speed and geographical location). At a fixed frequency, if an event occurs between two reporting cycles, the cloud-perceived state will be severely delayed, potentially leading to undetected safety hazards. The third mode ensures that any critical state changes involving doors, windows, or tires are synchronized to the cloud within milliseconds, providing real-time decision-making support for remote monitoring, anti-theft alarms, and emergency rescue.
[0046] In step S103, upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud.
[0047] Specifically, when the T-BOX receives a remote control command from the cloud, it immediately performs a pre-control state synchronization: interrupting the current reporting strategy, immediately collecting and reporting the latest and most granular vehicle status related to the command to the cloud; the cloud control service performs final security verification and fine-tuning of command parameters based on this synchronized state.
[0048] In step S104, during the execution of the remote control command, the control process parameters of the actuator corresponding to the remote control command are continuously reported until the preset termination condition is met.
[0049] The control process parameters of the actuator include at least one of the following: drive motor current value, position sensor output value, percentage of travel, and fault code.
[0050] Specifically, during the execution of remote control commands, the T-BOX switches to process tracking mode, reporting key status signals directly related to the control action at a higher frequency than usual, until the action is completed or a timeout occurs. This process data flow forms a closed loop of "control command - execution feedback," which is then monitored in real time by the cloud.
[0051] It should be noted that the system records the execution result, process time, and reporting strategy used for each remote control operation. By analyzing successful and highly efficient cases, strategy optimization knowledge is generated, which is used to dynamically adjust the parameters of the default reporting strategy in various scenarios, thereby continuously improving the overall system energy efficiency and control experience.
[0052] To help those skilled in the art to more intuitively understand the vehicle remote collaborative control method of this application, the following explanation is provided with examples.
[0053] S1. Multi-dimensional state perception and context construction.
[0054] T-BOX continuously monitors and constructs a multi-dimensional vector as the decision context Ctx: Ctx.power_mode: Vehicle power mode (OFF / ACC / ON), derived from the CAN bus.
[0055] Ctx.speed: Real-time vehicle speed.
[0056] Ctx.signal_volatility: Calculates the frequency of change of critical states (such as door locks, windows, tire pressure) over the past minute.
[0057] Ctx.network_rssi: Current cellular network signal strength.
[0058] Ctx.pending_commands: A list of pending or active remote control commands subscribed from the cloud.
[0059] S2. Adaptive reporting strategy dynamic decision-making.
[0060] The adaptive policy engine has a pre-built policy matrix that matches based on Ctx: If Ctx.speed > 5km / h and Ctx.network_rssi > -85dBm, then P1 mode is used: a full state snapshot is reported every 10 seconds.
[0061] If Ctx.power_mode == OFF and Ctx.signal_volatility == 0 persists for more than 5 minutes, then P2 mode is used: a heartbeat packet containing only power and network status is sent every 5 minutes.
[0062] If any door status changes from "locked" to "open" during monitoring, P3 mode is immediately triggered, and the "door status change" event and associated status are reported.
[0063] S3. Priority response and status synchronization of remote control commands.
[0064] When the cloud sends a "remotely open the trunk" command, the T-BOX's remote control agent module will send a high-priority interrupt to the policy engine.
[0065] The policy engine immediately forces a switch to "control synchronization mode (S mode)".
[0066] The T-BOX uses the CAN bus to not only query the trunk lock status, but also to query related safety statuses such as whether the vehicle is in P gear and whether the doors are unlocked.
[0067] Within 100 milliseconds, this precise and correlated status data is packaged and reported to the cloud-based remote control service via a high-priority message.
[0068] S4. Status tracking and reporting of the control execution process.
[0069] After the cloud confirms the status is safe, the final execution command is issued. T-BOX entry process tracking: During command execution, the T-BOX reports process signals such as "trunk lock motor current" and "latch position sensor" twice per second. If an abnormal current or timeout is detected, a fault event is immediately reported. After execution, the final status "trunk open" is reported.
[0070] S5. Strategy feedback and self-learning optimization.
[0071] System log: {Command: “Open trunk”, Initial strategy: P2, Synchronization delay: 105ms, Execution result: Success, Total time: 2.1s}.
[0072] After analyzing massive amounts of logs, the Collaborative Policy Manager discovered that when a vehicle is in P2 mode, the average synchronization latency for responding to remote control is 200ms higher than in P1 mode. Therefore, the manager can issue a policy optimization suggestion: "For vehicles frequently controlled remotely (such as test fleets), shorten the heartbeat interval in P2 mode from 5 minutes to 2 minutes during idle periods to balance reducing power consumption and improving control response speed." The T-BOX policy engine receives and applies this optimization.
[0073] The following is combined Figures 2-4 The vehicle remote collaborative control method of the present invention will be described in detail.
[0074] like Figure 2 As shown, the system architecture for adaptive vehicle status reporting and remote control collaborative processing is divided into two main modules: the vehicle-side intelligent T-BOX and the cloud service platform. On the vehicle side, the vehicle CAN bus status signal serves as the raw input to the adaptive strategy engine. This engine dynamically selects and drives multi-mode reporting actuators to upload data based on decision context, pre-control status synchronization requests, or strategy optimization suggestions. Simultaneously, when a remote control command is received from the cloud, the system can immediately switch to synchronization mode to ensure timely control. On the cloud side, the remote control service receives the status data reported by the vehicle and writes it to the vehicle status data center. The collaborative strategy manager generates control commands based on real-time status data and control execution feedback, which are then sent to the vehicle-side remote control command agent via the remote control service, thus forming a complete closed-loop collaborative control process from status perception and strategy adjustment to command execution and feedback.
[0075] like Figure 3 As shown, the system first continuously monitors and analyzes the current decision context, and dynamically matches three reporting strategies based on the vehicle's operating conditions: if the vehicle is determined to be in motion and the network signal is strong, the system adopts strategy P1 high-frequency polling mode to report all key states; if the vehicle is in a stable static / sleep state, the system switches to strategy P2 low-power heartbeat mode to report only connection keep-alive and summary information; if a sudden increase in the rate of change of key signals is detected, strategy P3 change trigger mode is immediately triggered to report the specific change signal.
[0076] In the cyclic monitoring phase after the strategy execution is completed, it is further determined whether a remote control command has been received. Once a command is received, regardless of the current reporting mode, it will be forcibly switched to the control synchronization mode to ensure the real-time performance and accuracy of remote control. If no command is received, it will return to the continued monitoring decision context.
[0077] like Figure 4As shown in the sequence diagram, this sequence diagram illustrates the collaborative interaction process between the cloud control service, the smart T-BOX, and the vehicle actuators after a user initiates a remote window-opening command via the app. The user app sends a command to the cloud, and the cloud sends a pre-verification control command to the smart T-BOX. Upon receiving the command, the T-BOX immediately interrupts the regular reporting mode and switches its state, then collects the current precise position of the window (e.g., 50%) and uploads it to the cloud. Based on the latest state, the cloud makes a final safety decision and issues a specific execution command (e.g., open to 80%). The T-BOX forwards the command to drive the vehicle actuators, and during execution, it tracks and reports process parameters such as motor current and position in real time. After the actuators complete their actions, the T-BOX reports the final result and status, the cloud sends a control success message back to the user app, and finally, the T-BOX reverts to its original adaptive reporting strategy.
[0078] Furthermore, embodiments of this application can define Quality of Service (QoS) levels for different status data. For example, battery level and GPS location are considered high QoS, requiring more reliable and potentially more frequent reporting; indoor light status is considered low QoS, only being reported in summary during changing or low-power modes. The policy engine dynamically adjusts the reporting priority and compression rate of each QoS level data based on real-time network bandwidth conditions.
[0079] As one possible approach, embodiments of this application can utilize cloud-based big data analysis of user behavior to predict remote control actions that users may initiate at specific times and locations (such as remotely starting the air conditioner before work). During the prediction window, the cloud can proactively send a "pre-synchronization" command to the T-BOX, enabling the T-BOX to switch to a reporting mode with higher readiness in advance, thereby achieving zero-latency state synchronization when the user's actual command arrives.
[0080] As one possible implementation, embodiments of this application can also pre-configure some core adaptive decision rules (such as "if the vehicle is turned off and parked within the GPS range of a home charging station, then enter deep energy-saving mode") in the T-BOX as a lightweight rule engine. Even in the extreme case of complete network outage, the T-BOX can still perform local intelligent policy management to ensure basic functions and energy saving.
[0081] Therefore, this application, through an adaptive strategy, is expected to reduce the average power consumption of T-BOX caused by status reporting by more than 60% and network traffic by more than 70% in scenarios such as vehicle stationary conditions, significantly reducing terminal power consumption and network load. By employing a pre-control state forced synchronization mechanism, it ensures that each control decision is based on the latest vehicle state, preventing control conflicts or dangerous operations caused by outdated states from the outset. This is expected to increase the first-time success rate of remote control by more than 15%, significantly improving the success rate and security of remote control. Furthermore, it breaks down the data barriers between status reporting and remote control, enabling the reporting strategy to proactively serve control needs, forming a highly efficient collaborative paradigm of "on-demand perception and precise control," achieving intelligent collaboration among subsystems. In addition, it possesses system-level self-optimization capabilities. Through a data feedback loop, the system can continuously learn and optimize strategy parameters, adapting to different vehicle models and user habits, making the system better with use.
[0082] According to the vehicle remote collaborative control method proposed in this application, feature information describing the current vehicle context state is constructed; a target reporting mode matching the feature information is selected from a variety of preset reporting modes, and status reporting is executed; upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud; during the execution of the remote control command, control process parameters of the actuator corresponding to the remote control command are continuously reported until a preset termination condition is met. This solves the problems of high power consumption and low network resource utilization of the vehicle terminal caused by fixed frequency or simple triggering in existing vehicle status reporting mechanisms, reduces power consumption, improves network efficiency, and enhances the real-time performance and success rate of remote control.
[0083] Next, the vehicle remote collaborative control device according to the embodiments of this application is described with reference to the accompanying drawings.
[0084] Figure 5 This is a block diagram of a vehicle remote collaborative control device according to an embodiment of this application.
[0085] like Figure 5 As shown, the vehicle remote collaborative control device 10 includes: an acquisition module 100, a matching module 200, a processing module 300, and a control module 400.
[0086] The system includes: an acquisition module 100, which acquires current vehicle operating data and cloud command data to construct feature information describing the current vehicle context state; a matching module 200, which selects a target reporting mode that matches the feature information from a set of preset reporting modes and performs status reporting based on the target reporting mode; a processing module 300, which interrupts the currently executing target reporting mode when a remote control command is received, collects the target status data corresponding to the remote control command, and uploads the target status data to the cloud; and a control module 400, which continuously reports the control process parameters of the actuator corresponding to the remote control command during the execution of the remote control command until a preset termination condition is met.
[0087] Furthermore, in some embodiments, the preset multiple reporting modes include: a first mode that sends full status data at a first reporting frequency; a second mode that sends partial status data at a second reporting frequency, wherein the second reporting frequency is less than the first reporting frequency; a third mode triggered in response to a preset signal transition in the signal bus; and a fourth mode triggered in response to a business event sent from the cloud.
[0088] Furthermore, in some embodiments, the matching module 200 is used to: determine whether the current vehicle speed is greater than a preset vehicle speed and whether the current network signal strength is higher than a preset signal threshold; and select a first reporting mode as the target reporting mode when the current vehicle speed is greater than the preset vehicle speed and the current network signal strength is higher than the preset signal threshold.
[0089] Furthermore, in some embodiments, the matching module 200 is used to: determine whether the current power setting is the off setting and whether the duration of the target signal changing frequency being zero is greater than a preset duration; if the current power setting is the off setting and the duration of the target signal changing frequency being zero is greater than the preset duration, select the second reporting mode as the target reporting mode.
[0090] Furthermore, in some embodiments, the matching module 200 is used to: determine whether any of the current vehicle's door lock signal, window position signal, or tire pressure signal has undergone a state transition; and if any of the current vehicle's door lock signal, window position signal, or tire pressure signal has undergone a state transition, select a third reporting mode as the target reporting mode.
[0091] Furthermore, in some embodiments, the feature information includes at least one of the following: vehicle power gear signal, vehicle speed signal, frequency of change of target signal, network signal strength, and status of pending instruction queue sent from the cloud. The control process parameters of the actuator include at least one of the following: drive motor current value, position sensor output value, percentage of travel, and fault code.
[0092] It should be noted that the foregoing explanation of the vehicle remote collaborative control method embodiment also applies to the vehicle remote collaborative control device of this embodiment, and will not be repeated here.
[0093] According to the vehicle remote collaborative control device proposed in this application, feature information describing the current vehicle context state is constructed; a target reporting mode matching the feature information is selected from a variety of preset reporting modes, and status reporting is executed; upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud; during the execution of the remote control command, control process parameters of the actuator corresponding to the remote control command are continuously reported until a preset termination condition is met. This solves the problems of high power consumption and low network resource utilization of the vehicle terminal caused by fixed frequency or simple triggering in existing vehicle status reporting mechanisms, reduces terminal energy consumption and network load, and improves the real-time performance and success rate of remote control.
[0094] Figure 6 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.
[0095] When the processor 602 executes the program, it implements the vehicle remote collaborative control method provided in the above embodiments.
[0096] Furthermore, the vehicle also includes: Communication interface 603 is used for communication between memory 601 and processor 602.
[0097] The memory 601 is used to store computer programs that can run on the processor 602.
[0098] The memory 601 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0099] If the memory 601, processor 602, and communication interface 603 are implemented independently, then the communication interface 603, memory 601, and processor 602 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0100] Optionally, in a specific implementation, if the memory 601, processor 602, and communication interface 603 are integrated on a single chip, then the memory 601, processor 602, and communication interface 603 can communicate with each other through an internal interface.
[0101] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.
[0102] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described vehicle remote cooperative control method.
[0103] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described vehicle remote collaborative control method.
[0104] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example 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.
[0105] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0106] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0107] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0108] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0109] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
[0110] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.
[0111] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.
Claims
1. A method for remote collaborative control of vehicles, characterized in that, Includes the following steps: Acquire current vehicle operating data and cloud command data, and construct feature information to describe the current vehicle context state; Select a target reporting mode that matches the feature information from a variety of preset reporting modes, and perform status reporting based on the target reporting mode; Upon receiving a remote control command, the currently executing target reporting mode is interrupted, target status data corresponding to the remote control command is collected, and the target status data is uploaded to the cloud. During the execution of the remote control command, the control process parameters of the actuator corresponding to the remote control command are continuously reported until the preset termination condition is met.
2. The method according to claim 1, characterized in that, The preset multiple reporting modes include: The first mode sends all status data at the first reporting frequency; A second mode in which partial status data is sent at a second reporting frequency, wherein the second reporting frequency is less than the first reporting frequency; The third mode is triggered in response to a preset signal transition in the signal bus; The fourth mode is triggered in response to business events issued from the cloud.
3. The method according to claim 1, characterized in that, The step of selecting a target reporting mode that matches the feature information from a set of preset reporting modes includes: Determine whether the current vehicle speed is greater than the preset vehicle speed and whether the current network signal strength is higher than the preset signal threshold; When the current vehicle speed is greater than the preset vehicle speed and the current network signal strength is higher than the preset signal threshold, the first reporting mode is selected as the target reporting mode.
4. The method according to claim 1, characterized in that, The step of selecting a target reporting mode that matches the feature information from a set of preset reporting modes further includes: Determine whether the current power setting is the off position and whether the duration of the target signal's change frequency being zero is greater than the preset duration; If the current power setting is the off position and the duration of the target signal changing at a frequency of zero is greater than the preset duration, then the second reporting mode is selected as the target reporting mode.
5. The method according to claim 1, characterized in that, The step of selecting a target reporting mode that matches the feature information from a set of preset reporting modes further includes: Determine whether any of the following signals of the current vehicle—door lock signal, window position signal, or tire pressure signal—has undergone a state transition; If any of the current vehicle's door lock signal, window position signal, or tire pressure signal undergoes a state change, the third reporting mode is selected as the target reporting mode.
6. The method according to claim 1, characterized in that, The characteristic information includes at least one of the following: vehicle power gear signal, vehicle speed signal, target signal change frequency, network signal strength, and pending instruction queue status sent from the cloud. The control process parameters of the actuator include at least one of the following: drive motor current value, position sensor output value, percentage of travel, and fault code.
7. A vehicle remote collaborative control device, characterized in that, include: The acquisition module is used to acquire the current vehicle's operating data and cloud command data, and to construct feature information to describe the current vehicle's context state. The matching module is used to select a target reporting mode that matches the feature information from a variety of preset reporting modes, and to perform status reporting based on the target reporting mode; The processing module is used to interrupt the target reporting mode that is being executed when a remote control command is received, collect the target status data corresponding to the remote control command, and upload the target status data to the cloud. The control module is used to continuously report the control process parameters of the actuator corresponding to the remote control command during the execution of the remote control command until the preset termination condition is met.
8. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and capable of running on the processor, the processor executing the computer program to implement the vehicle remote cooperative control method as described in any one of claims 1-6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is executed by a processor to implement the vehicle remote cooperative control method as described in any one of claims 1-6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle remote cooperative control method as described in any one of claims 1-6.