Vehicle remote wake-up processing method and computer readable storage medium
By generating and analyzing the timestamps of the first and second data points, the success or failure of remote vehicle wake-up is determined, thus solving the problem of low accuracy in remote vehicle wake-up and achieving accurate remote wake-up results.
Patent Information
- Application Number
- CN202310417200.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-18
- Publication Date
- 2025-12-30
- Estimated Expiration
- 2043-04-18
AI Technical Summary
Existing technologies for remote vehicle wake-up have low accuracy and cannot accurately pinpoint the specific reasons for wake-up failure.
By forwarding the remote wake-up command from the user terminal to the vehicle while the vehicle is in sleep mode, the first set of embedded data is generated, and the second set of embedded data sent by the vehicle is received. Based on these two sets of data, the wake-up result of the remote wake-up command is generated, and the wake-up success or failure and the reason are determined by analyzing the timestamp and embedded data.
It improves the accuracy of remote vehicle wake-up, accurately determining whether there are problems at the receiving and sending ends of the remote wake-up command, thus solving the problem of low wake-up accuracy.
Smart Images

Figure CN116419184B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle data processing, and more specifically, to a method for remotely waking up a vehicle and a computer-readable storage medium. Background Technology
[0002] With the rapid development of vehicle-to-everything (V2X) technology, V2X has become a standard feature in mainstream vehicles, enabling remote vehicle control through in-vehicle controllers, vehicle communication terminals, V2X cloud platforms, and V2X mobile applications. One such function is remote engine start via a user terminal (e.g., a mobile phone), allowing users to control the vehicle in advance. It's important to note that the remote control process involves communication between the vehicle and the cloud. When the vehicle is off, communication between the vehicle's backend and the cloud is impossible, which necessitates waking up the in-vehicle communication terminal.
[0003] Currently, remote wake-up of vehicle terminals mainly relies on sending wake-up SMS messages. However, relying solely on wake-up SMS messages to wake up the vehicle cannot accurately pinpoint the specific reason for the wake-up failure, resulting in a low accuracy rate for remote vehicle wake-up.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] This invention provides a method for remotely waking up a vehicle and a computer-readable storage medium to at least solve the technical problem of low wake-up accuracy in remotely waking up vehicles in related technologies.
[0006] According to one aspect of the present invention, a method for remotely waking up a vehicle is provided, comprising: forwarding a remote wake-up command sent by a user terminal to the vehicle when the vehicle is in a sleep state; generating first embedded data based on the remote wake-up command, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command; receiving second embedded data sent by the vehicle, wherein the second embedded data is used to characterize data related to the receiving of the remote wake-up command; and generating a wake-up result of the remote wake-up command based on the first embedded data and the second embedded data.
[0007] Optionally, based on the first and second embedded data, a wake-up result for the remote wake-up command is generated, including: in response to incomplete first or second embedded data, a wake-up result of wake-up failure is generated, and the cause of failure corresponding to the wake-up result is determined to be failure of remote wake-up command issuance; in response to complete first and second embedded data, a wake-up result is generated based on first time information contained in the first embedded data and second time information contained in the second embedded data, wherein the first time information is used to characterize the time of generating the first embedded data, and the second time information is used to characterize the time when the vehicle sends the second embedded data.
[0008] Optionally, based on the first time information contained in the first embedded data and the second time information contained in the second embedded data, a wake-up result is generated, including: obtaining the difference between the first time information and the second time information to obtain a time difference; in response to the time difference being greater than a first preset threshold, a wake-up result of wake-up failure is generated, and the cause of failure corresponding to the wake-up result is determined based on the time difference; in response to the time difference being less than or equal to the first preset threshold, a wake-up result of wake-up success is generated.
[0009] Optionally, determining the failure reason corresponding to the wake-up result based on the time difference includes: in response to the time difference being greater than a second preset threshold, determining the failure reason as a delay in sending the remote wake-up command; in response to the time difference being greater than a first preset threshold and less than or equal to a second preset threshold, determining the failure reason as a wake-up delay in the vehicle.
[0010] Optionally, based on the first and second tracking data, a wake-up result for the remote wake-up command is generated, including: obtaining a locally stored tracking data list, wherein the tracking data list is used to store the first and second tracking data; traversing the tracking data list to obtain target tracking data, wherein the target tracking data is used to represent any one tracking data in the tracking data list; and generating a wake-up result based on the target tracking data.
[0011] Optionally, after generating the wake-up result of the remote wake-up command based on the first and second embedded data, the method further includes: determining the number of times the wake-up result is a successful wake-up based on the wake-up result, and determining the total number of times the wake-up result is generated; obtaining the quotient of the number of times and the total number of times to obtain the wake-up success rate of the remote wake-up command.
[0012] Optionally, forwarding the remote wake-up command sent by the user terminal to the vehicle includes: forwarding the remote wake-up command to the vehicle in response to the vehicle being online; and generating and sending an SMS message to the vehicle based on the remote wake-up command in response to the vehicle being offline.
[0013] Optionally, the SMS information includes, but is not limited to: wake-up ciphertext, identification information, and a delivery timestamp, wherein the delivery timestamp is generated when the user terminal sends a wake-up SMS.
[0014] Optionally, the method further includes: receiving the execution result corresponding to the remote wake-up command returned by the vehicle; and sending the execution result to the user terminal.
[0015] According to another aspect of the present invention, a method for remotely waking up a vehicle is also provided, comprising: receiving a remote wake-up command forwarded by a server, wherein the remote wake-up command is sent to the server by a user terminal; controlling the vehicle to execute the remote wake-up command and generating second embedded data; sending the second embedded data to the server, wherein the second embedded data and first embedded data stored in the server are used to determine the wake-up result of the remote wake-up command, and the first embedded data is generated by the server based on the remote wake-up command.
[0016] According to another aspect of the present invention, a processing apparatus for remotely waking up a vehicle is also provided, comprising: a first sending module, configured to forward a remote wake-up command sent by a user terminal to the vehicle when the vehicle is in a sleep state; a first generating module, configured to generate first embedded data based on the remote wake-up command, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command; a first receiving module, configured to receive second embedded data sent by the vehicle, wherein the second embedded data is used to characterize data related to the receiving of the remote wake-up command; and a second generating module, configured to generate a wake-up result of the remote wake-up command based on the first embedded data and the second embedded data.
[0017] According to another aspect of the present invention, a processing apparatus for remotely waking up a vehicle is also provided, comprising: a receiving module for receiving a remote wake-up command forwarded by a server, wherein the remote wake-up command is sent from a user terminal to the server; a control module for controlling the vehicle to execute the remote wake-up command and generating second embedded data; and a sending module for sending the second embedded data to the server, wherein the second embedded data and first embedded data stored in the server are used to determine the wake-up result of the remote wake-up command, and the first embedded data is generated by the server based on the remote wake-up command.
[0018] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the vehicle remote wake-up processing method described above.
[0019] According to another aspect of the present invention, a vehicle is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the vehicle remote wake-up processing method described above.
[0020] In this embodiment of the invention, when the vehicle is in a sleep state, a remote wake-up command sent by a user terminal is forwarded to the vehicle; based on the remote wake-up command, first embedded data is generated, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command; second embedded data sent by the vehicle is received, wherein the second embedded data is used to characterize data related to the reception of the remote wake-up command; and based on the first and second embedded data, the wake-up result of the remote wake-up command is generated. It is readily apparent that the first and second embedded data can accurately determine whether there are problems at the receiving and sending ends of the remote wake-up command, achieving the goal of accurately waking up the vehicle remotely. This improves the accuracy of remote wake-up of the vehicle and solves the technical problem of low wake-up accuracy in related technologies. Attached Figure Description
[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:
[0022] Figure 1 This is a flowchart of a vehicle remote wake-up processing method according to Embodiment 1 of the present invention;
[0023] Figure 2 This is a system architecture diagram of an optional vehicle remote wake-up according to Embodiment 1 of the present invention;
[0024] Figure 3 This is a flowchart illustrating an optional wake-up command issuance method according to Embodiment 1 of the present invention.
[0025] Figure 4 This is an interactive flowchart of an optional purchase point data reporting method according to Embodiment 1 of the present invention;
[0026] Figure 5 This is an interactive flowchart of an optional embedded data analysis according to Embodiment 1 of the present invention;
[0027] Figure 6 This is a flowchart of a vehicle remote wake-up processing method according to Embodiment 2 of the present invention;
[0028] Figure 7This is a schematic diagram of the structure of a vehicle remote wake-up processing device according to Embodiment 1 of the present invention;
[0029] Figure 8 This is a schematic diagram of a vehicle remote wake-up processing device according to Embodiment 2 of the present invention. Detailed Implementation
[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0032] Example 1
[0033] According to an embodiment of the present invention, an embodiment of a method for remotely waking up a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0034] Figure 1 This is a flowchart of a vehicle remote wake-up processing method according to Embodiment 1 of the present invention, as shown below. Figure 1 As shown, the method includes the following steps:
[0035] Step S102: When the vehicle is in a sleep state, forward the remote wake-up command sent by the user terminal to the vehicle.
[0036] In the technical solution disclosed in step S102 of this invention, the vehicle can be any type of vehicle with remote wake-up function, such as a gasoline vehicle with remote wake-up function, a new energy vehicle with remote wake-up function, or a hybrid vehicle with remote wake-up function, but not limited to these. The aforementioned user terminal can be any terminal capable of issuing remote wake-up commands, wherein the user terminal can include, but is not limited to: mobile phones, personal computers, and tablet computers. The aforementioned remote wake-up command can be a wake-up command sent by the user terminal to wake up the vehicle, for example, it can be "start the engine", "turn on the air conditioner", "open the window", "open the window and air conditioner", etc., but not limited to these.
[0037] In one optional embodiment, when the vehicle is in a dormant state, if the user needs to remotely control the vehicle, the user can send a remote wake-up command to the vehicle through the user terminal. Then, the cloud can forward the remote wake-up command from the user terminal to the vehicle. When the vehicle receives the remote wake-up command, it will perform the corresponding operation based on the remote wake-up command.
[0038] It should be noted that in the field of remote wake-up technology, communication between the vehicle and the user terminal needs to go through the cloud. Therefore, in this embodiment of the invention, the remote wake-up command of the user terminal can be forwarded through the cloud.
[0039] For example, when a vehicle is in a dormant state, if a user wants to start the engine, the user can send a "start engine" remote wake-up command to the vehicle through the user terminal. The cloud can then forward the remote wake-up command from the user terminal to the vehicle. Once the vehicle successfully receives the remote wake-up command, it can start the engine based on the command.
[0040] For example, when a vehicle is in a dormant state, if a user wants to open the windows and turn on the air conditioning, the user can send a remote wake-up command to "open the windows and turn on the air conditioning" through the user terminal. The cloud can then forward the remote wake-up command from the user terminal to the vehicle. Once the vehicle successfully receives the remote wake-up command, it can open the windows and turn on the air conditioning based on the command.
[0041] Step S104: Based on the remote wake-up command, generate first embedded data, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command.
[0042] The aforementioned first data point can be cloud-generated data related to the forwarding of remote wake-up commands. For example, it may include, but is not limited to: the timestamp of the remote wake-up command and identification information. The timestamp indicates the time the remote wake-up command was sent to the vehicle, and the identification information can be uniquely identifying the remote wake-up command, such as the remote wake-up command's ID.
[0043] In one optional embodiment, after the cloud forwards the remote wake-up command sent by the user terminal to the vehicle, the cloud can generate the first embedded data based on the sending time and identification information of the remote wake-up command.
[0044] In another optional embodiment, while the cloud forwards the remote wake-up command sent by the user terminal to the vehicle, the cloud can generate the first embedded data based on the sending time and identification information of the remote wake-up command.
[0045] Step S106: Receive second embedded data sent by the vehicle, wherein the second embedded data is used to characterize data related to the receipt of the remote wake-up command.
[0046] The second set of embedded data mentioned above can be data related to receiving the remote wake-up command sent by the vehicle to the cloud after receiving the remote wake-up command. For example, it may include, but is not limited to, the timestamp of the remote wake-up command reception. The timestamp is used to characterize the time when the vehicle receives the remote wake-up command.
[0047] In one optional embodiment, after the vehicle successfully receives the remote wake-up command forwarded by the cloud, the vehicle can send second embedded data to the cloud based on the time the remote wake-up command was received.
[0048] Step S108: Based on the first and second embedded data, generate the wake-up result of the remote wake-up command.
[0049] The wake-up results mentioned above can be those indicating successful vehicle wake-up, those indicating failed vehicle wake-up and analysis of the reasons for failure, or the vehicle's wake-up rate, but are not limited to these.
[0050] In one optional embodiment, after obtaining the first and second event tracking data, the cloud can analyze the first and second event tracking data to obtain the wake-up result of the remote wake-up command. For example, the timestamps in the first and second event tracking data can be analyzed. If the time interval between the sending timestamp in the first event tracking data and the receiving timestamp in the second event tracking data is one wake-up cycle, the wake-up result can be determined to be a successful wake-up. Alternatively, if the time interval between the sending timestamp in the first event tracking data and the receiving timestamp in the second event tracking data is less than or greater than one wake-up cycle, the wake-up result can be determined to be a failed wake-up. However, this is not the only possible approach.
[0051] In another optional embodiment, after obtaining the first and second event tracking data, the cloud can compare the data in the first and second event tracking data. Based on the comparison result, the wake-up result of the remote wake-up command can be obtained. For example, the time values of the sending timestamp in the first event tracking data and the receiving timestamp in the second event tracking data can be compared. If the receiving timestamp is greater than the sending timestamp, the wake-up result is "wake-up successful." Conversely, if the receiving timestamp is less than or equal to the sending timestamp, the wake-up result is "wake-up failed."
[0052] In this embodiment of the invention, when the vehicle is in a sleep state, a remote wake-up command sent by a user terminal is forwarded to the vehicle; based on the remote wake-up command, first embedded data is generated, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command; second embedded data sent by the vehicle is received, wherein the second embedded data is used to characterize data related to the reception of the remote wake-up command; and based on the first and second embedded data, the wake-up result of the remote wake-up command is generated. It is readily apparent that the first and second embedded data can accurately determine whether there are problems at the receiving and sending ends of the remote wake-up command, achieving the goal of accurately waking up the vehicle remotely. This improves the accuracy of remote wake-up of the vehicle and solves the technical problem of low wake-up accuracy in related technologies.
[0053] The method described in this embodiment will be further described below.
[0054] Optionally, based on the first and second embedded data, a wake-up result for the remote wake-up command is generated, including: in response to incomplete first or second embedded data, a wake-up result of wake-up failure is generated, and the cause of failure corresponding to the wake-up result is determined to be failure of remote wake-up command issuance; in response to complete first and second embedded data, a wake-up result is generated based on first time information contained in the first embedded data and second time information contained in the second embedded data, wherein the first time information is used to characterize the time of generating the first embedded data, and the second time information is used to characterize the time when the vehicle sends the second embedded data.
[0055] In one optional embodiment, after obtaining the first and second event tracking data, the cloud first determines the completeness of the first and second event tracking data. If either the first or second event tracking data is incomplete, the cloud can directly generate a wake-up result of "wake-up failed." If both the first and second event tracking data are complete, a wake-up result can be generated based on the first and second time information. The first time information represents the generation time of the first event tracking data, and the second time information represents the transmission time of the second event tracking data. For example, the first time information can be compared with the second time information. If the comparison result shows that the second time information is less than the first time information, it can be determined that the vehicle received the remote wake-up command before the user terminal issued the remote wake-up command. The cloud can then determine that the remote wake-up command received by the vehicle is inconsistent with the remote wake-up command issued by the user terminal, and thus a wake-up failure result can be generated. Alternatively, the time difference between the first and second time information can be obtained. If the time difference is greater than the wake-up period of the remote wake-up command, the cloud can determine that there is a delay in the remote wake-up command issued by the user terminal or the operator, and thus a wake-up failure result can be generated. If the time difference is less than or equal to the wake-up period of the remote wake-up command, the cloud can determine that there is no delay in the remote wake-up command issued by the user terminal and the operator, and thus a wake-up success result can be generated. However, this method is not the only one that can be used.
[0056] Optionally, based on the first time information contained in the first embedded data and the second time information contained in the second embedded data, a wake-up result is generated, including: obtaining the difference between the first time information and the second time information to obtain a time difference; in response to the time difference being greater than a first preset threshold, a wake-up result of wake-up failure is generated, and the cause of failure corresponding to the wake-up result is determined based on the time difference; in response to the time difference being less than or equal to the first preset threshold, a wake-up result of wake-up success is generated.
[0057] The aforementioned first preset threshold can be a threshold set by the user in advance to determine whether remote wake-up has failed. The user can set the specific value according to actual needs. In this embodiment, 10 seconds (s) is used as an example for explanation, but it is not limited to this. It can also be 8s, 12s, etc.
[0058] In one optional embodiment, after obtaining the first time information and the second time information, the difference between the first time information and the second time information can be obtained first to obtain the time difference; then, the time difference can be compared with a first preset threshold. If the time difference is greater than the first preset threshold, the cloud can generate a wake-up result as wake-up failure, and the failure reason corresponding to the wake-up result can be determined based on the time difference. If the time difference is less than the first preset threshold, the cloud can generate a wake-up result as wake-up success.
[0059] Optionally, determining the failure reason corresponding to the wake-up result based on the time difference includes: in response to the time difference being greater than a second preset threshold, determining the failure reason as a delay in sending the remote wake-up command; in response to the time difference being greater than a first preset threshold and less than or equal to a second preset threshold, determining the failure reason as a wake-up delay in the vehicle.
[0060] The aforementioned second time difference can be a threshold set in advance by the user to determine the cause of failure. The specific value can be set by the user according to actual needs. In this embodiment, 20 seconds (s) is used as an example, but it is not limited to this. It can also be 18s, 22s, etc.
[0061] In one optional embodiment, after determining that the time difference is greater than a first preset threshold, the time difference can be compared with a second preset threshold. If the time difference is greater than the second preset threshold, the failure can be determined to be due to a delay in the remote wake-up command. If the time difference is greater than the first preset threshold and less than or equal to the second preset threshold, the failure can be determined to be due to a wake-up delay in the vehicle.
[0062] Optionally, based on the first and second tracking data, a wake-up result for the remote wake-up command is generated, including: obtaining a locally stored tracking data list, wherein the tracking data list is used to store the first and second tracking data; traversing the tracking data list to obtain target tracking data, wherein the target tracking data is used to represent any one tracking data in the tracking data list; and generating a wake-up result based on the target tracking data.
[0063] The aforementioned list of event tracking data can be a list stored locally in the cloud, used to store the first and second event tracking data. The target event tracking data can be all event tracking data in the event tracking data list.
[0064] In one optional embodiment, the cloud can also retrieve a list of locally stored event tracking data at regular intervals. This list contains first and second event tracking data. Next, the event tracking data list can be traversed to obtain target event tracking data, which is the event tracking data in the event tracking data list. Finally, a wake-up result can be generated based on the target event tracking data. The method for generating the wake-up result based on the target event tracking data is the same as described above and will not be elaborated upon here.
[0065] It should be noted that the aforementioned period of time can be a time period set by the user based on actual needs. In this embodiment, a day is used as an example for explanation, but it is not limited to this.
[0066] Optionally, after generating the wake-up result of the remote wake-up command based on the first and second embedded data, the method further includes: determining the number of times the wake-up result is a successful wake-up based on the wake-up result, and determining the total number of times the wake-up result is generated; obtaining the quotient of the number of times and the total number of times to obtain the wake-up success rate of the remote wake-up command.
[0067] In one optional embodiment, after obtaining the wake-up result, the cloud can determine the number of times the wake-up result is successfully generated within a certain period of time, and can obtain the total number of times the wake-up result is generated within that period of time; secondly, the cloud can obtain the quotient of the number of times and the total number of times to obtain the wake-up success rate of the remote wake-up command.
[0068] It should be noted that the aforementioned time period can be a time period set by the user based on actual needs. In this embodiment, a day is used as an example for explanation, but it is not limited to this.
[0069] Optionally, forwarding the remote wake-up command sent by the user terminal to the vehicle includes: forwarding the remote wake-up command to the vehicle in response to the vehicle being online; and generating and sending an SMS message to the vehicle based on the remote wake-up command in response to the vehicle being offline.
[0070] In one optional embodiment, when the vehicle is online, the cloud can forward the remote wake-up command to the vehicle; when the vehicle is offline, the cloud can generate an SMS message based on the remote wake-up command and send the SMS message to the vehicle for remote wake-up.
[0071] Optionally, the SMS information includes, but is not limited to: wake-up ciphertext, identification information, and a delivery timestamp, wherein the delivery timestamp is generated when the user terminal sends a wake-up SMS.
[0072] In one optional embodiment, the SMS message may include, but is not limited to: wake-up ciphertext, which the vehicle will decrypt after receiving the wake-up ciphertext and perform the corresponding wake-up operation based on the decrypted content; identification information, which is a unique identifier for the SMS message, which may be a string of characters, but is not limited to this, and the corresponding SMS message can be found based on the identification information; and a delivery timestamp, which is generated synchronously when the user terminal sends the wake-up SMS message.
[0073] Optionally, the method further includes: receiving the execution result corresponding to the remote wake-up command returned by the vehicle; and sending the execution result to the user terminal.
[0074] The execution results mentioned above may include, but are not limited to: successful execution or failed execution.
[0075] In one optional embodiment, after the vehicle performs the corresponding operation based on the remote wake-up command, it will send the execution result to the cloud. After receiving the execution result, the cloud can forward the execution result to the user terminal, so that the user can intuitively and clearly see whether the remote wake-up was successfully executed.
[0076] This invention employs a data tracking method. A cloud platform sends instructions to record the tracked data. After receiving the data, the vehicle-mounted communication terminal reports the tracked data to the cloud platform. The cloud platform then uses big data analysis to identify problematic nodes. This allows for accurate statistics on wake-up success rates and problematic nodes. The reasons for wake-up failures are statistically analyzed, including platform failure to send SMS messages, operator SMS delivery failures or delays, or the vehicle-mounted communication terminal receiving an SMS but not executing the wake-up command. The percentage of wake-up failures is obtained, and this data is used to resolve product quality issues and guide the optimization and upgrading of next-generation products, improving the usability of connected vehicle products. Furthermore, it facilitates wake-up testing and product evaluation for vehicle-mounted terminals, assessing wake-up success rates and product usability through data analysis.
[0077] Figure 2 This is an optional system architecture diagram for remote vehicle wake-up according to Embodiment 1 of the present invention, such as... Figure 2 As shown, the system includes: a client, a vehicle network cloud platform, an IoT platform, and vehicles. The client includes user terminals and a management website; the vehicle network cloud platform includes: remote control backend services, downlink data services, IoT interface protocol decoding services, uplink data services, and a data statistics module, which further includes: data analysis services and data tracking services; the vehicle network includes in-vehicle communication terminals and vehicle controllers.
[0078] The client application includes a user terminal and a management website. The user terminal is used for remote control and sending commands such as starting the engine; the management website is used by users to view statistics on the wake-up results of the vehicle communication terminal.
[0079] The vehicle-to-everything (V2X) cloud platform serves as a backend service, supporting business functions such as remote control of user terminals and providing statistics on remote control wake-up success rates. The remote control component includes: remote control backend services, data uplink services, data downlink services, and IoT integration services; the remote control wake-up statistics component includes: data tracking services and data analysis services.
[0080] The Internet of Things (IoT) platform, serving as the medium for information communication between the vehicle and the vehicle-to-everything (V2X) cloud platform, is primarily responsible for transmitting vehicle-to-cloud data.
[0081] The vehicle receives commands from the cloud to control the vehicle and upload embedded data. The in-vehicle communication terminal module serves as the main module for receiving wake-up commands and uploading embedded data; the in-vehicle controller is used to implement various remote control commands.
[0082] Depend on Figure 2 As can be seen, after the user terminal sends a remote wake-up command, the remote control backend service of the vehicle network cloud platform receives the remote wake-up command and sends it to the IoT platform through the data downlink service and IoT docking protocol decoding service. The IoT platform forwards the remote wake-up command to the vehicle's in-vehicle communication terminal. Then, based on the remote wake-up command, the in-vehicle controller sends the vehicle-side embedded data (i.e., the second embedded data) to the in-vehicle communication terminal. The in-vehicle communication terminal sends the vehicle-side embedded data to the IoT platform. The IoT platform sends the vehicle-side embedded data to the vehicle network cloud platform. The vehicle network cloud platform processes the vehicle-side embedded data through the IoT docking protocol decoding service, data uplink service, data statistics module, and in conjunction with the client's management website to obtain the wake-up result. Then, the wake-up result is sent to the user terminal through the remote control backend service of the vehicle network cloud platform.
[0083] Figure 3 This is a flowchart illustrating an optional wake-up command issuance process according to Embodiment 1 of the present invention, as follows: Figure 3As shown, after the user terminal sends a remote wake-up command, it initiates a remote control service. The remote control backend service receives the command, performs command orchestration, and sends the command to the data downlink service. Upon receiving the command, the data downlink service first determines whether the vehicle is online. If the vehicle is online, it sends a remote control command to the IoT docking service. The IoT docking service sends data to the IoT platform. The IoT platform forwards the data to the in-vehicle communication terminal. The in-vehicle communication terminal receives the remote control command, sends the command to each controller, and then sends a remote control result response to the IoT platform. The IoT platform forwards the data to the IoT docking service, and the IoT docking service forwards the data to the data uplink service. In the first step, the data uplink service receives remote control data and distributes the remote control results to the remote control backend service. The remote control backend service receives the remote control execution results and sends them to the user terminal. The user terminal ends the process after receiving the execution results. In response to the vehicle being offline, the data downlink service generates an SMS wake-up command, which includes, but is not limited to, sending a timestamp and identification information. Then, it sends a wake-up SMS to the mobile operator. After receiving the SMS, the mobile operator wakes up the vehicle. At the same time, the data downlink service also polls the wake-up status to determine whether the vehicle is online and continues to send remote control commands. At this time, the above process of determining whether the vehicle is online is repeated, which will not be elaborated here.
[0084] When a mobile user issues a remote control command, the cloud platform's remote control backend service receives the request, orchestrates the command, and then sends it to the data downlink service. The data downlink service determines the vehicle's online status. If the vehicle is online, it sends the remote control command to the vehicle via the IoT platform; otherwise, it generates a wake-up SMS message (containing: wake-up ciphertext + unique SMS identifier + sending timestamp) and synchronizes the wake-up command data to the data tracking service, which stores the tracking data. The cloud-based wake-up command is then issued, and the tracking is complete.
[0085] Figure 4 This is an optional flowchart of the purchase point data reporting process according to Embodiment 1 of the present invention, as follows: Figure 4 As shown, after receiving the wake-up SMS, the vehicle communication terminal first parses the SMS content, then wakes up the vehicle terminal itself according to the SMS instruction, then wakes up the vehicle-side embedded data via SMS, and finally reports the vehicle status data to the IoT platform. The vehicle-side embedded data may include, but is not limited to: SMS timestamp, unique identifier, SMS reception time, and reporting time. After receiving the data, the IoT platform forwards it to the IoT docking service. The IoT docking service then forwards the data to the data uplink service. The data uplink service then forwards the vehicle-side embedded data to the data embedding service. Upon receiving the vehicle-side embedded data, the data embedding service searches for the vehicle's cloud-based embedded data within a preset time period (e.g., 5 minutes), updates the data, and then ends the process.
[0086] After receiving an SMS message, the vehicle-mounted communication terminal parses the message content and completes its self-wake-up. Then, it encapsulates the wake-up SMS data into tracking points. Vehicle-side tracking data is reported based on vehicle status (including the timestamp in the SMS, a unique identifier, the time the vehicle received the SMS, and the time the vehicle-side tracking data was reported). The cloud platform receives the reported tracking data and synchronizes it to the tracking service. It then searches for the vehicle's cloud-based tracking data within the last 5 minutes (which can be calibrated) and updates the tracking data accordingly.
[0087] Figure 5 This is an optional interactive flowchart for embedded data analysis according to Embodiment 1 of the present invention, such as... Figure 5 As shown, after receiving the event tracking data, the data analysis service can perform event tracking data analysis on a T+1 basis (i.e., daily). It iterates through the event tracking data list, analyzing each entry one by one. First, it checks if the cloud-based event tracking data and the vehicle-side event tracking data are complete. If the data is incomplete, it determines that the vehicle-side did not report the event tracking, did not receive the SMS, or there is a problem with the SMS operator, and the process ends. If the data is complete, it checks if the time between the cloud-based event tracking and the vehicle-side receiving the SMS is less than 20 seconds. If it is greater than or equal to 20 seconds, it determines that there is a delay in the SMS operator sending the SMS, and the process ends. If it is less than 20 seconds, it checks if the time between the cloud-based event tracking and the vehicle-side reporting is less than 10 seconds. If it is greater than or equal to 10 seconds, it determines that there is a delay in the vehicle-side wake-up, and the problem can be analyzed on the vehicle-side, and the process ends. If it is less than 10 seconds, the vehicle-side can wake up the entire vehicle, and the process ends.
[0088] Data analysis is performed based on the event tracking records to generate wake-up analysis results. This is executed once daily (T+1 mode), iterating through the event tracking data list and analyzing each record. By determining the completeness of the vehicle-side event tracking data, the vehicle's SMS reception time, and the time the vehicle reported the event tracking data, issues such as the operator not sending SMS messages, operator-sent SMS delays, and vehicle-side self-wake-up problems are identified.
[0089] Example 2
[0090] According to an embodiment of the present invention, an embodiment of a method for remotely waking up a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0091] Figure 6 This is a flowchart of a vehicle remote wake-up processing method according to Embodiment 2 of the present invention, as shown below. Figure 6 As shown, the method includes the following steps:
[0092] Step S602: Receive the remote wake-up command forwarded by the server, wherein the remote wake-up command is sent from the user terminal to the server;
[0093] Step S604: Control the vehicle to execute the remote wake-up command and generate the second embedded data;
[0094] Step S606: Send the second tracking data to the server. The second tracking data and the first tracking data stored in the server are used to determine the wake-up result of the remote wake-up command. The first tracking data is generated by the server based on the remote wake-up command.
[0095] In one optional embodiment, the vehicle can first receive a remote wake-up command forwarded by the server, wherein the remote wake-up command is sent from the user terminal to the server; secondly, the vehicle can be controlled to execute the remote wake-up command and generate second embedded data; finally, the second embedded data can be sent to the server, wherein the second embedded data and the first embedded data stored in the server are used to determine the wake-up result of the remote wake-up command, and the first embedded data is generated by the server based on the remote wake-up command.
[0096] Example 3
[0097] According to an embodiment of the present invention, a processing device for remote vehicle wake-up is also provided. This device can execute the processing method for remote vehicle wake-up provided in Embodiment 1 above. The specific implementation method and preferred application scenario are the same as those in Embodiment 1 above, and will not be repeated here.
[0098] Figure 7 This is a schematic diagram of a vehicle remote wake-up processing device according to Embodiment 1 of the present invention. As shown in the figure, the device includes: a first sending module 72, used to forward a remote wake-up command sent by a user terminal to the vehicle when the vehicle is in a sleep state; a first generating module 74, used to generate first embedded data based on the remote wake-up command, wherein the first embedded data is used to characterize data related to the forwarding of the remote wake-up command; a first receiving module 76, used to receive second embedded data sent by the vehicle, wherein the second embedded data is used to characterize data related to the receiving of the remote wake-up command; and a second generating module 78, used to generate a wake-up result of the remote wake-up command based on the first embedded data and the second embedded data.
[0099] Optionally, the second generation module includes: a first generation unit, configured to generate a wake-up result of wake-up failure in response to incomplete first or second embedded data, and determine that the failure reason corresponding to the wake-up result is failure to send a remote wake-up command; and a second generation unit, configured to generate a wake-up result based on first time information contained in the first embedded data and second time information contained in the second embedded data in response to complete first or second embedded data, wherein the first time information is used to characterize the time of generating the first embedded data and the second time information is used to characterize the time when the vehicle sends the second embedded data.
[0100] Optionally, the second generation unit includes: an acquisition subunit, used to acquire the difference between the first time information and the second time information to obtain a time difference; a first generation subunit, used to generate a wake-up result of wake-up failure in response to the time difference being greater than a first preset threshold, and to determine the failure reason corresponding to the wake-up result based on the time difference; and a second generation subunit, used to generate a wake-up result of wake-up success in response to the time difference being less than or equal to the first preset threshold.
[0101] Optionally, the first generating subunit is further configured to: determine that the failure is due to a delay in sending the remote wake-up command in response to a time difference greater than a second preset threshold; and determine that the failure is due to a wake-up delay in the vehicle in response to a time difference greater than a first preset threshold and less than or equal to a second preset threshold.
[0102] Optionally, the second generation module further includes: an acquisition unit for acquiring a locally stored list of event tracking data, wherein the list of event tracking data is used to store first event tracking data and second event tracking data; a traversal unit for traversing the list of event tracking data to obtain target event tracking data, wherein the target event tracking data is used to represent any event tracking data in the list of event tracking data; and a third generation unit for generating a wake-up result based on the target event tracking data.
[0103] Optionally, the device further includes: a determining module, used to determine the number of times the wake-up result is a successful wake-up based on the wake-up result, and to determine the total number of times the wake-up result is generated; and an acquiring module, used to acquire the quotient of the number of times and the total number of times to obtain the wake-up success rate of the remote wake-up command.
[0104] Optionally, the sending module includes: a forwarding unit, used to forward the remote wake-up command to the vehicle in response to the vehicle being online; and a fourth generation unit, used to generate SMS information based on the remote wake-up command and send the SMS information to the vehicle in response to the vehicle being offline.
[0105] Optionally, the SMS information includes, but is not limited to: wake-up ciphertext, identification information, and a delivery timestamp, wherein the delivery timestamp is generated when the user terminal sends a wake-up SMS.
[0106] Optionally, the device further includes: a second receiving module for receiving the execution result corresponding to the remote wake-up command returned by the vehicle; and a second sending module for sending the execution result to the user terminal.
[0107] Example 4
[0108] According to an embodiment of the present invention, a processing device for remote vehicle wake-up is also provided. This device can execute the processing method for remote vehicle wake-up provided in Embodiment 2 above. The specific implementation method and preferred application scenario are the same as those in Embodiment 2 above, and will not be repeated here.
[0109] Figure 8 This is a schematic diagram of a vehicle remote wake-up processing device according to Embodiment 2 of the present invention, as shown below. Figure 8 As shown, the device includes: a receiving module 82 for receiving a remote wake-up command forwarded by a server, wherein the remote wake-up command is sent from a user terminal to the server; a control module 84 for controlling the vehicle to execute the remote wake-up command and generating second embedded data; and a sending module 86 for sending the second embedded data to the server, wherein the second embedded data and first embedded data stored in the server are used to determine the wake-up result of the remote wake-up command, and the first embedded data is generated by the server based on the remote wake-up command.
[0110] Example 5
[0111] According to an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the vehicle remote wake-up processing method described above.
[0112] Example 6
[0113] According to an embodiment of the present invention, a vehicle is also provided, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the vehicle remote wake-up processing method described above.
[0114] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0115] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0116] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0118] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0119] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0120] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A processing method for vehicle remote wake-up, characterized in that, The method comprises: forwarding a remote wake-up instruction sent by a user terminal to a vehicle in a dormant state; generating first burying point data based on the remote wake-up instruction, wherein the first burying point data is used to represent data related to the forwarding of the remote wake-up instruction; receiving second burying point data sent by the vehicle, wherein the second burying point data is used to represent data related to the receiving of the remote wake-up instruction; generating a wake-up result of the remote wake-up instruction based on the first burying point data and the second burying point data; wherein generating the wake-up result of the remote wake-up instruction based on the first burying point data and the second burying point data comprises: in response to the first burying point data or the second burying point data being incomplete, generating the wake-up result as a wake-up failure, and determining that the failure reason corresponding to the wake-up result is a failure in issuing the remote wake-up instruction; in response to the first burying point data and the second burying point data being complete, generating the wake-up result based on first time information contained in the first burying point data and second time information contained in the second burying point data, wherein the first time information is used to represent the time of generating the first burying point data, and the second time information is used to represent the time of the vehicle sending the second burying point data.
2. The method of claim 1, wherein, generating the wake-up result based on the first time information contained in the first burying point data and the second time information contained in the second burying point data comprises: obtaining a difference between the first time information and the second time information to obtain a time difference value; in response to the time difference value being greater than a first preset threshold, generating the wake-up result as a wake-up failure, and determining the failure reason corresponding to the wake-up result based on the time difference value; in response to the time difference value being less than or equal to the first preset threshold, generating the wake-up result as a wake-up success.
3. The method of claim 2, wherein, determining the failure reason corresponding to the wake-up result based on the time difference value comprises: in response to the time difference value being greater than a second preset threshold, determining that the failure reason is a delay in sending the remote wake-up instruction; in response to the time difference value being greater than the first preset threshold and less than or equal to the second preset threshold, determining that the failure reason is a wake-up delay of the vehicle.
4. The method of claim 1, wherein, generating the wake-up result of the remote wake-up instruction based on the first burying point data and the second burying point data comprises: obtaining a burying point data list stored locally, wherein the burying point data list is used to store the first burying point data and the second burying point data; traversing the burying point data list to obtain target burying point data, wherein the target burying point data is used to represent any one of the burying point data in the burying point data list; generating the wake-up result based on the target burying point data.
5. The method of claim 1, wherein, After generating the wake-up result of the remote wake-up instruction based on the first burying point data and the second burying point data, the method further comprises: determining the number of times that the wake-up result is a wake-up success based on the wake-up result, and determining the total number of times that the wake-up result is generated; obtaining a quotient value of the number of times and the total number of times to obtain a wake-up success rate of the remote wake-up instruction.
6. The method of claim 1, wherein, Forwarding the remote wake-up command sent by the user terminal to the vehicle includes: In response to the vehicle being online, the remote wake-up command is forwarded to the vehicle; In response to the vehicle being offline, an SMS message is generated based on the remote wake-up command and sent to the vehicle.
7. The method of claim 1, wherein, The method further includes: Receive the execution result corresponding to the remote wake-up command returned by the vehicle; The execution result is sent to the user terminal.
8. A method for processing vehicle remote wake-up, the method comprising: include: Receive a remote wake-up command forwarded by the server, wherein the remote wake-up command is sent from the user terminal to the server; Control the vehicle to execute the remote wake-up command and generate the second embedded data; The second data point is sent to the server, wherein the second data point and the first data point stored in the server are used to determine the wake-up result of the remote wake-up command, and the first data point is generated by the server based on the remote wake-up command; the wake-up result is a wake-up failure when the first data point or the second data point is incomplete, and the reason for the wake-up failure is that the remote wake-up command was not issued; when the first data point and the second data point are complete, the first time information contained in the first data point and the second time information contained in the second data point are used to generate the wake-up result, wherein the first time information is used to characterize the time when the first data point was generated, and the second time information is used to characterize the time when the vehicle sent the second data point.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the vehicle remote wake-up processing method according to any one of claims 1 to 8.
Citation Information
Patent Citations
Smart Speaker Wake-Up Method and Device, Smart Speaker and Storage Medium
US20210151048A1