WO2025161731A1 - Vehicle remote control method and apparatus, server, vehicle, and storage medium - Google Patents

Abstract

The present application provides a vehicle remote control method and apparatus, a server, a vehicle, and a storage medium. The method comprises: a server receiving a vehicle control request sent by a user terminal device; on the basis of the state of a MQTT connection with a target vehicle corresponding to a target vehicle identifier, determining a connection state of the target vehicle, wherein when the state of the MQTT connection is a connected state, the target vehicle is determined to be online, and when the state of the MQTT connection is a disconnected state, the target vehicle is determined to be offline; if the target vehicle is offline, sending a short messaging service (SMS) to wake up the target vehicle; and when the target vehicle is woken up, establishing a MQTT connection with the server, and by means of a MQTT, the server sending a control instruction to the target vehicle for execution. By means of the present method, the loss of a quiescent current on a vehicle side can be reduced to avoid the loss of power caused when a vehicle remains in a wake-up state for a long time, thereby prolonging the service life of a battery; in addition, the method can be applicable to a variety of network environments by means of SMS and MQTT integration.

Description

Vehicle remote control method, device, server, vehicle and storage medium

This application claims priority to the Chinese patent application filed with the China Patent Office on January 29, 2024, with application number 202410122783.4 and application name “Method and Device for Remote Control of Vehicle”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to vehicle communication technology, and in particular to a method, device, server, vehicle and storage medium for remote control of a vehicle.

Background Art

With the development of the Internet of Vehicles and mobile Internet, users' demand for the Internet of Vehicles is no longer limited to the use of vehicle-side products and services. The demand for the interconnection between mobile phones and vehicle-side is also increasing. Remote control of vehicle-side services through mobile phone applications, such as remote unlocking and remote air conditioning, has brought great convenience to customers' car use.

Message Queuing Telemetry Transport (MQTT), a technology for the next-generation Internet of Vehicles (IoV), features low latency and a high success rate. However, the intelligent vehicle communication terminal (Traffic Control and Monitoring Module, TCAM) based on MQTT will remain awake for a long time, significantly increasing its quiescent current consumption and impacting the battery life.

Therefore, how to improve the service life of vehicle batteries without affecting the user's vehicle control experience is an urgent problem to be solved.

Summary of the Invention

The present application provides a method, device, server, vehicle and storage medium for remote control of a vehicle, which are used to solve the problem of service life of vehicle batteries.

In a first aspect, the present application provides a method for remotely controlling a vehicle, applied to a server, the method comprising:

Receiving a vehicle control request sent by a user terminal device, wherein the vehicle control request includes a target vehicle identifier and a control instruction;

Determining a connection status of the target vehicle according to a status of a message queue telemetry transmission protocol MQTT connection between the target vehicle corresponding to the target vehicle identifier, wherein the target vehicle is determined to be online when the status of the MQTT connection is connected, and the target vehicle is determined to be offline when the status of the MQTT connection is disconnected;

If the target vehicle is offline, sending a text message SMS to wake up the target vehicle;

After the target vehicle is awakened, the control instruction is sent to the target vehicle via MQTT.

Optionally, the method further includes:

Acquire the current time in real time, and determine whether the current time is within a preset connection time period corresponding to the target vehicle identifier;

If the current time is not within the preset connection time period, disconnect the MQTT connection with the target vehicle;

If the current time is within the preset connection time period, an MQTT connection is established with the target vehicle.

Optionally, the method further includes:

If it is detected that the target vehicle is turned off for longer than a preset time, the MQTT connection with the target vehicle is disconnected.

Optionally, the connection time periods corresponding to vehicles of different energy types are different, and the energy types include pure electric type and non-pure electric type.

In a second aspect, the present application further provides a vehicle remote control method, applied to a vehicle, the method comprising:

Receive a text message SMS sent by a server, where the SMS is used to wake up the vehicle;

Wake up the main control chip SOC and the communication module, and establish a message queue telemetry transmission protocol MQTT connection with the server through the communication module;

Receive the control instruction sent by the server via MQTT and execute the control instruction.

Optionally, the energy type of the vehicle includes a pure electric type and a non-pure electric type;

Accordingly, the method further includes:

If the vehicle is a pure electric vehicle, the MQTT connection is maintained with the server through the communication module, and the SOC is placed in a dormant state;

If the vehicle is not a pure electric type, the MQTT connection with the server is maintained through the communication module within a preset connection time period, and the SOC is placed in a sleep state. Outside the preset connection time period, the MQTT connection between the communication module and the server is disconnected.

Optionally, the method includes:

If a control instruction sent by a cloud server is received while the vehicle maintains an MQTT connection with the server, determining whether the SOC is in a dormant state;

If the SOC is in a dormant state, the SOC is awakened, and the control instruction is sent to the SOC for execution.

Optionally, the method further includes:

obtaining the temperature and remaining battery power of the vehicle;

If the temperature is lower than a preset temperature value or the remaining battery power is lower than a preset power value, the MQTT connection with the server is disconnected.

In a third aspect, the present application further provides a vehicle remote control device, the device comprising:

A receiving module, configured to receive a vehicle control request sent by a user terminal device, wherein the vehicle control request includes a target vehicle identifier and a control instruction;

a judgment module, configured to determine a connection status of the target vehicle according to a status of a message queue telemetry transmission protocol MQTT connection between the target vehicle corresponding to the target vehicle identifier, wherein the target vehicle is determined to be online when the status of the MQTT connection is connected, and the target vehicle is determined to be offline when the status of the MQTT connection is disconnected;

A first sending module is used to send a text message SMS to wake up the target vehicle if the target vehicle is offline;

The second sending module is used to send the control instruction to the target vehicle through MQTT after the target vehicle is awakened.

In a fourth aspect, the present application further provides a vehicle remote control device, the device comprising:

A receiving module receives a short message SMS sent by a server, wherein the SMS is used to wake up the vehicle;

A wake-up module is used to wake up the main control chip SOC and the communication module, and establish a message queue telemetry transmission protocol MQTT connection with the server through the communication module;

The execution module is used to receive the control instruction sent by the server through MQTT and execute the control instruction.

In a fifth aspect, the present application further provides a server, comprising:

A processor, a memory connected to the processor, and a communication interface for interacting with other devices, wherein the processor is used to execute the vehicle remote control method described in any one of the first aspects.

In a sixth aspect, the present application further provides a vehicle, comprising a vehicle body and a controller;

The controller is used to execute the vehicle remote control method described in any one of the second aspects.

In the seventh aspect, the present application also provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the vehicle remote control method as described in any one of the first aspect or the second aspect.

In an eighth aspect, the present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the vehicle remote control method as described in any one of the first aspect or the second aspect.

The present application provides a method, device, server, vehicle and storage medium for remote control of a vehicle, the method comprising: a server receiving a request for controlling a vehicle sent by a user terminal device; determining the connection status of the target vehicle based on the status of the MQTT connection between the target vehicle and the target vehicle identifier, wherein the target vehicle is determined to be online when the MQTT connection status is connected, and is determined to be offline when the MQTT connection status is disconnected; if the target vehicle is offline, sending an SMS message (SMS) to wake up the target vehicle; after the target vehicle is woken up, an MQTT connection is established with the server, and the server sends the control instruction to the target vehicle via MQTT for execution. This method can reduce the loss of static current on the vehicle side, avoid power loss when the vehicle is awake for a long time, and thus improve battery life. In addition, SMS and MQTT can be applied to a variety of network environments.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

FIG1 is a schematic diagram of an application scenario of the present application;

FIG2 is a flow chart of a first embodiment of a method for remotely controlling a vehicle provided by the present application;

FIG3 is a flow chart of a second embodiment of a method for remotely controlling a vehicle provided by the present application;

FIG4 is a flow chart of a third embodiment of the vehicle remote control method provided by the present application;

FIG5 is a flow chart of a fourth embodiment of a method for remotely controlling a vehicle provided by the present application;

FIG6 is a schematic structural diagram of a first embodiment of a vehicle remote control device provided by the present application;

FIG7 is a schematic structural diagram of a second embodiment of a vehicle remote control device provided by the present application;

FIG8 is a schematic diagram of the structure of a server provided in this application.

The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments.

DETAILED DESCRIPTION

Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

First, let’s explain the terms involved in this application:

Message Queuing Telemetry Transport (MQTT): uses a publish/subscribe-based communication model in which devices can publish (send) messages and subscribe (receive) topics of interest. It usually has low latency and is suitable for application scenarios that require high real-time performance.

Short Messaging Service (SMS): In this application, it refers to the use of SMS service to send text messages directly to the vehicle through the mobile network base station.

Telematics Service Provider (TSP): Responsible for providing remote vehicle services such as remote monitoring and remote control. Through the TSP, users can remotely manage vehicle functions such as vehicle positioning and remote unlocking.

Telematics Communication Access Module (TCAM): acts as the communication hub between the vehicle and the Internet of Vehicles service platform, responsible for handling communication-related tasks, including receiving instructions from the TSP and passing them to other control modules inside the vehicle.

Currently, nearly all mainstream car models support remote control of vehicle-side services via mobile phone, bringing significant convenience to customers. The data link used by users to activate vehicle-side services via mobile applications (APPs) is long, spanning the APP, TSP, TCAM, the in-vehicle data exchange gateway (BGM), and the onboard electronic controller, spanning the mobile phone, cloud, and vehicle systems. The TCAM is a key node responsible for vehicle-cloud communication.

The current mainstream method generally uses SMS wake-up mode, which is a traditional SMS technology solution. After the vehicle is dormant, when the app issues a remote vehicle control command, the TSP side wakes up the vehicle's TCAM through the operator's SMS message. After waking up, the TCAM completes the network and sends the command to the vehicle. After the vehicle completes a series of operations, the execution results are fed back to the app. Another method is to use a car networking solution based on MQTT technology (commonly known as a long connection method) to achieve vehicle-to-vehicle connection and control services in pure electric and extended-range vehicles.

As a technology for the next-generation Internet of Vehicles, MQTT technology features low latency and high success rate. However, compared to SMS solutions, MQTT technology has certain disadvantages in weak network environments (such as underground garages). At the same time, in the MQTT technology solution, the vehicle-side TCAM will be in an awake state for a long time, so its static current consumption will be significantly increased, which will have a certain impact on the frequency of intelligent charging, the static calibration of the BMS, the battery life, and the locking time in the absence of charging.

In light of the above issues, the inventors discovered during their research in this field that a solution that integrates MQTT and SMS could be used. During periods when the user frequently uses the vehicle, the vehicle connects to the server and sends control commands via MQTT. During periods when the vehicle is not frequently used, the vehicle is disconnected from the server. When remote control of the vehicle is required, commands are sent via SMS, thereby extending the service life of the vehicle battery. Based on this, the present application proposes a method, apparatus, server, vehicle, and storage medium for remote vehicle control.

Figure 1 is a schematic diagram of the application scenario of this application, which includes three major systems: terminal devices, cloud servers, and vehicle-side systems. The application on the user terminal device connects to the cloud server, and the cloud server establishes a connection with the vehicle-side system to complete the issuance of user remote commands. In this application scenario, mobile phones, tablets, and smart wearable devices are all terminal devices. The vehicle side is not limited to any type of vehicle, but must be able to communicate with the server.

The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

FIG2 is a flow chart of a first embodiment of a method for remotely controlling a vehicle provided by the present application. As shown in FIG2 , the method includes the following steps:

S101. A user terminal device sends a vehicle control request, where the vehicle control request includes a target vehicle identifier and a control instruction.

In this step, the user operates in the vehicle manufacturer's APP in the terminal device and sends a remote vehicle control request. The vehicle control request includes the target vehicle identification and control instructions to be controlled, such as remote unlocking/locking, remote opening of the sunroof, remote opening of the air conditioner, remote seat heating, checking tire pressure, checking driving logs, and other operations.

S102: The server receives a vehicle control request sent by a user terminal device.

S103. Determine the connection status of the target vehicle according to the status of the MQTT connection between the target vehicle and the target vehicle identifier, wherein the target vehicle is determined to be online when the MQTT connection status is connected, and the target vehicle is determined to be offline when the MQTT connection status is disconnected.

In this step, the cloud server connects to each vehicle and displays its connection status. If the connection status is disconnected, it means the vehicle is offline. The MQTT connection status can be changed by the server or the vehicle.

In one implementation, the server periodically sends a heartbeat message to the target vehicle. If the server does not receive a response from the target vehicle within a certain period of time, it can determine that the target vehicle's MQTT connection status is disconnected. If the vehicle is displayed as offline, it can send another heartbeat message to confirm that the target vehicle is offline when a control request is received.

In one implementation, the MQTT protocol allows the client to use a persistent session identifier when establishing a connection. The server can record the persistent session identifiers of each target vehicle and check their status to determine whether the connection still exists.

In one implementation, a last wish message is a message sent by a vehicle when the connection is disconnected. The server can learn the connection status of the target vehicle when it subscribes to the last wish topic of the target vehicle.

In one implementation, the target vehicle can periodically publish its own status information to a specific MQTT topic, and the server subscribes to this topic to understand the connection status of the target vehicle.

In one implementation, the server may obtain the latest status of the target vehicle by subscribing to a retention message. If no retention message is received, the server may determine that the connection status is disconnected.

If the target vehicle is online, execute step 107 .

S104: If the target vehicle is offline, send a text message SMS to wake up the target vehicle.

In this step, the target vehicle may be offline due to active disconnection or poor network, making it impossible to send control instructions via MQTT. Therefore, the vehicle needs to be woken up first. The SMS method has strong adaptability to weak networks, so the server wakes up the vehicle via SMS.

Specifically, the server system prepares an SMS message containing specific instructions in advance, including a command to wake up the target vehicle. The server sends the SMS message to the SIM card of the target vehicle via a mobile network through an SMS gateway or SMS service provider.

It should be noted that the vehicle is offline based on the time slice scheduling strategy, that is, during the non-preset connection time period, the vehicle remains offline unless it is woken up by SMS.

S105. The vehicle receives the SMS message sent by the server.

In this step, the target vehicle receives a text message sent via SMS and parses the instruction content in the text message, which is usually a wake-up instruction, to perform subsequent operations.

S106 , waking up the main control chip SOC and the communication module, and establishing an MQTT connection with the server through the communication module.

In this step, the vehicle wakes up the TCAM's system-on-chip (SoC) and the communication module according to the wake-up command in the SMS. Once the vehicle wakes up (and the TCAM wakes up), the communication module establishes an MQTT connection with the server over the mobile network for subsequent communication.

S107. The server sends the control instruction to the target vehicle via MQTT.

In this step, when the server detects that the target vehicle's connection status has become online, it sends the control command to the target vehicle via MQTT.

S108. The target vehicle receives the control instruction sent by the server via MQTT and executes the control instruction.

In this step, the target vehicle forwards the control instructions sent by the communication module server through MQTT to the in-vehicle data interaction gateway (BGM), and the BGM then forwards the instructions to the electronic control unit of the corresponding function for execution.

In one case, the target vehicle on the server side is online, that is, the target vehicle maintains an MQTT connection with the server, but the main control chip SOC in the TCAM is put into a sleep state to reduce power loss. After receiving the control instruction, the SOC is awakened and the control instruction is forwarded to the electronic control unit of the corresponding function.

Optionally, after executing the control instruction, if no other messages sent via MQTT are received within a preset time period and the vehicle is in a non-preset connection time period, the MQTT connection is actively disconnected, putting the vehicle offline.

This embodiment provides a method for remote control of a vehicle, wherein a server receives a request for controlling a vehicle sent by a user terminal device; the connection status of the target vehicle is determined based on the status of the MQTT connection between the target vehicle and the target vehicle identifier, wherein the target vehicle is determined to be online when the MQTT connection status is connected, and the target vehicle is determined to be offline when the MQTT connection status is disconnected; if the target vehicle is offline, a text message SMS is sent to wake up the target vehicle; after the target vehicle is woken up, an MQTT connection is established with the server, and the server sends the control instruction to the target vehicle via MQTT for execution. This method can reduce the loss of static current on the vehicle side, avoid power loss when the vehicle is awake for a long time, and thus improve battery life. In addition, SMS and MQTT can be applied to a variety of network environments.

FIG3 is a flow chart of a second embodiment of the method for remotely controlling a vehicle provided by the present application. As shown in FIG3 , based on the above-mentioned first embodiment, after the control instruction is executed on the vehicle side, the following steps are further included:

S109. The target vehicle returns the command execution result to the server via MQTT.

In this step, the target vehicle generates a command execution result, which indicates the execution status of the command, such as success, failure, or other specific status information. The command execution result is packaged into a message via MQTT and published to the result topic that the server has subscribed to in advance.

S110. The server returns the command execution result to the user's terminal device via MQTT.

In this step, the server subscribes to the result topic associated with the target vehicle via MQTT and receives the command execution results returned by the target vehicle. The server generates a corresponding result message, including the execution status and possible detailed information, and sends the generated result message via MQTT to the topic subscribed by the user terminal device, or sends the command execution results to the topic subscribed by the user terminal device.

S111. The terminal device displays the execution result.

In this step, the user's terminal device subscribes to the topic related to the target vehicle through MQTT, so it can receive the command execution result message sent by the server.

This embodiment returns the execution results from the vehicle to the user's terminal device via MQTT, which has low latency and high success rate, and reduces the possibility of message sending failures due to network connection problems.

FIG4 is a flow chart of a third embodiment of the vehicle remote control method provided by the present application. As shown in FIG4 , the server side further includes the following steps:

S201. Obtain the current time in real time.

In this step, the server side pre-sets the time-sharing scheduling strategy, that is, sets a preset connection time period. During the preset connection time period, the server establishes an MQTT connection with the vehicle. The preset time period can be set to different time periods as needed. For example, the time period from 6:00 to 22:00 when users frequently use the car is the preset time period, and the time period from 22:00 to 6:00 the next day when users do not frequently use the car is the non-preset time period. The time-sharing adjustment strategy can also be set according to the different energy types of the vehicle (such as BEV\PHEV\extended range), different battery types (lithium battery/lead-acid battery), different vehicle types, and ambient temperature types. It also supports user-defined settings.

In a possible implementation, the cloud server divides the time periods when the car is frequently used as preset time periods and the other time periods as non-preset time periods based on the user's car usage history data.

For example, for a pure electric vehicle, the preset time period is 24 hours a day. The vehicle's communication module maintains an MQTT connection with the cloud server, maintaining a heartbeat. From 6:00 AM to 10:00 PM, the vehicle wakes up the TCAM every 10 minutes. That is, the TCAM's main control chip and microprocessor are in a dormant state. The vehicle wakes up once every preset time period and maintains the preset time after waking up. From 10:00 PM to 6:00 AM the next day, the TCAM wakes up every 60 minutes.

For non-pure electric vehicles, the preset time period is set from 6:00 to 22:00. During the preset time period, the vehicle's communication module and the cloud server remain in an MQTT connection state, and the heartbeat is maintained; during the non-preset time period, the vehicle's communication module and the cloud server's long connection is disconnected, and only SMS communication with the vehicle is supported.

S202: If it is detected that the target vehicle has been turned off for longer than a preset time, disconnect the MQTT connection with the target vehicle.

In this step, the server records the target vehicle's start-up and shutdown times. Based on the current time and the target vehicle's shutdown time, the shutdown time is determined. If the shutdown time exceeds a preset duration—for example, more than 14 days since the last vehicle start (i.e., the shutdown duration)—the user has no plans to use the vehicle within that timeframe, the connection to the target vehicle is disconnected, and the time-sharing scheduling strategy is no longer implemented to reduce power consumption. However, this does not affect vehicle wake-up via SMS.

The preset duration can be adjusted as needed. It differs between pure electric and non-pure electric vehicles. For example, the preset duration for pure electric vehicles is 14 days, while the preset duration for non-pure electric vehicles is 7 days. Non-pure electric vehicles have smaller battery capacities, so the preset duration is shorter than that for pure electric vehicles.

If it is detected that the target vehicle's shutdown time does not exceed the preset time, the subsequent time-sharing adjustment strategy is executed.

S203: Determine whether the current moment is within a preset connection time period corresponding to the target vehicle identifier.

In this step, the current time, acquired in real time, is used to determine whether the target vehicle is within the preset connection time period corresponding to the target vehicle ID. Each vehicle participating in the time-sharing scheduling strategy has a different preset connection time period. Therefore, the current time is used to determine whether the target vehicle is within the corresponding preset connection time period.

If the current time is not within the preset connection time period, step S204 is executed.

If the current time is within the preset connection time period, step S205 is executed.

S204: Disconnect the MQTT connection with the target vehicle.

In this step, if the current time is not within the preset connection time period, the server will actively disconnect the MQTT connection with the target vehicle. The TCAM of the target vehicle will be in a dormant state after the preset offline time.

S205: Establish an MQTT connection with the target vehicle.

In this step, if the current moment is within the preset connection time period, the MQTT connection status with the target vehicle is detected. When the target vehicle is online, there is no need to establish a connection. When the target vehicle is offline, an MQTT connection with the target vehicle is established.

In one possible implementation, both the vehicle side and the server side store a preset connection time period. When the preset time period is reached, the vehicle side wakes up the communication module of the TCAM, and the server and the communication module can establish an MQTT connection.

In another possible implementation, when a preset time period is reached, the server sends an SMS message to the vehicle to activate the vehicle TCAM and establish an MQTT connection with the vehicle TCAM.

In this embodiment, the server side sets the MQTT connection time period with each vehicle through a time-sharing scheduling strategy. The time-sharing scheduling strategy can be set according to the vehicle energy type or user historical behavior data. If the current moment does not belong to the preset connection time period, the MQTT connection with the vehicle is disconnected. If the current moment belongs to the preset connection time period, the MQTT connection with the vehicle is established. Moreover, if the vehicle's ignition is turned off for more than the preset duration, the MQTT connection with the target vehicle is disconnected and the time-sharing adjustment strategy is no longer executed. The time-sharing modulation strategy allows for flexible scheduling that conforms to user behavior, reduces static current loss, and improves battery life without affecting the user's vehicle control experience. This improves the adaptability of different vehicle types to achieve the optimal vehicle control optimization solution under the hardware conditions of different vehicle categories.

The following is an example of an example of steps that the vehicle needs to perform when adopting the time-sharing adjustment strategy:

If the vehicle is a pure electric type, the MQTT connection with the server is maintained through the communication module, and the SOC is put into sleep mode.

Among them, the preset connection time period for pure electric vehicles is set to all day, that is, the MQTT connection is maintained with the server through the communication module, and the heartbeat is maintained, but in order to save power, other components in the vehicle need to be put into sleep mode. Specifically, after the vehicle communication module is started, it sends authentication information, and the server establishes an MQTT connection with the vehicle communication module after verifying the identity information. The communication module subscribes to topics related to the target vehicle so that it can receive instructions from the server. The SOC (main control chip) performs preparatory work, such as saving the current state and shutting down unnecessary modules or peripherals in order to enter the sleep state; the communication module sends a command or signal to notify the SOC to enter the sleep state; the SOC shuts down the main processor and other unnecessary power-consuming modules according to the instructions of the communication module. While the SOC is in sleep mode, the communication module continues to maintain the MQTT connection, and the heartbeat mechanism is used between the device and the server to ensure that the connection remains active. The server side shows that the vehicle is online. When the server has instructions to send to the target vehicle, it is sent to the communication module via MQTT messages. After the communication module receives the instruction from the server, it needs to detect whether the SOC is in a dormant state. Therefore, it will wake up once at a fixed time after the SCO goes into dormancy and maintain the preset duration, for example, waking up once every 10 minutes and maintaining it for one minute. When the SOC is in a dormant state, the communication module sends a wake-up signal to the SOC so that the SOC wakes up from the dormant state. After the SOC is awakened, it processes the received instruction and forwards the instruction to the corresponding execution module. When the SOC is not in a dormant state, the control instruction is sent to the SOC. After the SOC executes the instruction, the communication module sends the instruction execution result to the server through MQTT, including the execution status and related information. After the SOC completes instruction processing, it maintains the preset time and continues to remain in the dormant state if no other instructions are issued.

This method can ensure that while the SOC is in sleep mode, the MQTT connection with the server is maintained through the communication module, so that remote commands can be issued and execution results can be returned.

If the vehicle is not a pure electric type, the MQTT connection with the server is maintained through the communication module during the preset connection time period, and the SOC is put into a dormant state. Outside the preset connection time period, the MQTT connection between the communication module and the server is disconnected.

Among them, if the vehicle is not a pure electric type, the process is the same as that of the pure electric type within the preset connection time period, but outside the preset connection time period, the MQTT between the vehicle and the server will also be disconnected, and the communication module will enter a dormant state, further reducing power consumption.

FIG5 is a flow chart of a fourth embodiment of the method for remotely controlling a vehicle provided by the present application. As shown in FIG5 , the vehicle side further includes the following steps:

S301: Obtain the vehicle's temperature and remaining battery power.

In this step, the vehicle initiates an operation to obtain vehicle information based on certain trigger conditions, such as timing, event triggering, or request. Vehicle information includes the current vehicle temperature and remaining battery power. The vehicle's internal temperature sensors and battery management module obtain the vehicle's ambient temperature and remaining battery power.

S302: If the temperature is lower than a preset temperature value or the remaining battery power is lower than a preset power value, disconnect the MQTT connection with the server.

In this step, when the temperature around the vehicle is lower than the preset temperature value, it means that the vehicle is in a low-temperature state. The consumption of static current at low temperatures will affect the battery life. Therefore, it is necessary to disconnect the MQTT connection with the server and put the main control chip, processor and other devices into sleep mode.

When the battery level is lower than the preset value, the MQTT connection with the server needs to be disconnected, and the main control chip, processor and other devices need to be put into sleep mode.

The preset temperature value and the preset power value can be set as needed. For example, in non-pure electric vehicles, it is set that when the temperature is below -18°C or when the power battery SOC is below 20%, the MQTT connection with the server will be disconnected; in pure electric vehicles, it is set that when the temperature is below -18°C or when the power battery SOC is below 10%, the MQTT connection with the server will be disconnected. It should be understood that the preset temperature value and preset power value of different vehicles can be set according to the vehicle conditions. Different battery types have different decay cycles, so the preset power value can be set to different power levels.

In either of the above two situations, the vehicle side actively disconnects the MQTT connection. The server side can still wake up the vehicle through SMS to establish a connection. After the connection is established, it still needs to be disconnected when there is no communication data.

The following example illustrates how to issue commands while maintaining a long MQTT connection.

Taking vehicle unlocking as an example, in actual scenarios, the vehicle-side TCAM and the cloud-side TSP maintain a long connection through the MQTT protocol. When the user sends an unlock command through the APP, the TSP forwards the unlock command to the TCAM through an MQTT message after receiving the unlock command. After waking up the SOC, the TCAM addresses the ECU through the in-vehicle data interaction gateway BGM, and forwards the command to the body domain controller ECU through the vehicle network to complete the door unlocking. After the body domain controller executes successfully, the direct result is returned to the TCAM through the BGM, and the TCAM returns it to the TSP. The TSP returns the result code of the command execution to the APP. The APP prompts the APP side that the vehicle has been unlocked based on the returned result code. At the same time, the car model status changes to unlocked, and the unlock switch changes from closed to unlocked.

Based on any of the above embodiments, dial-up can be used instead of SMS, combining dial-up with MQTT technology. That is, when the vehicle is offline, dial-up can be used to wake up the vehicle, and after waking up, the vehicle establishes an MQTT connection with the server. This method allows for faster message delivery and more stable connections even under unstable network conditions.

Based on any of the above embodiments, a private TCP protocol can be integrated with an SMS solution to facilitate massive message communication across millions of vehicle computers. The private TCP protocol provides more refined control and more efficient communication. Specifically, the server establishes a connection with the vehicle module via the private TCP protocol, and the vehicle's communication module receives instructions from the server via the private TCP protocol. Even when the vehicle is offline, SMS can still be used to wake it up. After waking up, the vehicle establishes a TCP connection with the server.

FIG6 is a schematic structural diagram of a first embodiment of a vehicle remote control device provided by the present application. As shown in FIG6 , the device 600 includes:

A receiving module 611 is configured to receive a vehicle control request sent by a user terminal device, wherein the vehicle control request includes a target vehicle identifier and a control instruction;

a determination module 612 for determining a connection status of the target vehicle based on a status of a message queue telemetry transmission protocol MQTT connection between the target vehicle and the target vehicle identifier, wherein the target vehicle is determined to be online when the MQTT connection status is connected, and is determined to be offline when the MQTT connection status is disconnected;

The first sending module 613 is used to send a text message SMS to wake up the target vehicle if the target vehicle is offline;

The second sending module 614 is configured to send the control instruction to the target vehicle via MQTT after the target vehicle is awakened.

Optionally, the device further includes an acquisition module and a control module:

The acquisition module is used to acquire the current time in real time and determine whether the current time is within the preset connection time period corresponding to the target vehicle identifier;

The control module is used for:

If the current time is not within the preset connection time period, disconnect the MQTT connection with the target vehicle;

If the current time is within the preset connection time period, an MQTT connection is established with the target vehicle.

Optionally, the control module is further configured to:

If it is detected that the target vehicle is turned off for longer than a preset time, the MQTT connection with the target vehicle is disconnected.

Optionally, the connection time periods corresponding to vehicles of different energy types are different, and the energy types include pure electric type and non-pure electric type.

The vehicle remote control device provided in the embodiment of the present application is used to implement the vehicle remote control method described in any one of the server side embodiments of the aforementioned method. Its implementation principle and technical effects are similar and will not be described in detail here.

On the server side, the server is divided into three modules: the cloud service module handles the interaction with the terminal device, the policy engine module is responsible for managing the vehicle's time-sharing scheduling strategy, and the MQTT service provider (Broker) is responsible for maintaining communication with the vehicle end.

FIG7 is a schematic diagram of the structure of a second embodiment of a vehicle remote control device provided by the present application. As shown in FIG7 , the device includes:

Receiving module 711, receiving SMS messages sent by the server, the SMS being used to wake up the vehicle;

A wake-up module 712 is used to wake up the main control chip SOC and the communication module, and establish a message queue telemetry transmission protocol MQTT connection with the server through the communication module;

The execution module 713 is configured to receive the control instruction sent by the server via MQTT and execute the control instruction.

Optionally, the energy type of the vehicle includes a pure electric type and a non-pure electric type;

Accordingly, the apparatus further includes a control module 714, and the control module 714 is configured to:

If the vehicle is a pure electric vehicle, the MQTT connection is maintained with the server through the communication module, and the SOC is placed in a dormant state;

If the vehicle is not a pure electric type, the MQTT connection with the server is maintained through the communication module within a preset connection time period, and the SOC is placed in a sleep state. Outside the preset connection time period, the MQTT connection between the communication module and the server is disconnected.

The control module 714 is further configured to:

If a control instruction sent by a cloud server is received while the vehicle maintains an MQTT connection with the server, determining whether the SOC is in a dormant state;

If the SOC is in a dormant state, the SOC is awakened, and the control instruction is sent to the SOC for execution.

Optionally, the device further includes an acquisition module, the acquisition module being configured to acquire the temperature and remaining battery power of the vehicle;

The control module 714 is further configured to disconnect the MQTT connection with the server if the temperature is lower than a preset temperature value or the remaining battery power is lower than a preset power value.

The vehicle remote control device provided in the embodiment of the present application is used to implement any vehicle remote control method on the vehicle side in the aforementioned method embodiments. Its implementation principle and technical effects are similar and will not be described in detail here.

FIG8 is a schematic diagram of the structure of a server provided by the present application. As shown in FIG8 , the server 800 includes:

A processor 811, a memory 812 in communication with the processor, and a communication interface 813 for interacting with other devices;

The memory 812 stores computer-executable instructions;

The processor 811 executes the computer-executable instructions stored in the memory to implement the vehicle remote control method described in any one of the above-mentioned server-side method embodiments.

Optionally, the above-mentioned components of the server 800 may be connected via a system bus.

The memory 812 may be a separate storage unit or a storage unit integrated in the processor 811. The number of the processor 811 may be one or more.

It should be understood that the processor 811 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented as being executed by a hardware processor, or by a combination of hardware and software modules in the processor.

The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. System buses can be divided into address buses, data buses, and control buses. For ease of illustration, the diagram uses a single thick line, but this does not imply a single bus or type of bus. Memory may include random access memory (RAM) and non-volatile memory (NVM), such as at least one disk drive.

All or part of the steps of the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above-mentioned method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disc, and any combination thereof.

The server provided in the embodiment of the present application is used to implement the vehicle remote control method described in any of the aforementioned method embodiments. Its implementation principle and technical effects are similar and will not be described in detail here.

An embodiment of the present application further provides a vehicle, the vehicle comprising a vehicle body and a controller;

The controller includes: a processor, a memory connected to the processor, and a communication module;

The processor executes the computer-executable instructions stored in the memory to implement the vehicle remote control method described in any of the above-mentioned vehicle-side method embodiments.

The vehicle also includes a temperature sensor that senses the ambient temperature of the vehicle and transmits the sensed temperature to the processor via the vehicle network.

The vehicle provided in the embodiment of the present application is used to implement the method of vehicle remote control described in any one of the vehicle side embodiments of the aforementioned method. Its implementation principle and technical effects are similar and will not be described in detail here.

The present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the equity data processing method as described in any one of the aforementioned method embodiments.

The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the vehicle remote control method as described in any one of the first aspect or the second aspect.

It is understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct RAMbus RAM (DR RAM). It should be noted that references to memory above are intended to include, but are not limited to, these and any other suitable types of memory.

Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims (14)

A vehicle remote control method, characterized in that it is applied to a server and comprises: Receiving a vehicle control request sent by a user terminal device, wherein the vehicle control request includes a target vehicle identifier and a control instruction; Determining a connection status of the target vehicle according to a status of a message queue telemetry transmission protocol MQTT connection between the target vehicle corresponding to the target vehicle identifier, wherein the target vehicle is determined to be online when the status of the MQTT connection is connected, and the target vehicle is determined to be offline when the status of the MQTT connection is disconnected; If the target vehicle is offline, sending a text message SMS to wake up the target vehicle; After the target vehicle is awakened, the control instruction is sent to the target vehicle via MQTT. The method according to claim 1, further comprising: Acquire the current time in real time, and determine whether the current time is within a preset connection time period corresponding to the target vehicle identifier; If the current time is not within the preset connection time period, disconnect the MQTT connection with the target vehicle; If the current time is within the preset connection time period, an MQTT connection is established with the target vehicle. The method according to claim 1 or 2, characterized in that the method further comprises: If it is detected that the target vehicle is turned off for longer than a preset time, the MQTT connection with the target vehicle is disconnected. The method according to claim 2 is characterized in that the preset connection time periods corresponding to vehicles of different energy types are different, and the energy types include pure electric types and non-pure electric types. A vehicle remote control method, characterized in that it is applied to a vehicle, the method comprising: Receive a text message SMS sent by a server, where the SMS is used to wake up the vehicle; Wake up the main control chip SOC and the communication module, and establish a message queue telemetry transmission protocol MQTT connection with the server through the communication module; Receive the control instruction sent by the server via MQTT and execute the control instruction. The method according to claim 5, wherein the energy type of the vehicle includes a pure electric type and a non-pure electric type; Accordingly, the method further includes: If the vehicle is a pure electric vehicle, the MQTT connection is maintained with the server through the communication module, and the SOC is placed in a dormant state; If the vehicle is not a pure electric type, the MQTT connection with the server is maintained through the communication module within a preset connection time period, and the SOC is placed in a sleep state. Outside the preset connection time period, the MQTT connection between the communication module and the server is disconnected. The method according to claim 6, characterized in that the method further comprises: If a control instruction sent by a cloud server is received while the vehicle maintains an MQTT connection with the server, determining whether the SOC is in a dormant state; If the SOC is in a dormant state, the SOC is awakened, and the control instruction is sent to the SOC for execution. The method according to any one of claims 5 to 7, further comprising: obtaining the temperature and remaining battery power of the vehicle; If the temperature is lower than a preset temperature value or the remaining battery power is lower than a preset power value, the MQTT connection with the server is disconnected. A vehicle remote control device, characterized in that the device comprises: A receiving module, configured to receive a vehicle control request sent by a user terminal device, wherein the vehicle control request includes a target vehicle identifier and a control instruction; a judgment module, configured to determine a connection status of the target vehicle according to a status of a message queue telemetry transmission protocol MQTT connection between the target vehicle corresponding to the target vehicle identifier, wherein the target vehicle is determined to be online when the status of the MQTT connection is connected, and the target vehicle is determined to be offline when the status of the MQTT connection is disconnected; A first sending module is used to send a text message SMS to wake up the target vehicle if the target vehicle is offline; The second sending module is used to send the control instruction to the target vehicle through MQTT after the target vehicle is awakened. A vehicle remote control device, characterized in that the device comprises: A receiving module receives a short message SMS sent by a server, wherein the SMS is used to wake up the vehicle; A wake-up module is used to wake up the main control chip SOC and the communication module, and establish a message queue telemetry transmission protocol MQTT connection with the server through the communication module; The execution module is used to receive the control instruction sent by the server through MQTT and execute the control instruction. A server, characterized in that the server comprises: A processor, a memory connected to the processor, and a communication interface for interacting with other devices, wherein the processor is used to execute the vehicle remote control method according to any one of claims 1 to 4. A vehicle, characterized in that the vehicle comprises a vehicle body and a controller; The controller is used to execute the vehicle remote control method according to any one of claims 5 to 8. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the vehicle remote control method according to any one of claims 1 to 8. A computer program product, characterized in that it comprises a computer program, which, when executed by a processor, implements the vehicle remote control method according to any one of claims 1 to 8.