Vehicle-mounted terminal and server connection recovery method

Abstract

The invention provides a method for a vehicle-mounted terminal and a server to recover connection, and belongs to the technical field of vehicle-mounted Internet of Things MQTT, the method is applied to the vehicle-mounted terminal, and the method comprises the following steps: sending a connection request to the server, and obtaining a connection request response returned by the server; periodically sending a heartbeat request to the server according to a preset keep-alive period, and obtaining a heartbeat request response returned by the server; and in the keep-alive period, when the MQTT connection is abnormally disconnected, sending the heartbeat request to the server again so as to reconnect the server. According to the method for optimizing the vehicle-mounted terminal and the server to recover the connection again, when the vehicle-mounted terminal causes the MQTT to be disconnected abnormally due to external reasons, the vehicle-mounted terminal carries out MQTT reconnection operation in time, the server judges the MQTT connection state as early as possible, it is ensured that communication and services among a mobile phone APP, a TSP, a TBOX and other platforms can be processed and operated normally, and the service quality of the mobile phone APP, the TSP, the TBOX and other platforms is improved. The robustness of the system is improved, and the user experience is ensured.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted Internet of Things (MQTT) technology, and in particular to a method for reconnecting vehicle-mounted terminals and servers. Background Technology

[0002] MQTT is a lightweight, publish / subscribe (Pub / Sub) based messaging protocol designed for low-bandwidth, high-latency, or unreliable network environments, and is widely used in the field of automotive IoT.

[0003] The main application scenarios of MQTT in automotive IoT include: Real-time data acquisition: Through the MQTT protocol, vehicle sensors (such as battery status, engine temperature, tire pressure, fuel consumption, etc.) can report data to the cloud platform in real time; Remote control: Based on a mobile APP, remote control commands can be sent to the vehicle terminal via the MQTT protocol to remotely set the vehicle's doors, air conditioning, seats, lights, etc.; Over-the-air (OTA) software updates: Through the MQTT publish / subscribe mechanism, automakers can push firmware upgrade packages to vehicles in batches to ensure the reliability of the upgrade process; V2X communication: Through the MQTT protocol, communication between vehicles and cloud platforms (V2N), vehicles and vehicles (V2V), and vehicles and infrastructure (V2I) can be realized; Fault warning and diagnosis: The vehicle's ECU (Electronic Control Unit) pushes fault codes or abnormal data via MQTT, and the cloud platform can analyze and notify the owner or repair shop in real time; Personalized services: Content is pushed based on the user's subscribed infotainment-related MQTT topics (such as music and news).

[0004] To ensure the above functions can be implemented, it is first necessary to ensure that the vehicle terminal TBOX and the TSP server can maintain a normal MQTT connection. Currently, the MQTT connection between the vehicle terminal TBOX and the TSP server has certain limitations:

[0005] 1. During the keep-alive period, under abnormal circumstances, the MQTT connection may be interrupted in the client TBOX. At this time, the server judges that it has not exceeded 1.5 times the keep-alive period and mistakenly believes that the connection between the two parties is maintained. This causes the TSP, mobile APP, and OTA server to continue to carry out normal remote command or business delivery work, which makes the TBOX unable to receive normally, resulting in the failure of remote control or business execution.

[0006] 2. If the TBOX has lost connection within the 1.5 times keep-alive period on the server side, but the TSP still considers the connection to be normal, firstly, other applications or platforms associated with the server will not be able to obtain the connection status of the TBOX in a timely and correct manner, leading to misjudgment of information or business. The TSP will continue to send normal information or business to the TBOX, resulting in a decline in user experience. Summary of the Invention

[0007] The present invention aims to solve at least one of the above-mentioned technical problems in the prior art, and proposes an optimized method for reconnecting the vehicle terminal and the server in the event of MQTT disconnection, thereby reducing misjudgments caused by failure to make timely judgments during the keep-alive period, improving the robustness of the system, and ensuring user experience.

[0008] In a first aspect, embodiments of the present invention provide a method for reconnecting a vehicle-mounted terminal and a server, the method being applied to a vehicle-mounted terminal, the method comprising:

[0009] Send a connection request to the server and receive the connection request response from the server.

[0010] Based on the preset keep-alive period, it periodically sends heartbeat requests to the server and obtains the heartbeat request response returned by the server;

[0011] During the keep-alive period, if the MQTT connection is abnormally disconnected, a heartbeat request is sent to the server again to reconnect to the server.

[0012] In a preferred embodiment, the step of sending a heartbeat request to the server again to reconnect to the server when the MQTT connection is abnormally disconnected during the keep-alive period includes:

[0013] The abnormal disconnection of the MQTT connection includes: the vehicle terminal reconnecting to the APN or the vehicle terminal switching to flight mode.

[0014] In a preferred embodiment, the system further includes: after the vehicle terminal successfully reconnects to the server, it executes business process operations.

[0015] In a preferred embodiment, the method further includes: after the vehicle terminal successfully reconnects to the server, if there is no subsequent service, the vehicle terminal is set to a long connection, and according to a preset keep-alive period, the vehicle terminal periodically sends a heartbeat request to the server and obtains the heartbeat request response returned by the server.

[0016] In a preferred embodiment, the system further includes: after the vehicle terminal successfully reconnects to the server, if there are no subsequent services, and the vehicle terminal is not set to a long connection, the vehicle terminal performs a sleep operation.

[0017] Secondly, embodiments of the present invention provide another method for reconnecting a vehicle-mounted terminal and a server, the method being applied to a server, the method comprising:

[0018] Obtain the connection request sent by the vehicle terminal and return the connection request response to the vehicle terminal;

[0019] Get the heartbeat request sent by the vehicle terminal and return the heartbeat request response to the vehicle terminal;

[0020] Within the first time threshold, the obtained mobile APP request is sent to the vehicle terminal;

[0021] Detect whether a response to the mobile app request returned by the vehicle terminal is received within the second time threshold;

[0022] If a response to the mobile app request is received from the vehicle terminal, the response to the mobile app request is fed back to the mobile app.

[0023] If no response is received from the vehicle terminal for the mobile app request, check if the number of retries does not exceed two.

[0024] If the number of retries does not exceed two, the obtained mobile APP request is resent to the vehicle terminal, and the step of detecting whether the response to the mobile APP request returned by the vehicle terminal is received within the second time threshold is executed.

[0025] If the number of retries exceeds two, wake up the vehicle terminal via SMS, execute the steps of obtaining the connection request sent by the vehicle terminal, returning the connection request response steps to the vehicle terminal, obtaining the heartbeat request sent by the vehicle terminal, and returning the heartbeat request response steps to the vehicle terminal to reconnect to the vehicle terminal.

[0026] In a preferred embodiment, the mobile app request is a remote control command or a query command; the response to the mobile app request is a remote control execution result or a query result.

[0027] In a preferred embodiment, in the step of sending the acquired mobile APP request to the vehicle terminal within the first time threshold:

[0028] The first time threshold is greater than or equal to the preset keep-alive period.

[0029] In a preferred embodiment, the first time threshold is 1.5 times the preset keep-alive period.

[0030] In a preferred embodiment, the second time threshold is 5 seconds.

[0031] Beneficial effects of this invention:

[0032] This invention optimizes the method for reconnecting the vehicle terminal and the server, enabling the vehicle terminal to promptly reconnect to MQTT when it experiences an abnormal MQTT disconnection due to external factors. The server then determines the MQTT connection status as early as possible, ensuring normal processing and operation of communication and services between the mobile app, TSP, TBOX, and other platforms. This improves system robustness and guarantees a better user experience. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the MQTT connection process between the vehicle terminal and the server under normal circumstances.

[0034] Figure 2 This is a schematic diagram of the T-BOX structure;

[0035] Figure 3 This diagram illustrates the connection between a mobile phone, an in-vehicle terminal, and a server.

[0036] Figure 4 This is a schematic flowchart of a method for reconnecting a vehicle-mounted terminal and a server according to an embodiment of the present invention.

[0037] Figure 5 This is a schematic flowchart illustrating another method for reconnecting a vehicle-mounted terminal and server, provided in an embodiment of the present invention. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0039] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0040] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0041] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0042] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0043] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0044] The abbreviations and key terms in this invention are defined as follows:

[0045] Cellular Network, or mobile network;

[0046] C / S, Client / Server;

[0047] IOV, Internet of Vehicles;

[0048] MQTT, Message Queuing Telemetry Transport.

[0049] Pub, Publisher;

[0050] Sub, Subscriber;

[0051] T-BOX, Telematics BOX, Cellular Wireless Communication Terminal;

[0052] TSP stands for Telematics Service Provider.

[0053] like Figure 1 As shown, under normal circumstances, the MQTT connection process between the vehicle terminal and the server is mainly divided into two stages: the first is the connection establishment stage, and the second is the connection maintenance stage.

[0054] (1) Connection establishment phase

[0055] 1.1. The vehicle terminal (client) sends a CONNECT message with a keep-alive period parameter (e.g., keep-alive period = T seconds);

[0056] 1.2. After server verification, a connection request CONNACK is returned. At this point, the keep-alive function is not yet active; the keep-alive timer will start after the connection is successfully established.

[0057] (2) Connection maintenance phase

[0058] 2.1. If the client does not send any message (such as PUBLISH) during the Keep Alive period, it must actively send a heartbeat request PINGREQ.

[0059] 2.2. After receiving a heartbeat request, the server returns a PINRESP response. If the server does not receive any messages (including heartbeats or data) within 1.5 times the Keep Alive time, it will proactively disconnect the connection.

[0060] In related technologies, the cellular internet wireless communication terminal TBOX is an in-vehicle electronic controller, and its application layer software is also designed modularly. Its heartbeat connection with the server's MQTT is a separate module. For example... Figure 2 As shown, the TBOX includes an MQTT heartbeat module, a network anomaly module, and other TBOX modules. Due to external environmental factors, such as a lack of base stations or remote mountainous areas, the TBOX network anomaly module detects an abnormal network signal and performs APN reconnection or airplane mode switching operations. This operation abnormally disconnects the MQTT connection. However, the network anomaly module does not notify the MQTT heartbeat module of the disconnection, causing the MQTT heartbeat module to still consider the MQTT connection normal during its keep-alive period. It continues to abnormally process OTA, data reporting, data mining, and other services, resulting in the failure of all related services and severely impacting the business process between the TBOX and the TSP.

[0061] In related technologies, the connection relationship between the mobile phone, the vehicle-mounted terminal TBOX, and the server (cloud-based TSP) is as follows: Figure 3As shown in the diagram, the vehicle can be remotely controlled via a mobile app, performing operations such as opening and closing doors, windows, and air conditioning. These remote control commands first pass through the cloud-based TSP (Traffic Support Service). The cloud TSP then checks if the MQTT connection is normal. If it is, the remote control command is sent to the TBOX (Total Vehicle Controller). The TBOX then executes the remote control operation according to the vehicle's normal communication protocols. If the TSP and TBOX maintain a normal MQTT connection, the mobile app's remote control commands can communicate normally. However, if the TBOX abnormally disconnects its MQTT connection, and the TSP is still within its 1.5x keep-alive period, the TSP will still consider the MQTT connection normal. When the mobile app sends a remote control command, the TSP mistakenly believes the connection is active and will still send the normal remote control command to the TBOX. Ultimately, the mobile app will display a remote control execution failure message, severely impacting the user experience.

[0062] This invention optimizes the method for reconnecting the vehicle-mounted terminal (TBOX) and the server (TSP). This enables the TBOX to quickly reconnect to the TSP via MQTT when it is within its keep-alive period and when its MQTT connection is abnormally disconnected due to external factors. Furthermore, when the server sends a remote control command to the TBOX within its keep-alive period, if the command fails to be sent, a two-retry mechanism quickly assesses the communication between the two parties. If a connection problem is detected, an SMS wake-up call quickly re-establishes the MQTT connection with the TBOX, ensuring normal business operations.

[0063] Figure 4 This is a flowchart illustrating a method for reconnecting a vehicle-mounted terminal and server according to an embodiment of the present invention; as shown below. Figure 4 As shown, this method is applied to an in-vehicle terminal, and the method includes:

[0064] Step S1: Send a connection request to the server and obtain the connection request response returned by the server;

[0065] Step S2: According to the preset keep-alive period, periodically send heartbeat requests to the server and obtain the heartbeat request response returned by the server;

[0066] Step S3: During the keep-alive period, if the MQTT connection is abnormally disconnected, a heartbeat request is sent to the server again to reconnect to the server.

[0067] In some embodiments, step S3, during the keep-alive period, involves sending a heartbeat request to the server again to reconnect to the server when the MQTT connection is abnormally disconnected.

[0068] The abnormal disconnection of the MQTT connection includes: the vehicle terminal reconnecting to the APN or the vehicle terminal switching to flight mode.

[0069] APN stands for Access Point Name. When the TBOX detects "signal strength but inability to transmit data" (i.e., the long connection is broken and cannot be re-established), it triggers an APN reconnection operation, including: Disconnecting the data connection: The TBOX actively disconnects the currently established but problematic data connection channel with the operator; Reconfiguring: It rereads the APN configuration information in the SIM card and the preset configuration information; Re-initiating the connection request: It re-initiates a "login" request to the operator's network, requesting the establishment of a new data channel and obtaining a new IP address; Re-establishing the upper-layer connection: After the data channel is established, it re-initiates the TCP connection and long connection with the cloud server.

[0070] Airplane mode disables all wireless communication functions of the device. In TBOX, airplane mode specifically disables the cellular network module. The process of switching airplane mode involves: Enabling airplane mode: The TBOX software sends a command to the communication module to completely disable its radio frequency function; Short wait: The system waits a few seconds to ensure the module is completely shut down, clearing its temporary cache and error state; Deactivating airplane mode: TBOX sends the command again to re-enable the communication module.

[0071] In some embodiments, the method further includes: step S4, after the vehicle terminal successfully reconnects to the server, performing business process operations.

[0072] In some embodiments, the method further includes: step S5, after the vehicle terminal successfully reconnects to the server, if there is no subsequent service, the vehicle terminal is set to a long connection, and according to a preset keep-alive period, the vehicle terminal periodically sends a heartbeat request to the server and obtains the heartbeat request response returned by the server.

[0073] The long connection refers to the TBOX establishing a network connection (TCP connection) with the cloud server after the vehicle is started, and maintaining this connection as long as possible throughout the vehicle's use, so as to enable continuous, real-time or near real-time bidirectional communication.

[0074] The aforementioned real-time bidirectional communication means that it can be achieved as long as a connection exists:

[0075] The server actively issues commands: The cloud can send commands to the vehicle at any time, such as: remote control: remotely unlocking, closing windows, and starting the air conditioning; remote query: querying the vehicle's location, remaining fuel / battery level, and door status; push notifications: pushing navigation routes and software update notifications to the vehicle's infotainment system.

[0076] TBOX proactively reports data: TBOX can report data at any time or according to settings, such as: real-time status: vehicle fault codes, battery health status; driving behavior data: rapid acceleration, emergency braking, etc.; trigger-based alarms: automatically report location and alarm information when the vehicle is involved in a collision or stolen.

[0077] In some embodiments, the method further includes: step S6, after the vehicle terminal successfully reconnects to the server, if there are no subsequent services and the vehicle terminal is not set to a long connection, the vehicle terminal performs a hibernation operation.

[0078] In sleep mode, TBOX disables its high-power functions, mainly those related to communication.

[0079] Hibernation operations may include:

[0080] Disconnect persistent connections: Persistent connections with the cloud server will be actively disconnected;

[0081] Stop heartbeats: Stop sending heartbeats to maintain the connection;

[0082] Main communication modules are shut down: the 4G / 5G cellular network module and GPS module will be turned off or placed in an extremely low power state.

[0083] Stop data reporting: Normal vehicle status data will not be reported.

[0084] Unable to respond to remote commands: During this period, most of the remote control functions of the mobile app will be disabled. For example, sending commands such as "remotely unlock" or "turn on the air conditioner" via the mobile app will display "execution failed" or "vehicle not online".

[0085] In some embodiments, the entire process of connecting to the server TSP executed by the in-vehicle terminal (client) TBOX includes:

[0086] ①TBOX powers on normally;

[0087] ②The TBOX and TSP initiate the initial MQTT connection by sending normal CONNECT and CONNECTACK requests and responses.

[0088] ③TBOX and TSP perform normal periodic PINGREQ and PINRESP heartbeat interactions;

[0089] ④TBOX and TSP perform normal business and process operations;

[0090] ⑤ If a network error occurs during periodic heartbeat sending, the network error module will reconnect via APN or switch to airplane mode, causing the MQTT connection to be abnormally disconnected. The network error module will immediately send the connection error status to the heartbeat module, and the heartbeat module will immediately re-initiate the PINGREQ connection request to reconnect to the TSP without waiting for the keep-alive period time to send the heartbeat packet request.

[0091] ⑥ Once the TSP and TBOX successfully reconnect via MQTT, if there are subsequent actual business transactions, return to ④ and proceed with the normal business process for both parties according to the standard procedure.

[0092] ⑦ If there is no actual business afterward, and if the TBOX has a persistent connection configured, return to step ③.

[0093] ⑧If the TBOX is not configured with a persistent connection and there is no actual business activity, the TBOX will perform a normal sleep procedure.

[0094] Figure 5 A flowchart illustrating another method for reconnecting a vehicle-mounted terminal and server according to an embodiment of the present invention; as shown. Figure 5 As shown, this method is applied to a server, and the method includes:

[0095] Step T1: Obtain the connection request sent by the vehicle terminal and return a connection request response to the vehicle terminal;

[0096] Step T2: Obtain the heartbeat request sent by the vehicle terminal and return a heartbeat request response to the vehicle terminal;

[0097] Step T3: Within the first time threshold, send the obtained mobile APP request to the vehicle terminal;

[0098] Step T4: Detect whether a response to the mobile APP request returned by the vehicle terminal is received within the second time threshold.

[0099] Step T5: If a response to the mobile APP request is received from the vehicle terminal, the response to the mobile APP request is fed back to the mobile APP.

[0100] Step T6: If no response to the mobile APP request is received from the vehicle terminal, check whether the number of retries does not exceed two.

[0101] Step T7: If the number of retries does not exceed two, resend the obtained mobile APP request to the vehicle terminal and perform the step of detecting whether the response of the mobile APP request returned by the vehicle terminal is received within the second time threshold.

[0102] Step T8: If the number of retries exceeds two, wake up the vehicle terminal via SMS, execute the steps of obtaining the connection request sent by the vehicle terminal, returning the connection request response to the vehicle terminal, obtaining the heartbeat request sent by the vehicle terminal, and returning the heartbeat request response to the vehicle terminal to reconnect to the vehicle terminal.

[0103] Wake-up of the vehicle terminal TBOX via SMS is a backup technology that utilizes the basic signaling channel of the mobile network to achieve reliable remote triggering while the TBOX is in deep sleep mode.

[0104] In some embodiments, the mobile app request is a remote control command or a query command; the response to the mobile app request is a remote control execution result or a query result.

[0105] In some embodiments, in step T3, within the first time threshold, the step of sending the acquired mobile APP request to the vehicle terminal includes:

[0106] The first time threshold is greater than or equal to the preset keep-alive period.

[0107] In some embodiments, the first time threshold is 1.5 times the preset keep-alive period.

[0108] To maintain a long connection, the heartbeat keep-alive period of the vehicle terminal TBOX is relatively short, usually ranging from 30 seconds to 5 minutes, depending on network characteristics and software settings.

[0109] In some embodiments, the second time threshold is 5 seconds.

[0110] In some embodiments, the entire process of connecting the server TSP to the vehicle terminal (client) TBOX includes:

[0111] ① The mobile app and TSP maintain normal connection and communication;

[0112] ②TBOX and TSP maintain a normal MQTT connection state (when TBOX and TSP connect for the first time, TSP has already sent the keep-alive period T and the activation will flag when making the CONNECT connection request).

[0113] ③ Perform normal remote control and related business inquiries through the mobile APP, and send the results to the TSP;

[0114] ④ During the 1.5 times keep-alive period, TSP sets the variables N-retry=0 and latest-respond-flag=false;

[0115] ⑤ Within a 1.5 times keep-alive period, the TSP sends remote control or query commands to the TBOX according to the request of the mobile APP;

[0116] ⑥ Within a fixed time period (e.g., 5 seconds), if the TSP receives a positive response from the TBOX (e.g., it receives a remote control execution result or a query status), then latest-respond-flag=true; proceed to step ⑧; within a fixed time period (e.g., 5 seconds), if the TSP receives a negative response from the TBOX (e.g., it does not receive a response from the vehicle terminal to the mobile APP request), proceed to step ⑦;

[0117] ⑦ Execute the retry mechanism: If N-Retry! = 2, send the remote control command or query command to TBOX according to the request of the mobile APP, N-Retry++, and execute step ⑥;

[0118] ⑧ If latest-respond-flag=true, TSP forwards the remote control execution result or query status feedback to the mobile APP; Execution step ⑩;

[0119] If latest-respond-flag=false, the TSP wakes up the TBOX via SMS, and then both parties establish a normal MQTT connection. Once the connection is successful, step ③ is executed.

[0120] ⑩ Proceed with the subsequent related procedures as normal.

[0121] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for recovering connection between a vehicle terminal and a server, characterized by, The method is applied to a vehicle terminal, and the method comprises: sending a connection request to a server and obtaining a connection request response returned by the server; periodically sending a heartbeat request to the server according to a preset keep-alive period and obtaining a heartbeat request response returned by the server; when the MQTT connection is abnormally disconnected within the keep-alive period, sending a heartbeat request to the server again to reconnect the server.

2. The method of claim 1, wherein, In the step of sending a heartbeat request to the server again to reconnect the server when the MQTT connection is abnormally disconnected within the keep-alive period: the abnormal disconnection of the MQTT connection comprises APN reconnection of the vehicle terminal or switching of the vehicle terminal to a flight mode.

3. The method according to claim 1 or 2, characterized in that, Further comprising: after the vehicle terminal reconnects the server successfully, performing a business process operation.

4. The method of claim 3, wherein, Further comprising: after the vehicle terminal reconnects the server successfully, if there is no subsequent business, setting the vehicle terminal as a long connection, periodically sending a heartbeat request to the server according to a preset keep-alive period, and obtaining a heartbeat request response returned by the server.

5. The method of claim 3, wherein, Further comprising: after the vehicle terminal reconnects the server successfully, if there is no subsequent business, and the vehicle terminal is not set as a long connection, performing a sleep operation by the vehicle terminal.

6. A method for recovering connection between a vehicle terminal and a server, characterized by, The method is applied to a server, and the method comprises: obtaining a connection request sent by a vehicle terminal and returning a connection request response to the vehicle terminal; obtaining a heartbeat request sent by the vehicle terminal and returning a heartbeat request response to the vehicle terminal; within a first time threshold, sending a mobile phone APP request obtained to the vehicle terminal; detecting whether a response to the mobile phone APP request returned by the vehicle terminal is received within a second time threshold; if the response to the mobile phone APP request returned by the vehicle terminal is received, feeding back the response to the mobile phone APP request to a mobile phone APP; if the response to the mobile phone APP request returned by the vehicle terminal is not received, detecting whether a retry count is less than twice; if the retry count is less than twice, sending the mobile phone APP request obtained to the vehicle terminal again, and performing the step of detecting whether the response to the mobile phone APP request returned by the vehicle terminal is received within the second time threshold; if the retry count is more than twice, waking up the vehicle terminal through a short message, performing the steps of obtaining the connection request sent by the vehicle terminal and returning the connection request response to the vehicle terminal, and obtaining the heartbeat request sent by the vehicle terminal and returning the heartbeat request response to the vehicle terminal, to reconnect the vehicle terminal.

7. The method of claim 6, wherein, The mobile phone APP request is a remote control instruction or a query instruction, and the response to the mobile phone APP request is a remote control execution result or a query result.

8. The method according to claim 6 or 7, characterized in that, In the step of sending the mobile phone APP request obtained to the vehicle terminal within the first time threshold: the first time threshold is greater than or equal to the preset keep-alive period.

9. The method of claim 8, wherein, the first time threshold is 1.5 times the preset keep-alive period.

10. The method of claim 9, wherein, the second time threshold is 5 seconds.

Images