Vehicle control instruction execution method and device, medium and server

Abstract

This application discloses a vehicle control command execution method, apparatus, medium, and server, relating to the field of vehicle control. The method, applied to a server, includes: acquiring vehicle control commands from a user device and generating a task object based on the commands. The task object encapsulates the data structure of the vehicle control commands, the data structure including at least a task type, a task identifier, and task data; sending the task type and task identifier to the vehicle's vehicle network terminal, causing the vehicle network terminal to wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module; and responding to a data request sent by the control module based on the task identifier, sending the task data corresponding to the task identifier to the control module, causing the control module to execute the task according to preset control logic. This application enables independence between the TBOX and vehicle control services, improves the flexibility and maintainability of the overall vehicle architecture, and reduces the complexity and cost of system updates.

Description

Technical Field

[0001] This application belongs to the field of vehicle control technology, and in particular relates to a vehicle control command execution method, device, medium and server. Background Technology

[0002] As vehicles become increasingly intelligent, connected car functions have expanded from traditional remote control (such as remote start and lock) to a wider range of applications. Various operations performed by users on their mobile apps, such as navigation settings, music playback, seat adjustments, and ambient lighting control, need to be synchronized to the vehicle in real time to achieve a seamless user experience.

[0003] However, current connected vehicle systems rely heavily on TBOX (Telematics Entity Box), resulting in strong coupling in the system architecture. For example, adding new commands or business functions often requires simultaneous updates to the TBOX software version, which not only increases the complexity of development and maintenance but may also lead to longer upgrade cycles and higher costs. Furthermore, the current command issuance method is relatively simple, mainly relying on SMS, which is insufficient to meet the increasingly complex vehicle architecture and users' higher demands for real-time performance, reliability, and functional diversity. Therefore, it is urgent to address future more complex application scenarios and user needs through technological upgrades and architectural optimization. Summary of the Invention

[0004] This application provides a vehicle control command execution method, device, medium, and server, which can realize the independence between TBOX and vehicle control services, improve the flexibility and maintainability of the vehicle architecture, and reduce the complexity and cost of system updates.

[0005] In a first aspect, embodiments of this application provide a vehicle control command execution method, applied to a server, the method comprising:

[0006] Obtain vehicle control commands from user devices and generate task objects based on the vehicle control commands. The task objects are used to encapsulate the data structure of the vehicle control commands. The data structure includes at least the task type, task identifier, and task data.

[0007] The task type and task identifier are sent to the vehicle's vehicle network terminal, so that the vehicle network terminal can wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module.

[0008] In response to the data request sent by the control module based on the task identifier, the task data corresponding to the task identifier is sent to the control module so that the control module can execute the task according to the preset control logic.

[0009] In some feasible embodiments, the data request includes at least a task identifier, and the control module sends the data request to the server through a preset network channel.

[0010] In response to the data request sent by the control module based on the task identifier, the task data corresponding to the task identifier is sent to the control module, including:

[0011] Determine the task data corresponding to the task identifier based on the data request;

[0012] The task data is sent to the control module through a preset network channel.

[0013] In some feasible embodiments, sending the task type and task identifier to the vehicle's connected vehicle terminal includes:

[0014] Determine the vehicle's communication connection status, which includes normal connection status and disconnection status;

[0015] If the communication connection status is disconnected, the task type and task identifier will be sent to the vehicle network terminal via SMS.

[0016] If the communication connection status is normal, the task type and task identifier will be sent to the vehicle network terminal through the target network channel.

[0017] In some feasible embodiments, the method includes:

[0018] If the communication connection status is normal, then based on the communication connection status, determine at least one network channel that is normally connected to the vehicle.

[0019] Determine the target network channel based on at least one network channel.

[0020] In some feasible embodiments, the server includes a task scheduling module and at least one management module, and the method further includes:

[0021] The task scheduling module receives the task execution results sent by the control module;

[0022] The task scheduling module sends the task execution results to the target management module, so that the target management module can perform preset operations based on the task execution results.

[0023] In some feasible embodiments, at least one target management module performs preset operations based on the execution results, including:

[0024] If the execution result indicates that the task has failed, then the failure tolerance preset in the task object is used to determine whether the task is allowed to fail.

[0025] If the task is allowed to fail, terminate the task and send a notification message to the user device;

[0026] If the task is not allowed to fail, the task object is regenerated and rescheduled for execution.

[0027] In some feasible embodiments, the method includes:

[0028] The timer starts when the task type and task identifier are sent to the vehicle's connected vehicle terminal;

[0029] If no data request is received from the control module within the preset time threshold, the task is determined to have timed out, and the task status of the task object is updated to timed out to trigger the preset timeout handling mechanism.

[0030] Secondly, embodiments of this application provide a vehicle control command execution device, the device comprising:

[0031] The task object generation module is used to obtain vehicle control commands from user devices and generate task objects based on the vehicle control commands. The task object is used to encapsulate the data structure of the vehicle control commands. The data structure includes at least the task type, task identifier, and task data.

[0032] The first sending module is used to send the task type and task identifier to the vehicle's vehicle network terminal, so that the vehicle network terminal can wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module;

[0033] The second sending module is used to respond to the data request sent by the control module based on the task identifier and send the task data corresponding to the task identifier to the control module so that the control module can execute the task according to the preset control logic.

[0034] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the vehicle control instruction execution method described above.

[0035] Fourthly, embodiments of this application provide a server, which includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the vehicle control instruction execution method as described above.

[0036] Fifthly, embodiments of this application provide a computer program product in which the instructions are executed by the processor of an electronic device, causing the electronic device to execute any of the vehicle control instruction execution methods described above.

[0037] Invention Function and Effect

[0038] This application discloses a vehicle control command execution method, apparatus, medium, and server. The vehicle control command execution method is applied to a server and includes: acquiring a vehicle control command from a user device and generating a task object based on the command. The task object encapsulates the data structure of the vehicle control command, and the data structure includes at least a task type, a task identifier, and task data. The method sends the task type and task identifier to the vehicle's vehicle network terminal, enabling the vehicle network terminal to wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module. In response to a data request sent by the control module based on the task identifier, the method sends the task data corresponding to the task identifier to the control module, enabling the control module to execute the task according to preset control logic. Thus, in this application embodiment, when a vehicle control command needs to be issued to the vehicle's TBOX, the TSP platform only sends the task type and identifier information to the TBOX, without directly carrying complete business data. After receiving this information, the TBOX automatically wakes up the corresponding vehicle control module according to the task type. Subsequently, the control module communicates directly with the TSP platform, requests the necessary business data and executes tasks independently, thereby achieving independence between the TBOX and vehicle control services, improving the flexibility and maintainability of the vehicle architecture, and reducing the complexity and cost of system updates.

[0039] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0040] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0041] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0042] Figure 1 This is a schematic diagram of the remote vehicle control system architecture provided in the embodiments of this application;

[0043] Figure 2 This is a flowchart illustrating the vehicle control command execution method provided in an embodiment of this application;

[0044] Figure 3 This is one of the schematic diagrams of the business processing provided in the embodiments of this application;

[0045] Figure 4 This is the second schematic diagram of the business processing provided in the embodiments of this application;

[0046] Figure 5 This is a schematic diagram of the structure of the vehicle control command execution device provided in the embodiments of this application;

[0047] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such orders can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0050] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0051] To facilitate understanding, the terms used in this application will first be explained:

[0052] Connected Vehicle Service Provider (TSP): The TSP platform is the core of the connected vehicle ecosystem, connecting vehicles, users, and third-party service providers. It supports remote control functions (such as remote start, climate control, door locking, and vehicle location) by collecting real-time vehicle data and transmitting it to the cloud. It also provides fault diagnosis and warnings, navigation and entertainment services, safety and roadside assistance functions, and vehicle maintenance reminders.

[0053] Vehicle-to-Everything (TBOX) terminal: This is an intelligent terminal device installed inside the vehicle, used to receive control commands from the cloud or client to enable functions such as remote start, air conditioning adjustment, and door locking. It serves as a bridge for communication between the vehicle and the external network.

[0054] Integrated Domain Control Unit (IDCU): This is the core component of the remote vehicle control system. It is responsible for integrating and processing data from various functional domains of the vehicle, executing remote commands and coordinating communication. It supports remote operations such as locking the car and starting the air conditioning via mobile apps, while also providing feedback on vehicle status information.

[0055] Message Queues (MQ): A middleware used for asynchronous message delivery between applications or system components. MQ allows message senders and receivers to be decoupled in time and space; message senders put messages into queues, and message receivers read messages from queues for processing, without requiring both parties to be online or interact synchronously in real time.

[0056] In the current remote vehicle control architecture, when the server sends remote control commands to the vehicle, it transmits all service parameters to the vehicle's TBOX (Telematics Terminal Box). This design results in a high degree of system dependence on the TBOX and strong coupling. When new services are needed, both the TBOX and the server must be adjusted simultaneously, increasing system complexity and maintenance costs. Furthermore, when network communication between the server and the vehicle is completely interrupted, control commands can only be sent via SMS. However, the limited transmission capacity of SMS channels may lead to control command delivery failures, affecting system reliability.

[0057] To address the problems of the prior art, embodiments of this application provide a vehicle control command execution method, apparatus, medium, and server. Before detailing the vehicle control command execution method provided in the embodiments of this application, a brief description of the remote vehicle control architecture provided in the embodiments of this application is given below:

[0058] Figure 1 A schematic diagram of the remote vehicle control system architecture provided in an embodiment of this application is shown, such as... Figure 1 As shown, the remote vehicle control system architecture includes a mobile client 101, a TSP platform 102, and a vehicle terminal 103. The mobile client 101 includes an account module 110, a vehicle control module 111, and an authorization module 112; the TSP platform 102 includes an MQ 120, a Task service 121, an account service 122, an authorization service 123, and a vehicle control service 124; the vehicle terminal 103 includes an IDCU 130, a TBOX 131, and a CCU 132; the IDCU 130 includes an account module 1301 and an authorization module 1302.

[0059] The mobile client 101 can generate vehicle control commands in response to user operations and send the commands to the TSP platform 102 via an HTTP request. The TSP platform 102 can parse the received request and generate corresponding control commands, which are then sent to the vehicle terminal 103 via an SMS channel, MQTT connection, or TCP connection. After receiving the control commands, the vehicle terminal 103 can obtain task data and execute specific tasks via an MQTT connection or TCP connection. After the task is completed, the execution result is returned to the TSP platform 102 via the MQTT connection or TCP connection. The TSP platform 102 can process the execution result and feed back the final result to the mobile client 101, which then displays the result to the user.

[0060] Based on the aforementioned remote vehicle control system architecture, this application provides a method for executing vehicle control commands.

[0061] Please see Figure 2 This illustrates a flowchart of a vehicle control command execution method provided in one embodiment of this application. Figure 2 As shown, a vehicle control command execution method, applied to a server, includes the following steps:

[0062] S201: Obtain vehicle control commands from user equipment and generate task objects based on the vehicle control commands. The task objects are used to encapsulate the data structure of the vehicle control commands. The data structure includes at least the task type, task identifier, and task data.

[0063] When a user device sends a vehicle control command, the server receives the request information and encapsulates it into a task object, which includes at least the task type, task identifier, and task data of the vehicle control command. For example, if the user device wants to adjust the vehicle's air conditioning settings, the task type might be "air conditioning adjustment," the task identifier would be a unique number (such as a UUID), and the task data would contain the specific temperature setting and other relevant parameters.

[0064] Correspondingly, when a user device sends a request to cancel a task, the server can receive the cancellation request from the user device, parse the task identifier in the request, confirm its format and validity, and ensure that the corresponding task object can be accurately located. Subsequently, the server searches for the corresponding task object in the task queue or storage and marks its status as "cancelled".

[0065] Figure 3 This illustration shows one of the business processing flowcharts provided in the embodiments of this application, wherein the TSP is the aforementioned server, responsible for data interaction and management between the vehicle and various service providers.

[0066] like Figure 3As shown, when the primary user needs to send vehicle control commands, they can do so via a mobile app or smart wearable device. These commands include the desired operation type (e.g., "remotely start the vehicle") and necessary parameters (e.g., vehicle identifier, user identity information). The service is responsible for receiving and parsing the command, verifying the user's identity and permissions, and ensuring the request's legitimacy and security. Subsequently, the service can assemble the command into a Task based on its data structure (task type, task identifier, task data, etc.) and submit it to the Task service.

[0067] The Task service can construct and initialize a Task object based on the task code (task_code), task ID (task_id), and business parameters (task_biz_param). Here, task_code represents the task type, allowing for quick identification of the specific task category; task_id is the task identifier, a unique identifier for each task used to distinguish and track different tasks; and task_biz_param contains the task data, including various parameters and information required during task execution. These parameters are crucial inputs for correct task execution, guiding the specific operations and processing logic. During Task object creation, the Task service can simultaneously define the initial task state (task_state, e.g., "pending scheduling" or "pending execution") and timeout (task_timeout), and may set scheduling-related attributes (such as priority and execution queue) for the Task object, completing Task creation and incorporating it into the scheduling process.

[0068] When the primary user sends a request to cancel a task, the business service in the TSP platform receives the cancellation request from the user device, parses the task identifier in the request, and confirms its format and validity. Subsequently, the business service sends a vehicle control cancellation command to the Task service, which includes the task identifier. The Task service searches for the corresponding task object in the task queue or storage. If found, it marks the task's status as "cancelled" and, based on the task status, notifies the task scheduling module to remove the pending task or notifies the execution module to stop the already executed task. Regardless of whether the cancellation is successful or not, the Task service must provide feedback to the user device. In some embodiments, the Task service can also record operation logs for subsequent auditing and troubleshooting. Furthermore, the Task service must also pay attention to task status synchronization, concurrent processing, and security verification to ensure system stability and consistency.

[0069] In the remote vehicle control system architecture described above, the server is implemented by the TSP platform. It should be noted that this architecture is only an example, and the server is not limited to the TSP platform. In other embodiments, other forms of servers such as cloud servers, cloud platforms, and containerized servers can also be used. Similarly, the user device is not limited to a mobile client. In other embodiments, it can also be a tablet computer, smartwatch, vehicle terminal, or other smart device.

[0070] S202, the task type and task identifier are sent to the vehicle's vehicle network terminal, so that the vehicle network terminal can wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module.

[0071] Specifically, after receiving a vehicle control command, the server can send the command, which includes the task type and task identifier, to the vehicle-to-everything (V2X) terminal. Upon receiving the command, the V2X terminal will wake up the corresponding control module (such as the ECU module) based on the task type. For example, for the "air conditioning adjustment" task, the V2X terminal can identify that this is a task related to the vehicle's in-vehicle environmental control system, thus waking up the control module responsible for air conditioning operation. Simultaneously, the V2X terminal will forward the task identifier to the corresponding control module to ensure accurate subsequent data exchange.

[0072] like Figure 3 As shown, after the Task service creates a Task object in response to a vehicle control command, it can invoke the vehicle control command to schedule the corresponding vehicle control service module to send a control command to the TBOX via SMS channel to wake up the TBOX and start the Task delay check mechanism. This control command includes task_code and task_id. This mechanism can periodically check the task status; if the task is not completed before the timeout timestamp (e.g., the control command is not responded to or the task has not entered the execution state), timeout handling logic will be triggered. Timeout handling logic may include canceling the task, sending a timeout notification to the requester, or rescheduling the task. When the TBOX receives the control command, it passes the control command through to the IDCU and triggers the IDCU to wake up from its sleep state. Subsequently, the TBOX returns a command acknowledgment signal (Ack) to the TSP platform to confirm that the vehicle has successfully received the control command, ensuring reliable command transmission.

[0073] In this step, the control commands sent from the TSP platform to the TBOX only contain the task_code and task_id, reducing the amount of data and ensuring that the commands can be successfully sent through the limited bandwidth of SMS. This avoids transmission failures or delays that may occur with traditional commands containing large amounts of task data. In this way, the TBOX only needs to wake up the corresponding control module based on the task_code, without needing to process the specific task data. The execution of the specific task is handled by the corresponding control module, which retrieves the specific task data from the TSP and performs the execution itself. This achieves independence between the TBOX and the vehicle control service, enhancing the system's flexibility and independence.

[0074] In some feasible embodiments, sending the task type and task identifier to the vehicle's connected vehicle terminal includes:

[0075] Determining the vehicle's communication connection status, which includes both normal and disconnected states, can be achieved by detecting the network connection quality between the server and the vehicle-to-everything (V2X) terminal. For example, if the server can receive a heartbeat signal from the V2X terminal, it is considered to be in a normal connection state; conversely, if no heartbeat signal is received or an error message is received, it is considered to be in a disconnected state.

[0076] If the communication connection is disconnected, the task type and task identifier are sent to the vehicle-to-everything (V2X) terminal via SMS. SMS serves as a backup communication method, ensuring effective information delivery when the regular network connection is unavailable. This method relies on mobile operator services and offers high reliability and wide coverage. If the communication connection is active, the task type and task identifier are sent to the V2X terminal via the target network channel. The target network channel refers to the optimal communication path based on the current network conditions.

[0077] The vehicle control command execution method provided in this application can dynamically select the optimal communication method according to different vehicle states after determining the vehicle's communication connection status, so as to ensure the reliable issuance of remote control commands.

[0078] When a vehicle is in sleep mode, its vehicle-to-everything (V2X) terminal (such as TBOX) typically enters a low-power mode to conserve energy. The connection via network-based communication protocols (such as MQTT or TCP) is disconnected, and commands are sent via SMS, leveraging the wide coverage and high reliability of SMS to wake the vehicle. Upon receiving the SMS command, the TBOX triggers the vehicle to resume from sleep mode and activates the network communication module, preparing for subsequent interactions. When the vehicle is not in sleep mode, commands are preferentially sent via network channels (such as MQTT / TCP channels). This multi-channel compatible design not only ensures reliable command transmission in various scenarios but also optimizes communication efficiency and vehicle power consumption, while enhancing the system's flexibility and adaptability, providing a more stable and efficient control experience for intelligent connected vehicles. Furthermore, this design lays the foundation for supporting more communication methods in the future (such as V2X and satellite communication), further improving the system's scalability and compatibility.

[0079] Based on the above embodiments, in some feasible embodiments, the method includes: if the communication connection status is a normal connection status, then based on the communication connection status, determining at least one network channel that is normally connected to the vehicle; and based on the at least one network channel, determining a target network channel.

[0080] In this step, the server can assess the status of all available network channels. This can be achieved by sending test packets to the vehicle-to-everything (V2X) terminal and receiving responses. For example, by analyzing parameters such as response time and packet loss rate, the server can determine which network channels are currently available and performing well.

[0081] Once the list of available network channels is determined, the next step is to select the optimal target network channel. The target network channel here refers to the channel best suited to the current task requirements. To find the optimal path, the server can evaluate all available network channels (such as MQTT, TCP, Wi-Fi, 4G / 5G, etc.) and, considering factors such as latency and bandwidth, ultimately select the most suitable channel for data transmission. This not only improves the speed and stability of data transmission but also enhances the overall system's responsiveness and quality of service. For example, during high-priority task execution, selecting a low-latency network channel can reduce waiting time and improve user experience.

[0082] S203, in response to the data request sent by the control module based on the task identifier, send the task data corresponding to the task identifier to the control module so that the control module can execute the task according to the preset control logic.

[0083] In this step, once the control module issues a data request based on the task identifier, the server responds to the request and sends the corresponding task data to the control module. For example, when the control module is preparing to execute an air conditioning adjustment task, it requests detailed information such as specific temperature settings. The server sends all the necessary task data to the control module through a pre-established secure network channel, enabling the control module to complete the task according to the preset control logic.

[0084] Please see Figure 4 This illustrates a second schematic diagram of the business processing provided in the embodiments of this application, such as... Figure 4 As shown, after being woken up by the TBOX, the IDCU can retrieve a set of tasks (i.e., a list of tasks to be executed) from the Task service based on the task identifier (task_id). It then iterates through these tasks locally, parsing and executing each task. During execution, the IDCU calls the corresponding vehicle control module or functional unit (such as air conditioning control, window control, etc.) according to the specific requirements of each task to ensure accurate task completion. After execution, the IDCU summarizes the execution results of each task (such as success, failure, or specific status information) and returns the results to the Task service through a preset communication channel (such as HTTP, MQTT, etc.). This achieves distributed task execution and centralized result management, improving the system's flexibility and scalability while ensuring the reliability of task execution and real-time feedback capabilities.

[0085] In some feasible embodiments, the data request includes at least a task identifier. When the control module needs to obtain specific data required to execute a task, it sends a data request containing the task identifier to the server through a preset network channel (such as an HTTP request). HTTP is a widely used standardized protocol with advantages such as standardization, strong compatibility, ease of debugging and expansion, and supports HTTPS encryption to ensure data security.

[0086] Upon receiving the data request, the server first determines the corresponding task data based on the task identifier in the request. This process involves locating the task object associated with the task identifier and extracting the task data portion from it. Since each task object contains all the necessary information about a specific task (such as task type, task identifier, and task data), the server can quickly and accurately locate the required information. Once the server identifies the correct task data, it will send this data back to the control module using the same pre-defined network channel. In this process, selecting an appropriate network channel effectively avoids data loss or excessive latency, ensuring that the control module can receive the task data in a timely manner and begin executing the corresponding control logic.

[0087] In other embodiments, the control module can also acquire task data in other ways, such as: using WebSocket to achieve real-time bidirectional communication, suitable for scenarios requiring frequent data updates; using the MQTT protocol to efficiently transmit small data packets in low-bandwidth or unstable networks; utilizing the gRPC framework to achieve high-performance remote calls, supporting complex data interactions; transferring large files or batch data via FTP / SFTP; or designing a custom TCP / UDP protocol to meet specific performance requirements. Each of these methods has its advantages, and the specific choice depends on system requirements, network environment, and requirements for performance, security, and development costs.

[0088] The vehicle control command execution method of this application obtains vehicle control commands from a user device and generates a task object based on the vehicle control commands. The task object is used to encapsulate the data structure of the vehicle control commands, and the data structure includes at least a task type, a task identifier, and task data. The task type and task identifier are sent to the vehicle's vehicle network terminal, so that the vehicle network terminal wakes up the corresponding control module in the vehicle based on the task type and sends the task identifier to the control module. In response to the data request sent by the control module based on the task identifier, the task data corresponding to the task identifier is sent to the control module, so that the control module executes the task according to the preset control logic. Thus, in this embodiment of the application, when it is necessary to issue a vehicle control command to the TBOX on the vehicle side, the TSP only sends the task type and identifier information to the TBOX, without directly carrying the complete business data. After receiving this information, the TBOX will automatically wake up the corresponding vehicle control module according to the task type. Subsequently, the control module communicates with the TSP, requests the required business data on its own, and executes the task, thereby realizing the independence between the TBOX and the vehicle control service, improving the flexibility and maintainability of the overall vehicle architecture, and reducing the complexity and cost of system updates.

[0089] In some feasible embodiments, the server includes a task scheduling module and at least one management module. The task scheduling module, which is the Task service mentioned above, is responsible for receiving vehicle control commands, allocating tasks to execution nodes according to the scheduling strategy, monitoring task status, handling abnormal situations, and optimizing task execution efficiency to ensure that tasks are completed as planned. The management module, which is the vehicle control service in the TSP platform, is responsible for managing and coordinating tasks related to vehicle control. The method also includes:

[0090] The task scheduling module receives the task execution results sent by the control module; the task scheduling module sends the task execution results to the target management module so that the target management module can perform preset operations based on the task execution results.

[0091] In this step, after the control module completes its task, it sends the task execution result to the task scheduling module. Upon receiving the result, the task scheduling module broadcasts it to all management modules that have subscribed to that task's result. These management modules are the target management modules. Upon receiving the broadcast message, they process it according to their own business logic, such as updating the status, logging, or notifying users. This approach allows multiple modules to obtain task execution results promptly, facilitating collaboration and data sharing.

[0092] Please see Figure 4 After the IDCU completes the execution of the task set locally, it reports the task execution results to the Task service. The Task service can update the task status based on the execution results and broadcast the results to the vehicle control services that have subscribed to the task results via a message queue (MQ). This enables asynchronous notification of execution results, ensuring that multiple related modules or services can obtain the task execution status in a timely manner. For example, after the IDCU completes a task, the Task service, log service, and data analysis service can all receive the execution results simultaneously and perform subsequent processing as needed. In this embodiment, the Task service can obtain the task execution results returned by the IDCU in real time by listening to the MQ, without actively querying or waiting for the IDCU's synchronous response. This achieves asynchronous communication and decoupling, avoiding the performance overhead of polling or direct calls.

[0093] In some feasible embodiments, the target management module performs preset operations based on the execution result, including: if the execution result indicates that the task execution has failed, then determining whether the task is allowed to fail based on the preset failure tolerance in the task object. If the task is allowed to fail, then the task is terminated and a notification message is sent to the user device; if the task is not allowed to fail, then the task object is regenerated and rescheduled for execution.

[0094] Specifically, the task execution result contains information about whether the task was successfully completed. Based on this result, the target management module first analyzes its content to determine whether the task was successful. If the execution result indicates that the task failed, it further checks the preset failure tolerance parameter in the task object. This parameter determines what measures the system should take if the task fails.

[0095] If a task is allowed to fail, it is terminated, and a notification is sent to the user device. This process involves updating the task status and constructing and sending messages. This ensures that the user is promptly informed of task status changes. On the other hand, if a task cannot fail, the task scheduling module will regenerate the task object and reschedule its execution. This reasonable error handling mechanism improves system reliability and ensures the effective execution of critical tasks.

[0096] Understandably, in some embodiments, more complex failure-tolerance strategies can be introduced to improve system flexibility and adaptability. For example, for certain high-priority tasks, even if the first attempt fails, the system will not immediately reschedule, but will first attempt to diagnose and repair the cause of the failure. For instance, if the data transmission failure is due to an unstable network connection, the system may attempt to switch to a backup network channel and retry. This strategy not only considers the importance of the task but also incorporates possible causes of failure, thus providing a more intelligent task management approach.

[0097] In some embodiments, when the task type and task identifier are sent to the vehicle's vehicle-to-everything (V2X) terminal, a timer is started; if no data request is received from the control module within a preset time threshold, the task is determined to have timed out, and the task status of the task object is updated to timed out to trigger a preset timeout handling mechanism.

[0098] This step monitors the time interval between the issuance of the vehicle control command and the receipt of a data request from the control module. If no data request is received from the control module within this preset time threshold, the system determines that the task has timed out, updates the task object's status to "timed out," and triggers a series of preset timeout handling mechanisms. For example, the server might send a notification message to the user device, informing it that the current task failed to complete due to a timeout. Furthermore, the server might decide whether to reschedule the task based on its importance and priority. For critical tasks, even if a timeout occurs, the server might automatically attempt to regenerate the task object and resend the vehicle control command to ensure the task can ultimately be executed. This mechanism effectively improves the system's fault tolerance, ensuring that critical tasks can still be executed even under conditions of network instability or equipment failure.

[0099] Based on the vehicle control command execution method provided in the above embodiments, this application also provides specific implementation methods of the vehicle control command execution device. Please refer to the following embodiments.

[0100] like Figure 5 As shown in the embodiment of this application, the vehicle control command execution device includes:

[0101] The task object generation module 501 is used to obtain vehicle control instructions from the user device and generate task objects based on the vehicle control instructions. The task object is used to encapsulate the data structure of the vehicle control instructions. The data structure includes at least the task type, task identifier and task data.

[0102] The first sending module 502 is used to send the task type and task identifier to the vehicle's vehicle network terminal, so that the vehicle network terminal can wake up the corresponding control module in the vehicle based on the task type and send the task identifier to the control module.

[0103] The second sending module 503 is used to respond to the data request sent by the control module based on the task identifier and send the task data corresponding to the task identifier to the control module so that the control module can execute the task according to the preset control logic.

[0104] Figure 6 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0105] An electronic device may include a processor 601 and a memory 602 storing computer program instructions.

[0106] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0107] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0108] In a particular embodiment, memory 602 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0109] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the vehicle control instruction execution methods in the above embodiments.

[0110] In one example, the electronic device may also include a communication interface 603 and a bus 610. For example, Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0111] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0112] Bus 610 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0113] The electronic device can execute the vehicle control command execution method in the embodiments of this application, thereby achieving the combination Figure 1 and Figure 5 The described vehicle control command execution method and device.

[0114] Furthermore, in conjunction with the vehicle control command execution method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle control command execution methods in the above embodiments.

[0115] In conjunction with the vehicle control instruction execution methods in the above embodiments, this application embodiment can provide a computer program product, in which the instructions in the computer program product, when executed by the processor of an electronic device, cause the electronic device to execute any of the above vehicle control instruction execution methods.

[0116] In conjunction with the vehicle control command execution method in the above embodiments, this application embodiment can provide a server to implement it. The server includes at least one of the following: the vehicle control device as described above; the electronic device as described above; the computer-readable storage medium as described above; and the computer program product as described above. The server can be a TSP platform, which, through a communication connection with the vehicle, implements any of the above vehicle control command execution methods.

[0117] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0118] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0119] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0120] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0121] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method of vehicle control instruction execution, characterized by, Applied to a server, the method includes: Obtain vehicle control commands from user devices and generate task objects based on the vehicle control commands. The task objects are used to encapsulate the data structure of the vehicle control commands, and the data structure includes at least task type, task identifier, and task data. The task type and the task identifier are sent to the vehicle's vehicle network terminal, so that the vehicle network terminal wakes up the corresponding control module in the vehicle based on the task type and sends the task identifier to the control module; In response to the data request sent by the control module based on the task identifier, the task data corresponding to the task identifier is sent to the control module so that the control module executes the task according to the preset control logic.

2. The vehicle control command execution method according to claim 1, characterized by, The data request includes at least the task identifier, and the control module sends the data request to the server through a preset network channel. The step of responding to the data request sent by the control module based on the task identifier by sending the task data corresponding to the task identifier to the control module includes: Based on the data request, determine the task data corresponding to the task identifier; The task data is sent to the control module through the preset network channel.

3. The vehicle control command execution method according to claim 1, characterized by, Sending the task type and the task identifier to the vehicle's connected vehicle terminal includes: Determine the communication connection status of the vehicle, which includes a normal connection status and a disconnected connection status; If the communication connection status is disconnected, the task type and the task identifier are sent to the vehicle network terminal via SMS channel; If the communication connection status is normal, the task type and the task identifier are sent to the vehicle network terminal through the target network channel.

4. The vehicle control command execution method according to claim 3, characterized by, The method includes: If the communication connection status is a normal connection status, then based on the communication connection status, at least one network channel that is normally connected to the vehicle is determined. The target network channel is determined based on the at least one network channel.

5. The vehicle control command execution method according to claim 1, characterized by, The server includes a task scheduling module and at least one management module, and the method further includes: The task scheduling module receives the task execution results sent by the control module; The task scheduling module sends the task execution result to the target management module, so that the target management module can perform a preset operation based on the task execution result.

6. The vehicle control command execution method according to claim 5, characterized in that, The at least one target management module performs preset operations based on the execution result, including: If the execution result indicates that the task execution has failed, then it is determined whether the task is allowed to fail based on the preset failure tolerance in the task object. If the task is allowed to fail, then the task is terminated and a notification message is sent to the user device; If the task is not allowed to fail, the task object is regenerated and rescheduled for execution.

7. The vehicle control command execution method according to claim 1, characterized in that, The method includes: When the task type and the task identifier are sent to the vehicle's vehicle-to-everything (V2X) terminal, a timer is started; If the data request is not received from the control module within the preset time threshold, the task is determined to have timed out, and the task status of the task object is updated to timed out to trigger the preset timeout handling mechanism.

8. A vehicle control command execution device, characterized in that, The device includes: The task object generation module is used to obtain vehicle control instructions from the user device and generate task objects based on the vehicle control instructions. The task objects are used to encapsulate the data structure of the vehicle control instructions. The data structure includes at least task type, task identifier and task data. The first sending module is used to send the task type and the task identifier to the vehicle's vehicle network terminal, so that the vehicle network terminal wakes up the corresponding control module in the vehicle based on the task type and sends the task identifier to the control module; The second sending module is used to respond to the data request sent by the control module based on the task identifier, and send the task data corresponding to the task identifier to the control module so that the control module executes the task according to the preset control logic.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the vehicle control instruction execution method as described in any one of claims 1-7.

10. A server, characterized in that, It includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the vehicle control instruction execution method as described in any one of claims 1-7 by executing the instructions stored in the memory.

Images