Asynchronous communication method, device and equipment of Internet of Vehicles, storage medium and program product

Abstract

The embodiment of the invention provides an Internet of Vehicles asynchronous communication method and device, equipment, a storage medium and a program product. The method comprises the following steps: issuing a remote control instruction to message-oriented middleware, so that a vehicle end consumes the remote control instruction from the message-oriented middleware; determining a first timed task matched with the remote control instruction, and starting the first timed task; if it is determined that the message-oriented middleware receives an instruction execution result of the vehicle end within a preset time period according to the first timed task, the instruction execution result is sent to a remote control program, and an instruction execution state in a database is updated according to the instruction execution result; if it is determined that the message-oriented middleware does not receive the instruction execution result of the vehicle end within the preset time period according to the first timed task, an overtime execution result is determined, and after the overtime execution result is sent to the remote control program, the instruction execution state in the database is updated according to the overtime execution result; therefore, the integrity and accuracy of data and links are ensured.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to an asynchronous communication method, device, equipment, storage medium, and program product for vehicle networking. Background Technology

[0002] In the vehicle-to-everything (V2X) system, the cloud platform (i.e., the cloud) needs to execute remote control commands on the vehicle through the vehicle terminal (e.g., unlocking doors, controlling air conditioning, opening windows, etc.), and at the same time, the vehicle terminal needs to feed back the execution results to the cloud.

[0003] In one possible implementation, the cloud and the vehicle can transmit and receive instructions through asynchronous communication.

[0004] However, during asynchronous communication, abnormal scenarios such as instruction loss, feedback delay, and timeout may occur, which may prevent the formation of a complete data loop and / or link loop, resulting in defects in the remote control records in the database. Summary of the Invention

[0005] This application provides a method, apparatus, device, storage medium, and program product for asynchronous communication in vehicle-to-everything (V2X) networks, which aims to ensure the integrity and accuracy of data and links during asynchronous communication in V2X networks.

[0006] In a first aspect, embodiments of this application provide an asynchronous communication method for vehicle-to-everything (V2X) communication, including:

[0007] In response to remote control commands issued by a remote control program in the cloud, the remote control commands are published to a message middleware so that the vehicle consumes the remote control commands from the message middleware.

[0008] A first timed task matching the remote control command is determined and started; wherein, the first timed task is used to periodically query whether the message middleware has received the command execution result from the vehicle end within a preset time period;

[0009] If it is determined that the message middleware receives the instruction execution result from the vehicle within the preset time period, the instruction execution result is sent to the remote control program, and the instruction execution status in the database is updated according to the instruction execution result;

[0010] If it is determined that the message middleware does not receive the instruction execution result from the vehicle within the preset time period, a timeout execution result is determined, and the timeout execution result is sent to the remote control program. The instruction execution status in the database is then updated based on the timeout execution result.

[0011] In one possible implementation, determining a first timed task matching the remote control command includes:

[0012] Determine the polling frequency of the results matching the remote control command;

[0013] The first timed task is determined based on the polling frequency of the results.

[0014] In one possible implementation, determining the polling frequency of results matching the remote control command includes:

[0015] Obtain a preset polling frequency table; wherein the preset polling frequency table indicates the correspondence between preset instruction types and preset result polling frequencies;

[0016] Based on the instruction type of the remote control instruction and the preset polling frequency table, determine the result polling frequency that matches the remote control instruction.

[0017] In one possible implementation, determining the polling frequency of results matching the remote control command includes:

[0018] Determine the historical execution success rate of the remote control commands;

[0019] Based on the historical execution success rate, determine the polling frequency of the results matching the remote control command.

[0020] In one possible implementation, the instruction execution result indicates whether the execution was successful or failed; updating the instruction execution status in the database based on the instruction execution result includes:

[0021] If the instruction execution result indicates successful execution, then update the instruction execution status in the database to indicate successful instruction execution;

[0022] If the instruction execution result indicates that the execution failed, then the instruction execution status in the database is updated to "instruction execution failed".

[0023] In one possible implementation, the timeout execution result indicates an execution timeout; updating the instruction execution status in the database based on the timeout execution result includes:

[0024] Based on the timeout execution result, update the instruction execution status in the database to instruction execution timeout.

[0025] In one possible implementation, the method further includes:

[0026] If the message middleware receives the instruction execution result from the vehicle after the preset time period according to the first scheduled task, the instruction execution status in the database is updated according to the instruction execution result.

[0027] In one possible implementation, the method further includes:

[0028] If updating the instruction execution status in the database fails, then a pending update status is determined;

[0029] Start a second scheduled task; wherein the second scheduled task is used to periodically update the instruction execution status in the database;

[0030] Based on the second scheduled task and the pending update status, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

[0031] In one possible implementation, the number of states to be updated is multiple; based on the second timed task and the states to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated, including:

[0032] The state update order is determined based on the generation time of each state to be updated;

[0033] Based on the second scheduled task, the status update order, and the status to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

[0034] In one possible implementation, the method further includes:

[0035] If the remote control command fails to be published to the message middleware, the step of publishing the remote control command to the message middleware will be repeated according to the preset number of repetitions.

[0036] In one possible implementation, the method further includes:

[0037] If, after the preset number of repetitions, the remote control command still fails to be executed when sent to the message middleware, then the command sending result is determined to be a failure.

[0038] The system updates the instruction execution status in the database based on the failure result sent according to the instruction.

[0039] In one possible implementation, after updating the instruction execution status in the database, the method further includes:

[0040] Based on the updated instruction execution status, execution feedback information is generated and sent to the user terminal.

[0041] Secondly, embodiments of this application provide a vehicle-to-everything (V2X) asynchronous communication device, comprising:

[0042] The instruction response unit is used to respond to remote control instructions issued by the remote control program in the cloud, and to publish the remote control instructions to the message middleware so that the vehicle terminal can consume the remote control instructions from the message middleware.

[0043] A task initiation unit is used to determine a first timed task that matches the remote control command and to start the first timed task; wherein, the first timed task is used to periodically query whether the message middleware has received the command execution result from the vehicle end within a preset time period;

[0044] The first update unit is configured to, if it is determined that the message middleware receives the instruction execution result from the vehicle within the preset time period, send the instruction execution result to the remote control program and update the instruction execution status in the database according to the instruction execution result;

[0045] The second update unit is used to determine a timeout execution result if it is determined that the message middleware has not received the instruction execution result from the vehicle within the preset time period, and then send the timeout execution result to the remote control program and update the instruction execution status in the database according to the timeout execution result.

[0046] In one possible implementation, the task initiation unit is configured to:

[0047] Determine the polling frequency of the results matching the remote control command;

[0048] The first timed task is determined based on the polling frequency of the results.

[0049] In one possible implementation, the task initiation unit is configured to:

[0050] Obtain a preset polling frequency table; wherein the preset polling frequency table indicates the correspondence between preset instruction types and preset result polling frequencies;

[0051] Based on the instruction type of the remote control instruction and the preset polling frequency table, determine the result polling frequency that matches the remote control instruction.

[0052] In one possible implementation, the task initiation unit is configured to:

[0053] Determine the historical execution success rate of the remote control commands;

[0054] Based on the historical execution success rate, determine the polling frequency of the results matching the remote control command.

[0055] In one possible implementation, the instruction execution result indicates whether the execution was successful or failed; in this case, the first update unit is used to:

[0056] If the instruction execution result indicates successful execution, then update the instruction execution status in the database to indicate successful instruction execution;

[0057] If the instruction execution result indicates that the execution failed, then the instruction execution status in the database is updated to "instruction execution failed".

[0058] In one possible implementation, the timeout execution result indicates an execution timeout; at this time, the second update unit is used to:

[0059] Based on the timeout execution result, update the instruction execution status in the database to instruction execution timeout.

[0060] In one possible implementation, the device is also used for:

[0061] If the message middleware receives the instruction execution result from the vehicle after the preset time period according to the first scheduled task, the instruction execution status in the database is updated according to the instruction execution result.

[0062] In one possible implementation, the device is also used for:

[0063] If updating the instruction execution status in the database fails, then a pending update status is determined;

[0064] Start a second scheduled task; wherein the second scheduled task is used to periodically update the instruction execution status in the database;

[0065] Based on the second scheduled task and the pending update status, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

[0066] In one possible implementation, the number of states to be updated is multiple; in this case, the device is also used for:

[0067] The state update order is determined based on the generation time of each state to be updated;

[0068] Based on the second scheduled task, the status update order, and the status to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

[0069] In one possible implementation, the device is also used for:

[0070] If the remote control command fails to be published to the message middleware, the step of publishing the remote control command to the message middleware will be repeated according to the preset number of repetitions.

[0071] In one possible implementation, the device is also used for:

[0072] If, after the preset number of repetitions, the remote control command still fails to be executed when sent to the message middleware, then the command sending result is determined to be a failure.

[0073] The system updates the instruction execution status in the database based on the failure result sent according to the instruction.

[0074] In one possible implementation, the device is also used for:

[0075] After updating the instruction execution status in the database, execution feedback information is generated based on the updated instruction execution status, and the execution feedback information is sent to the user terminal.

[0076] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor;

[0077] The memory stores computer-executed instructions;

[0078] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0079] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0080] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0081] The vehicle-to-everything (V2X) asynchronous communication method, apparatus, device, storage medium, and program product provided in this application can respond to remote control commands issued by a remote control program in the cloud, and publish the remote control commands to a message middleware so that the vehicle can consume the remote control commands from the message middleware. At this time, the message middleware can decouple communication between the cloud and the vehicle, thereby ensuring communication quality. Simultaneously, the message middleware can also ensure the stability and reliability of command issuance and feedback, applying communication fluctuations and further improving the communication quality between the cloud and the vehicle. After the vehicle successfully publishes the remote control command to the message middleware, a first timed task matching the remote control command can be determined and started. This first timed task periodically queries whether the message middleware has received the command execution result from the vehicle within a preset time period. At this time, the timed task can cover abnormal scenarios, thereby helping to form a closed-loop record. Specifically, if the message middleware receives the instruction execution result from the vehicle within a preset time period according to the first scheduled task, the instruction execution result is sent to the remote control program, and the instruction execution status in the database is updated based on the instruction execution result. If the message middleware does not receive the instruction execution result from the vehicle within the preset time period according to the first scheduled task, a timeout execution result is determined, and the timeout execution result is sent to the remote control program, and the instruction execution status in the database is updated based on the timeout execution result. This implementation method can update the instruction execution status in the cloud database normally when the vehicle executes the remote control instruction normally and provides feedback on the instruction execution result. In addition, this implementation method can also determine the timeout execution result first and update the instruction execution status in the cloud database based on the timeout execution result in abnormal scenarios such as execution timeout or feedback delay, so that the cloud can provide timely and accurate feedback on the instruction execution status to the user, improve the response speed of remote control, reduce repetitive operations by the user, and improve the user experience. Furthermore, according to the above implementation method, a data / link closed loop can be formed in the cloud, thereby providing a complete data foundation for remote control performance optimization, which helps to improve the accuracy and efficiency of remote control performance optimization. Attached Figure Description

[0082] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0083] Figure 1 A flowchart illustrating an asynchronous communication method for vehicle networking provided in an embodiment of this application;

[0084] Figure 2 A flowchart illustrating another asynchronous communication method for vehicle networking provided in an embodiment of this application;

[0085] Figure 3 This is a schematic diagram illustrating an implementation scenario of an asynchronous communication method for vehicle networking provided in an embodiment of this application.

[0086] Figure 4 This is a schematic diagram illustrating the implementation process of an asynchronous communication method for vehicle networking provided in an embodiment of this application;

[0087] Figure 5 A schematic diagram of the structure of an asynchronous communication system for vehicle networking provided in this application embodiment;

[0088] Figure 6 This application provides a schematic diagram of the structure of an asynchronous communication device for vehicle networking.

[0089] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0090] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0091] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0092] The term "and / or" in this article merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone.

[0093] In addition, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of elements, such as including at least one of A, B, and C, and may mean including any one or more elements selected from the set consisting of A, B, and C.

[0094] In the vehicle-to-everything (V2X) system, the cloud platform (i.e., the cloud) needs to execute remote control commands on the vehicle through the vehicle terminal (e.g., unlocking doors, controlling air conditioning, opening windows, etc.), and at the same time, the vehicle terminal needs to feed back the execution results to the cloud.

[0095] In one possible implementation, the cloud and the vehicle can transmit and receive commands through asynchronous communication. Asynchronous communication between the cloud and the vehicle can include, but is not limited to, the following communication scenarios:

[0096] 1. The remote control command was sent from the cloud.

[0097] 2. The asynchronous remote control command was successfully sent from the cloud, but the vehicle did not receive the command.

[0098] 3. The asynchronous remote control command is successfully sent from the cloud and the vehicle receives the command, but the cloud does not receive a result from the vehicle indicating whether the execution was successful or failed.

[0099] 4. When the asynchronous remote control command is successfully sent from the cloud, the vehicle receives the command. If the vehicle fails to execute the command, the cloud platform will receive the result of successful or failed execution from the vehicle.

[0100] 5. The asynchronous remote control command is successfully sent from the cloud and the vehicle receives the command. However, the vehicle fails to execute the remote control command and the execution time limit is exceeded by the cloud. In the end, the vehicle receives the execution failure result.

[0101] 6. The asynchronous remote control command is successfully sent from the cloud. The vehicle receives the command, executes the remote control command successfully, and receives the execution success result from the vehicle after the cloud's time limit has expired.

[0102] 7. The asynchronous remote control command is successfully sent from the cloud. The vehicle receives the command, executes the remote control command successfully, and the cloud receives the successful execution result from the vehicle.

[0103] As can be seen from the above communication scenarios, during asynchronous communication between the vehicle and the cloud, abnormal situations such as command loss, feedback delay, and timeout may occur. However, the relevant technologies lack mechanisms to handle these abnormal situations, preventing the formation of a complete data loop and / or link loop in the cloud, resulting in defects in the remote control records in the database.

[0104] The asynchronous communication method for vehicle-to-everything (V2X) communication provided in this application enables the issuance of commands and the feedback of command execution results through a message middleware. Simultaneously, by incorporating a timed task mechanism, it ensures timely receipt, recording, and feedback of corresponding timeout execution results even in abnormal scenarios during asynchronous communication (e.g., feedback delays, timeout handling), thereby guaranteeing the integrity and accuracy of data and link loops in the V2X asynchronous communication process. Timely feedback of command execution results improves the speed of remote control command response, enhances user experience, and reduces the number of times users repeatedly initiate remote control commands, thus optimizing remote control performance.

[0105] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0106] Figure 1 This is a flowchart illustrating an asynchronous communication method for vehicle-to-everything (V2X) provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0107] S101. In response to remote control commands issued by the remote control program in the cloud, the remote control commands are published to the message middleware so that the vehicle can consume the remote control commands from the message middleware.

[0108] In this embodiment of the application, the user terminal can communicate with the vehicle terminal through the cloud, thereby enabling the user terminal to control the vehicle terminal.

[0109] For example, a user can initiate a remote control command from the user terminal and send the remote control command to the cloud. After receiving the remote control command initiated by the user terminal, the cloud will issue the remote control command.

[0110] The number of remote control commands can be one or more. When there are multiple remote control commands, the types of these commands can be the same or different.

[0111] At this point, the cloud can respond to the remote control commands issued by the remote control program in the cloud and publish the remote control commands to the uplink session of the message middleware, thereby realizing the publication of program control commands to the message middleware.

[0112] At this point, the vehicle can consume the corresponding remote control commands through the uplink session of the message middleware. After consuming the remote control commands, the vehicle can execute the corresponding remote control commands according to the vehicle's electronic control unit and obtain the command execution results.

[0113] Afterwards, the command execution result can be sent to the downlink session of the message middleware. At this time, the cloud obtains the command execution result by consuming the downlink session of the message middleware.

[0114] In this embodiment of the application, the message middleware is of type EMQX middleware. The type of message middleware is not limited here, and the asynchronous communication between the vehicle terminal and the cloud shall prevail.

[0115] At this point, to address abnormal scenarios during asynchronous communication, this application embodiment sets up a remote control timed task in the cloud, such as the first timed task described below. This first timed task can then promptly detect abnormal scenarios such as the cloud not receiving a success or failure result from the vehicle, or the cloud receiving a success or failure result from the vehicle after exceeding the cloud's time limit, as well as timeout handling. See the process described below for details.

[0116] S102. Determine the first timed task that matches the remote control command and start the first timed task.

[0117] The first scheduled task is used to periodically check whether the message middleware has received the instruction execution result from the vehicle end within a preset time period.

[0118] In one example, the first scheduled task can instruct a scheduled polling task. In this case, the scheduled polling of the first scheduled task can be used to determine whether the cloud has received the instruction execution result from the vehicle within a preset time period.

[0119] Optionally, the preset time period can indicate the time limit for the execution of instructions set in the cloud. For example, the preset time period can be 1 minute, 3 minutes, or 30 seconds. There is no limit to the value of the preset time period, which shall be determined according to the actual needs.

[0120] In one example, after the first scheduled task is started, the message middleware can be polled periodically according to the first scheduled task to determine whether the vehicle sends the instruction execution result to the message middleware within a preset time period, thereby determining whether the cloud has received the instruction execution result from the vehicle within the preset time period.

[0121] S103. If it is determined that the message middleware receives the instruction execution result from the vehicle end within a preset time period, the instruction execution result is sent to the remote control program, and the instruction execution status in the database is updated according to the instruction execution result.

[0122] S104. If it is determined that the message middleware has not received the instruction execution result from the vehicle end within the preset time period, then the timeout execution result is determined, and after the timeout execution result is sent to the remote control program, the instruction execution status in the database is updated according to the timeout execution result.

[0123] As described above, the embodiments of this application can respond to remote control commands issued by a remote control program in the cloud, publishing the remote control commands to a message middleware so that the vehicle can consume the remote control commands from the message middleware. In this case, the message middleware can decouple communication between the cloud and the vehicle, thereby ensuring communication quality. Simultaneously, the message middleware can also ensure the stability and reliability of command issuance and feedback, mitigating communication fluctuations and further improving the communication quality between the cloud and the vehicle. After the vehicle successfully publishes the remote control command to the message middleware, a first timed task matching the remote control command can be determined and started. This first timed task periodically checks whether the message middleware has received the command execution result from the vehicle within a preset time period. At this time, the timed task can cover abnormal scenarios, thus helping to form a closed-loop record. Specifically, if the message middleware receives the instruction execution result from the vehicle within a preset time period according to the first scheduled task, the instruction execution result is sent to the remote control program, and the instruction execution status in the database is updated based on the instruction execution result. If the message middleware does not receive the instruction execution result from the vehicle within the preset time period according to the first scheduled task, a timeout execution result is determined, and the timeout execution result is sent to the remote control program, and the instruction execution status in the database is updated based on the timeout execution result. This implementation method can update the instruction execution status in the cloud database normally when the vehicle executes the remote control instruction normally and provides feedback on the instruction execution result. In addition, this implementation method can also determine the timeout execution result first and update the instruction execution status in the cloud database based on the timeout execution result in abnormal scenarios such as execution timeout or feedback delay, so that the cloud can provide timely and accurate feedback on the instruction execution status to the user, improve the response speed of remote control, reduce repetitive operations by the user, and improve the user experience. Furthermore, according to the above implementation method, a data / link closed loop can be formed in the cloud, thereby providing a complete data foundation for remote control performance optimization, which helps to improve the accuracy and efficiency of remote control performance optimization.

[0124] Figure 2 A flowchart illustrating another asynchronous communication method for vehicle networking provided in this application embodiment is shown below. Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the asynchronous communication method for vehicle-to-everything (V2X) networks is described in detail, and the method includes:

[0125] S201. In response to remote control commands issued by the remote control program in the cloud, the remote control commands are published to the message middleware so that the vehicle can consume the remote control commands from the message middleware.

[0126] In one example, during the process of publishing remote control commands to the message middleware, there may be a situation where the command sending fails. In this case, the process described in S202 to S204 below can be executed.

[0127] S202. If the execution of the remote control command to the message middleware fails, the step of publishing the remote control command to the message middleware will be repeated according to the preset number of repetitions.

[0128] Optionally, the preset number of repetitions can be a pre-set value, such as 3 times, 5 times, etc. In this case, the same preset number of repetitions can be preset for different remote control commands of the same type, or different preset number of repetitions can be preset for different types of remote control commands. Here, there is no limit to the number of retries for failed remote control commands, and it is based on meeting actual needs.

[0129] Optionally, the preset number of repetitions can also be a value determined based on the historical number of retries. For example, if the release is successful after 2 historical retries, the preset number of repetitions can be set to 2; if the release is successful after 3 historical retries, the preset number of repetitions can be set to 3, and so on.

[0130] At this point, repeatedly issuing remote control commands can increase the probability of successful issuance of remote control commands, thereby helping to ensure the execution of remote control commands.

[0131] S203. If, after a preset number of repetitions, the remote control command still fails to execute when sent to the message middleware, then the command sending result is determined to be a failure.

[0132] S204. Update the command execution status in the database based on the failure result sent by the command.

[0133] Optionally, the command sending failure result indicates that the command sending failed.

[0134] At this point, the command execution status in the database can be updated to "command sent failed" based on the command sending failure result.

[0135] This implementation method can still update the instruction execution status in the database even if instruction sending fails, thereby improving the closed loop of asynchronous communication data and links in abnormal scenarios where instructions are lost.

[0136] In one example, if the remote control command is successfully published to the message middleware and executed, the process described below continues.

[0137] S205. Determine the polling frequency for results matching the remote control command.

[0138] S206. Determine the first scheduled task based on the polling frequency of the results.

[0139] The first scheduled task is used to periodically check whether the message middleware has received the instruction execution result from the vehicle end within a preset time period.

[0140] At this point, the polling time of the first scheduled task can be determined based on the polling frequency of the results, and the first scheduled task can be executed according to the polling time.

[0141] At this point, the frequency of result polling can be used to dynamically adjust the first scheduled task, thereby improving its applicability.

[0142] In one possible implementation, in order to make the first timed task more compatible with the current remote control command, different first timed tasks can be configured for different remote control commands in this embodiment of the application.

[0143] Based on this, when determining the polling frequency of results that match remote control commands, a preset polling frequency table can be obtained first; wherein, the preset polling frequency table indicates the correspondence between preset command types and preset result polling frequencies.

[0144] Then, based on the instruction type of the remote control instruction and the preset polling frequency table, the polling frequency of the result matching the remote control instruction is determined.

[0145] This implementation allows for customization of the result polling frequency for different instruction types using a preset polling frequency table, thereby increasing the diversity of result polling frequencies. Furthermore, by adding, deleting, or modifying the preset polling frequency table, the first scheduled task can be quickly and accurately adjusted, improving its flexibility, diversity, and scalability.

[0146] In one example, this embodiment of the application can also train a machine learning model based on the remote control commands and the execution duration of each command, resulting in a trained machine learning model. Then, the remote control commands issued by the remote control program can be input into the trained machine learning model to predict the execution duration of the remote control commands, and the result polling frequency can be determined based on the command execution duration.

[0147] In another possible implementation, when determining the polling frequency for results matching remote control commands, the historical execution success rate corresponding to the remote control commands can be determined first. Then, based on the historical execution success rate, the polling frequency for results matching remote control commands can be determined.

[0148] In one example, multiple success rate levels can be pre-defined, and a corresponding result polling frequency can be pre-configured for each success rate level. Then, the matching result polling frequency can be determined based on the success rate level to which the historical execution success rate of the remote control command belongs. The number of pre-defined success rate levels can be two, three, or four, etc. There is no limit to the number of pre-defined success rate levels; the choice is based on what is feasible.

[0149] S207. Start the first scheduled task.

[0150] At this point, after starting the first scheduled task, the first scheduled task can be executed according to the polling frequency of the results, so as to periodically check whether the message middleware has received the instruction execution results from the vehicle end within a preset time period.

[0151] S208. If it is determined that the message middleware receives the instruction execution result from the vehicle end within a preset time period, the instruction execution result will be sent to the remote control program.

[0152] Optionally, the instruction execution result indicates whether the execution was successful or failed. In this case, when updating the instruction execution status in the database based on the instruction execution result, please refer to the process described in S209 to S310 below.

[0153] S209. If the instruction execution result indicates successful execution, then update the instruction execution status in the database to "instruction executed successfully".

[0154] S210. If the instruction execution result indicates that the execution failed, then update the instruction execution status in the database to "instruction execution failed".

[0155] This implementation method can update the database with the results of instruction execution in a timely manner to ensure the consistency of instruction execution status between the cloud and the vehicle.

[0156] S211. If it is determined that the message middleware has not received the instruction execution result from the vehicle end within the preset time period, then the timeout execution result is determined and sent to the remote control program.

[0157] Optionally, the timeout execution result indicates that the execution timed out. In this case, when updating the instruction execution status in the database based on the timeout execution result, please refer to the process described in S312 below.

[0158] S212. Based on the timeout execution result, update the instruction execution status in the database to "instruction execution timeout".

[0159] This implementation method can update the instruction execution status in the database in a timely manner based on the timeout execution result when the instruction execution times out, thus shortening the time for execution result feedback and improving response speed.

[0160] Optionally, in order to capture the instruction execution status under abnormal scenarios and thus cover abnormal scenarios with timeout feedback, in this embodiment of the application, the duration of starting the first timed task can be greater than a preset time period.

[0161] Based on this, if the message middleware receives the instruction execution result from the vehicle after a preset time period according to the first scheduled task, the instruction execution status in the database is updated according to the instruction execution result.

[0162] For example, if the message middleware receives a successful instruction execution result from the vehicle after a preset time period, the instruction execution status in the database is updated from instruction execution timeout to instruction execution success; if the message middleware receives a failed instruction execution result from the vehicle after a preset time period, the instruction execution status in the database is updated from instruction execution timeout to instruction execution failure.

[0163] This implementation ensures that the cloud can still update the instruction execution status in the database after a timeout, thus guaranteeing the consistency and accuracy of instruction status between the vehicle and the cloud.

[0164] In one possible implementation, when updating the instruction execution status in the database, write conflicts or other issues may cause the update to fail. Therefore, in this embodiment, to ensure successful updates to the instruction execution status in the database, a second scheduled task can be configured to repeatedly execute the instruction execution status update process, as described in S213 to S215 below.

[0165] S213. If the execution status of the instruction to update the database fails, then determine the status to be updated.

[0166] Optionally, the pending status can indicate the result of instruction execution and / or the result of timeout execution.

[0167] S214. Start the second scheduled task.

[0168] The second scheduled task is used to periodically update the instruction execution status in the database.

[0169] Optionally, the execution interval for the second scheduled task can be 1 second or 5 seconds, etc. There is no limit to this, and it should be based on actual needs.

[0170] S215. Based on the second scheduled task and the pending update status, repeatedly update the instruction execution status in the database until the instruction execution status in the database is successfully updated.

[0171] This implementation method can ensure that the timeout execution results and / or instruction execution results are accurately written to the database through a second timed task, thereby reducing the impact of temporary failures on instruction execution status updates.

[0172] In one possible implementation, if the number of states to be updated is determined to be multiple, in order to ensure the accuracy of the state updates, this application embodiment can first determine the state update order based on the generation time of each state to be updated.

[0173] Then, based on the second scheduled task, the status update order, and the status to be updated, the instruction execution status in the database is updated repeatedly until the instruction execution status in the database is successfully updated.

[0174] In one possible implementation, after updating the instruction execution status in the database, in order to enable users on the client side to be aware of the instruction execution status in a timely manner to assist in user decision-making, the embodiments of this application can promptly feed back the instruction execution status to the client side.

[0175] Specifically, in this embodiment of the application, execution feedback information can be generated based on the updated instruction execution status, and the execution feedback information can be sent to the user terminal.

[0176] Figure 3 This is a schematic diagram illustrating an implementation scenario of an asynchronous communication method for vehicle networks provided in an embodiment of this application. Figure 3 As shown, in this implementation scenario, the cloud can include at least a remote control program and a message middleware, and the vehicle side can include at least a vehicle-side Tbox. In this case, the remote control program on the vehicle side and the vehicle-side Tbox communicate asynchronously through the message middleware (e.g., EMQX).

[0177] Specifically, the vehicle-side remote control program can send remote control commands to the uplink session of the message middleware. At this time, the vehicle-side Tbox consumes the uplink session, executes the remote control commands, and sends the command execution results to the downlink session of the message middleware. The cloud can consume the downlink session of the message middleware and obtain the command execution results.

[0178] Meanwhile, scheduled tasks can be set up in the cloud, and timeouts can be determined through scheduled task compensation, and the corresponding instruction execution status can be updated.

[0179] Figure 4 This is a schematic diagram illustrating the implementation process of an asynchronous communication method for vehicle networks provided in an embodiment of this application. Figure 3 Based on application scenarios, the asynchronous communication method for vehicle-to-everything (V2X) will be explained in detail, such as... Figure 4 As shown, the method may include the following steps:

[0180] Step 1: The remote control program at the remote end publishes remote control commands to the uplink session of the message middleware. If the command delivery fails, it is retried (e.g., three times). If it still fails, the command execution status in the cloud database is updated to "command delivery failed".

[0181] Step 2: If the instruction is successfully issued and the vehicle-side Tbox does not consume the remote control instruction in the EMQX uplink session (i.e., consumption fails), then timeout determination is performed according to the first timed task started. If timeout is determined, then the timeout execution result is obtained, and the instruction execution status is updated to instruction execution timeout based on the timeout execution result.

[0182] Step 3: If the command is successfully issued and the vehicle-side Tbox successfully consumes the remote control command (i.e., consumption is successful), the vehicle-side Tbox executes the command. At this point, regardless of whether the command execution succeeds or fails, if the cloud does not consume the command execution result within the preset time period, the first timed task will perform a timeout determination. If a timeout is determined, the timeout execution result is obtained, and the command execution status is updated to command execution timeout based on the timeout execution result.

[0183] Step 4: If the instruction is successfully issued and the vehicle receives the remote control instruction, and the vehicle executes the instruction successfully or fails, but receives the instruction execution result after a preset time period, then based on step 3, the instruction execution status is changed from instruction execution timeout to the corresponding instruction execution result.

[0184] Step 5: If the instruction is successfully issued and the vehicle receives the remote control instruction, but the cloud fails to update the instruction execution status, then start the second scheduled task and continue to update the instruction execution status according to the second scheduled task until the update is successful.

[0185] Step 6: If the instruction is successfully issued, the vehicle consumes the remote control instruction, and the cloud successfully updates the instruction execution status, then based on the updated instruction execution status, generate execution feedback information and send the execution feedback information to the user terminal.

[0186] Figure 5 This application provides a schematic diagram of the structure of an asynchronous communication system for vehicle networking, as shown in the embodiment of the present application. Figure 5 As shown, the vehicle-to-everything (V2X) asynchronous communication system provided in this embodiment includes: an instruction sending module, a timed task module, a status update module, and a feedback module.

[0187] The instruction sending module is used to publish remote control instructions to the message middleware, so that the vehicle can consume the remote control instructions from the message middleware.

[0188] The scheduled task module is used to determine the first scheduled task that matches the remote control command after it is successfully published to the message middleware, start the first scheduled task, and periodically query the message middleware to see if the command execution result from the vehicle end is received within a preset time period according to the first scheduled task.

[0189] The status update module is used to update the instruction execution status in the database based on the timeout execution result and / or instruction execution result.

[0190] The feedback module is used to generate execution feedback information based on the updated instruction execution status and send the execution feedback information to the user terminal.

[0191] Figure 6 This is a schematic diagram of the structure of an asynchronous communication device for vehicle networking provided in an embodiment of this application, as shown below. Figure 6 As shown, the vehicle-to-everything (V2X) asynchronous communication device 60 provided in this embodiment includes:

[0192] The instruction response unit 601 is used to respond to remote control instructions issued by the remote control program in the cloud, and to publish the remote control instructions to the message middleware so that the vehicle can consume the remote control instructions from the message middleware.

[0193] The task initiation unit 602 is used to determine a first timed task that matches the remote control command and to start the first timed task; wherein, the first timed task is used to periodically query whether the message middleware has received the command execution result from the vehicle end within a preset time period.

[0194] The first update unit 603 is used to send the instruction execution result to the remote control program and update the instruction execution status in the database according to the instruction execution result if it is determined that the message middleware has received the instruction execution result from the vehicle end within a preset time period.

[0195] The second update unit 604 is used to determine the timeout execution result if it is determined that the message middleware has not received the instruction execution result from the vehicle end within a preset time period, and then send the timeout execution result to the remote control program and update the instruction execution status in the database according to the timeout execution result.

[0196] In one possible implementation, the task initiation unit 602 is configured to:

[0197] Determine the polling frequency for results matching remote control commands;

[0198] The first scheduled task is determined based on the polling frequency of the results.

[0199] In one possible implementation, the task initiation unit 602 is configured to:

[0200] Obtain a preset polling frequency table; wherein, the preset polling frequency table indicates the correspondence between preset instruction types and preset result polling frequencies;

[0201] Based on the instruction type of the remote control command and the preset polling frequency table, determine the polling frequency of the result that matches the remote control command.

[0202] In one possible implementation, the task initiation unit 602 is configured to:

[0203] Determine the historical execution success rate of remote control commands;

[0204] Based on the historical execution success rate, determine the polling frequency for results that match remote control commands.

[0205] In one possible implementation, the instruction execution result indicates whether the execution was successful or failed; in this case, the first update unit 603 is used to:

[0206] If the instruction execution result indicates successful execution, then update the instruction execution status in the database to indicate successful instruction execution.

[0207] If the instruction execution result indicates that the execution failed, then update the instruction execution status in the database to indicate that the instruction execution failed.

[0208] In one possible implementation, the timeout execution result indicates an execution timeout; at this time, the second update unit 604 is used to:

[0209] Based on the timeout result, update the instruction execution status in the database to "instruction execution timeout".

[0210] In one possible implementation, the device is also used for:

[0211] If the message middleware receives the instruction execution result from the vehicle after a preset time period according to the first scheduled task, then the instruction execution status in the database is updated according to the instruction execution result.

[0212] In one possible implementation, the device is also used for:

[0213] If the execution status of the command to update the database fails, then the status to be updated is determined.

[0214] Start the second scheduled task; the second scheduled task is used to periodically update the instruction execution status in the database.

[0215] Based on the second scheduled task and the pending update status, repeatedly update the instruction execution status in the database until the instruction execution status in the database is successfully updated.

[0216] In one possible implementation, the number of states to be updated is multiple; in this case, the device is also used for:

[0217] The order of state updates is determined based on the generation time of each state to be updated;

[0218] Based on the second scheduled task, the status update order, and the status to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

[0219] In one possible implementation, the device is also used for:

[0220] If the remote control command fails to be published to the message middleware, the steps of publishing the remote control command to the message middleware will be repeated according to the preset number of repetitions.

[0221] In one possible implementation, the device is also used for:

[0222] If, after a preset number of repetitions, the remote control command still fails to execute when sent to the message middleware, then the command sending result is determined to be a failure.

[0223] Update the command execution status in the database based on the failure result of the command.

[0224] In one possible implementation, the device is also used for:

[0225] After updating the instruction execution status in the database, execution feedback information is generated based on the updated instruction execution status and sent to the user terminal.

[0226] The vehicle-to-everything (V2X) asynchronous communication device provided in this embodiment can execute the method provided in the above-described method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0227] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 7 As shown, the computer device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the computer device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0228] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0229] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0230] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0231] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0232] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0233] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0234] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0235] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0236] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0237] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0238] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0239] In addition, 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.

[0240] If a function 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 this invention, or the part that contributes to the prior art, or a 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 of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0241] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0242] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A vehicle-to-everything (V2X) asynchronous communication method, characterized in that, include: In response to remote control commands issued by a remote control program in the cloud, the remote control commands are published to a message middleware so that the vehicle consumes the remote control commands from the message middleware. A first timed task matching the remote control command is determined and started; wherein, the first timed task is used to periodically query whether the message middleware has received the command execution result from the vehicle end within a preset time period; If it is determined that the message middleware receives the instruction execution result from the vehicle within the preset time period, the instruction execution result is sent to the remote control program, and the instruction execution status in the database is updated according to the instruction execution result; If it is determined that the message middleware does not receive the instruction execution result from the vehicle within the preset time period, a timeout execution result is determined, and the timeout execution result is sent to the remote control program. The instruction execution status in the database is then updated based on the timeout execution result.

2. The method according to claim 1, characterized in that, Determining the first timed task that matches the remote control command includes: Determine the polling frequency of the results matching the remote control command; The first timed task is determined based on the polling frequency of the results.

3. The method according to claim 2, characterized in that, Determining the polling frequency of results matching the remote control command includes: Obtain a preset polling frequency table; wherein the preset polling frequency table indicates the correspondence between preset instruction types and preset result polling frequencies; Based on the instruction type of the remote control instruction and the preset polling frequency table, determine the result polling frequency that matches the remote control instruction.

4. The method according to claim 2, characterized in that, Determining the polling frequency of results matching the remote control command includes: Determine the historical execution success rate of the remote control commands; Based on the historical execution success rate, determine the polling frequency of the results matching the remote control command.

5. The method according to claim 1, characterized in that, The instruction execution result indicates whether the execution was successful or failed; updating the instruction execution status in the database based on the instruction execution result includes: If the instruction execution result indicates successful execution, then update the instruction execution status in the database to indicate successful instruction execution; If the instruction execution result indicates that the execution failed, then the instruction execution status in the database is updated to "instruction execution failed".

6. The method according to claim 1, characterized in that, The timeout execution result indicates an execution timeout; updating the instruction execution status in the database based on the timeout execution result includes: Based on the timeout execution result, update the instruction execution status in the database to instruction execution timeout.

7. The method according to claim 6, characterized in that, The method further includes: If the message middleware receives the instruction execution result from the vehicle after the preset time period according to the first scheduled task, the instruction execution status in the database is updated according to the instruction execution result.

8. The method according to claim 1, characterized in that, The method further includes: If updating the instruction execution status in the database fails, then a pending update status is determined; Start a second scheduled task; wherein the second scheduled task is used to periodically update the instruction execution status in the database; Based on the second scheduled task and the pending update status, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

9. The method according to claim 8, characterized in that, The number of states to be updated is multiple; based on the second scheduled task and the states to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated, including: The state update order is determined based on the generation time of each state to be updated; Based on the second scheduled task, the status update order, and the status to be updated, the instruction execution status in the database is repeatedly updated until the instruction execution status in the database is successfully updated.

10. The method according to claim 1, characterized in that, The method further includes: If the remote control command fails to be published to the message middleware, the step of publishing the remote control command to the message middleware will be repeated according to the preset number of repetitions.

11. The method according to claim 10, characterized in that, The method further includes: If, after the preset number of repetitions, the remote control command still fails to be executed when sent to the message middleware, then the command sending result is determined to be a failure. The system updates the instruction execution status in the database based on the failure result sent according to the instruction.

12. The method according to any one of claims 1-11, characterized in that, After updating the instruction execution status in the database, the method further includes: Based on the updated instruction execution status, execution feedback information is generated and sent to the user terminal.

13. A vehicle-to-everything (V2X) asynchronous communication device, characterized in that, include: The instruction response unit is used to respond to remote control instructions issued by the remote control program in the cloud, and to publish the remote control instructions to the message middleware so that the vehicle terminal can consume the remote control instructions from the message middleware. A task initiation unit is used to determine a first timed task that matches the remote control command and to start the first timed task; wherein, the first timed task is used to periodically query whether the message middleware has received the command execution result from the vehicle end within a preset time period; The first update unit is configured to, if it is determined that the message middleware receives the instruction execution result from the vehicle within the preset time period, send the instruction execution result to the remote control program and update the instruction execution status in the database according to the instruction execution result; The second update unit is used to determine a timeout execution result if it is determined that the message middleware has not received the instruction execution result from the vehicle within the preset time period, and then send the timeout execution result to the remote control program and update the instruction execution status in the database according to the timeout execution result.

14. A computer device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-12.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-12.

Images